Chapter 11

Implementation Discipline

Purpose

• The implementation discipline has four purposes:

– To define the organization of the code in terms of implementation subsystems organized in layers

– To implement classes and objects in terms of components • source files, binaries, executables, and others

– To test the developed components as units

– To integrate into an executable system the results produced by individual implementers or teams

The scope of test within the implementation discipline is limited to unit test of individual components.

Key Concepts (1)

• Builds– A build is an operational version of a system or part of a system that

demonstrates a subset of the capabilities to be provided in the final product.

– During iterative software development there will be numerous builds.

– Configuration control is useful if a build is needed to roll back to an earlier version when added functionality causes breakage.

– Typically, projects try to produce builds at regular intervals, up to one each day, but at least one per week toward the end of an iteration.

Key Concepts (2)

• Integration– The term integration refers to a software development activity in

which separate software components are combined into a whole.– Integration is done at several levels and stages of the

implementation, for the following purposes:• To integrate the work of a team working in the same implementation

subsystem

• To integrate subsystems into a complete system

– RUP approach to integration is incremental integration: • code is written and tested in small pieces and combined into a

working whole by the addition of one piece at a time.

– Phased integration, on the other hand, relies on integrating multiple (new and changed) components at the same time.

Key Concepts (2) (cont.)

• Incremental integration offers following benefits:

– Faults are easy to locate.

– The components are tested more fully.

– Some part of the system is running earlier.

• It is important to understand that integration occurs (at least once) during each iteration.

Key Concepts (3)

• Prototypes– Prototypes are used to reduce risk for the following issues.

• The business viability of a product being developed

• The stability or performance of key technology

• Project commitment or funding (a small proof-of-concept prototype)

• The understanding of requirements

• The look and feel, and usability, of the product

– However, the goal of the prototype must remain clear throughout its lifetime.

• If we don't intend to evolve the prototype into the real product, don't assume that because prototype works it should become final product.

Key Concepts (3) (Types of Prototypes)

• In the context of what they explore, there are 2 main types:

– A behavioral prototype• Which focuses on exploring specific behavior of the system

– A structural prototype• Which explores architectural or technological concern

• In the context of their outcome, there are also 2 types:

– An exploratory prototype, also called a throwaway prototype• Which is thrown away after it is finished and you have learned

whatever you wanted from it

– An evolutionary prototype• Which evolves to become the final system

Roles & Artifacts in Implementation

Roles in Implementation

• The main roles:– The Implementer

• develops components and related artifacts and performs unit testing

– The System Integrator• constructs a build

• Other roles include:– The Software Architect

• defines structure of the implementation model (layering and subsystems)

– The Code Reviewer• inspects the code for quality and conformance to the project standard

Key Artifacts

• Implementation Subsystem– A collection of implementation elements and other implementation

subsystems

• Implementation Elements– A piece of software code (source, binary, or executable) or a file

containing information (i.e. a start-up file or a readme file).

• Integration Build Plan– This document defines the order in which the elements and

subsystems should be implemented and specifies the builds to be created when the system is integrated.

Implementation Workflow

Round-trip engineering

• Certain programming languages and tools, such as Rational Rose, and for some types of applications, will allow a close tie between design and implementation.

• Designer can modify the design model and regenerate the corresponding code

• Implementer can modify the implementation code and then alter the design to match the modification.

Summary

• A key feature of the RUP is its approach to incremental integration throughout the lifecycle.

• During the elaboration phase, we build an evolutionary, structural prototype that becomes the final system during the construction phase.

• In parallel, we can build a few throwaway behavioral prototypes to explore issues such as the user interface.

• Round-trip engineering is a technique, supported by a tool such as Rose or XDE, that closely ties together design and implementation of a software development effort.

Chapter 12

Test Discipline

Purpose of Test Discipline

• Find and document failures in the software product

• Advise management on the perceived quality of software.

• Evaluate assumptions made in design and requirement specifications through concrete demonstration.

• Validate that software product works as designed.

• Validate that requirements are implemented appropriately.

Purpose of Test Discipline (cont.)

• Test discipline focuses on what is missing, incorrect, or inconsistent.

• A good test effort is driven by questions such as these:– How could this software break?– In what situations could this software fail to work predictably?

• A continuous approach to quality, initiated early in software lifecycle, can significantly lower the cost of completing and maintaining the software.

Testing in the Iterative Lifecycle

• Testing is not a single activity, nor is it a project phase during which we assess quality.

• Testing must occur throughout the lifecycle:

– We can test the broad functionality of early prototypes;– We can test the stability, coverage, and performance of the

architecture while there is still an opportunity to fix it;– And we can test the final product to assess its readiness for

delivery to customers.

Dimensions of Testing

• Tests can be categorized in various ways:

– Quality dimension: • The test focuses on a major quality characteristic or attribute.

– Level of testing: • The test strategy targets a general category of software elements.

– Type of test: • An individual test has a specific test objective, usually limited to a

single quality dimension.

Quality Dimension

• Following aspects are generally assessed for most products

– Reliability• Software performs predictably and consistently;

– Functionality• Software executes the required use cases or behavior as intended.

– Performance• Software and system execute and respond in a timely manner and

continue to perform acceptably when subjected to real-world operational characteristics.

– Usability• Software is suitable for use by its end users;

• The focus here is on human factors, esthetics, and so forth.

Levels of Testing

• Unit testing– The smallest testable elements of the system are tested, typically

at the same time that those elements are implemented.

• Integration testing– The integrated units (or components or subsystems) are tested.

• System testing– The complete application and system (one or more applications)

are tested.

• Acceptance testing– The complete application (or system) is tested by end users (or

representatives) to determine readiness for deployment.

Types of Test

• Some of the most common types of test include:– Benchmark test

• Assesses the performance of a target-of-test against a known standard such as existing software or measurement(s)

– Configuration test• Assesses how the target-of-test functions on different test

configurations (hardware or software)

– Functional test• Assesses how the target-of-test functions execute the required use

case as intended

– Installation test• Assesses how the target-of-test installs on different configurations or

under different conditions, such as insufficient disk space

Types of Test (cont.)

• Integrity test– Assesses the target-of-test's reliability, robustness, and resistance to

failure during execution

• Load test– Assesses the acceptability of the target-of test's performance under

varying operational conditions, such as number of users, number of transactions, etc., while the configuration remains constant

• Performance test– Assesses the acceptability of the target-of-test's performance using

various configurations while the operational conditions remain constant

• Stress test– Assesses the target-of-test's performance when abnormal or extreme

conditions are encountered, such as diminished resources or an extremely high number of users

Regression Testing

• Regression testing is a test strategy in which previously executed tests are reexecuted against a new version of the target-of-test to ensure that the quality of the target has not regressed (moved backward) when new capabilities have been added.

• The purpose of the regression test is to ensure two things:– The defects identified in the earlier execution of test have been

addressed.– The changes made to the code have not introduced new defects

or reintroduced old ones.

• Some regression testing is performed during each iteration, rerunning tests from prior iterations.

Roles & Artifacts in Test Discipline

Roles in Testing

• The Test Manager – Responsible for the overall test effort's success.

• The Test Analyst – Responsible for:

• identifying and defining the required tests,

• monitoring detailed testing progress,

• evaluating overall quality experienced as a result of testing activities.

• The Test Designer – Responsible for defining the test approach and ensuring its

successful implementation.

• The Tester – Responsible for executing the system tests.

Artifacts & their relationships in Test discipline

Keys Artifacts in Testing

• These are the key testing artifacts:

– The Test Plan • contains information about the purpose and goals of testing for the

project within its schedule.

– The Test Analyst • maintains a Test Ideas List, an enumerated list of ideas, often partially

formed, that identify potentially useful tests to conduct.

– The Test Cases, • specify a test, its conditions for execution, and associated Test Data.

– Test Scripts • manual or automated procedures used by Tester to execute the tests.

• Test Scripts may be assembled into Test Suites.

Keys Artifacts in Testing (cont.)

– A Workload Analysis Model • A special kind of Test Case for performance testing

• it identifies the variables and defines their values used in the different performance tests to simulate or emulate the actor characteristics and the end user's business functions (use cases), their load, and their volume.

– The Test Log• raw data captured during the execution of Test Suites.

• Test logs are filtered and analyzed to produce Test Results, from which change requests are raised, documenting defects or enhancement requests

Test Workflow

Tool Support

• The Rational Suite of software development tools supports test automation and Test discipline as follows:– Rational TestStudio ® is a suite of tools that support the

implementation, execution, and evaluation of tests.– Rational Test Realtime ® is a cross-platform solution for component

testing and runtime analysis.– Rational XDE Tester ®, integrated with Rational XDE® for Java and

Web testing.– Rational PerformanceStudio ® implements and executes virtual user

(VU) test scripts for performance and limited functional tests.– Rational PurifyPlus ® supports the test discipline with the following

tools:• Rational Purify ® for locating hard-to-find runtime errors• Rational PureCoverage ® to identify untested code and perform code-

coverage analysis• Rational Quantify ® to pinpoint performance bottlenecks

Summary

• Testing enables assessment of the quality of product being produced.

• Testing in an iterative process occurs in all phases of the lifecycle, enabling early feedback on product quality to be used to improve the product as it is designed and built.

• Quality is everyone's responsibility. Quality is not produced by a quality-assurance or testing organization.

• The test workflow provides a project feedback mechanism, enabling quality to be measured and defects to be identified and resolved before they become unworkable.

• Testing activities begin early in the project, with test planning and some assessment occurring even in the inception phase, and continue throughout the project.

Software Engineering

Maintenance Phase

Why Maintenance Is Necessary

• There are three main reasons for making change to the product:

– To correct any residual faults• specification faults, design faults, coding faults, documentation faults,

etc.

– To improve the effectiveness of product• The client may wish to have additional functionality added or to modify

the product so that it runs faster.

– To react to changes in environment in which the product operates.• A product is ported to a new compiler, operating system, hardware.

• A change to the tax code, zip-code system, etc.

Corrective Maintenance

Perfective Maintenance

Adaptive Maintenance

What Is Require of Maintenance Programmers

• Maintenance is the most difficult of all aspects because it incorporates aspects of all phases of the software process.

• Maintenance programmer needs to have far above average debugging skills because the fault could lie anywhere within the product.

• The fault must be fixed without introducing another fault elsewhere in the product (regression fault).

• Maintenance programmer must go through all phases.• In some cases, change may be applied to specification,

design, and implementation. Thus, maintenance programmer must be an expert in all three area.

Management of Maintenance

• Issues regarding management of maintenance

– Fault Reports– Authorizing changes to the product– Ensuring maintainability– Problem of repeated maintenance

Fault Reports

• If the product appears to be functioning incorrectly, a fault report should be filed by the user.– It must include enough information to enable the maintenance

programmer to recreate the problem.

• Unless the fault is critical, such as if a payroll product crashes the day before payday, it is cheaper to – make a number of changes, test them all, change documentation

and then install new version

• This is true, especially, if the software is used by a large number of clients.

• Thus, organizations prefer to accumulate the noncritical maintenance tasks and then implement the changes as a group.

Authorizing Changes to the Product

• The fix must be tested for the whole product (regression testing)

• Documentation must be updated to reflect the changes.– A detailed description of what was changed, why, by whom, and

when, must be added to prologue comments of any changed module– If necessary, the design and/or specification documents also have to

be changed

• The product must be approved by the Software Quality Assurance (SQA) group before it is distributed.

Ensuring Maintainability

• A well-written product will go through a series of versions over its lifetime.

• It is necessary to plan for maintenance during the entire software process.– Product should be designed and implemented for future

maintenance.

• Documentation should be complete and correct.

• During maintenance phase, it is important not to compromise the maintainability.

Problem of Repeated Maintenance

• One of the most frustrating difficulties of product development is the moving target problem.– As developer constructs product, client changes the

requirements.

• The more a completed product is changed, the more it will deviate from its original design, and the more difficult it will become to make further changes.

• As a result, regression testing files may not be up to date.

Reverse Engineering

• It sometimes happens that the only documentation available for maintenance is the source code itself.

• One way of handling this problem is to start with the source code and attempt to recreate the design documents , or even the specifications.– This process is call reverse engineering.

• The design can be recovered from the source code, then the specification may be reconstructed.

• Within the context of reverse engineering– The usual development process is called “forward engineering”.– The process of reverse engineering followed by forward

engineering is sometime called “reengineering”.

Restructuring

• A related activity that is often performed during the maintenance phase is restructuring.

• Reverse engineering takes the product from a lower level of abstraction to a higher level of abstraction.– For example, from code to design.

• Forward engineering takes the product from a higher level of abstraction to a lower level.

• Restructuring, however, takes place at the same level.– It is the process of improving the product without changing it

functionality.

Reverse Compiler

• The worse situation occurs if the source is lost, and the executable version is all that is available.

• The recovery of the source code may be performed by:– Using a disassembler to create assembler code.– Then, using reverse compiler to try to recreated the original high-

level language code.

• Many problems still remain from reverse compiler:– The name of variables have been lost.– Many compilers optimize the code, making it difficult to recreate

the original source code.– A loop in the assembler could correspond to a number of different

possible constructs in the source code.

Testing During Maintenance

• A change to one module may seriously affect one or more other modules, and hence the product as a whole.

• Regression testing should be performed to test the changed product against previous test cases to ensure that it still works correctly.

• It is vital to store all test cases, with their expected outcomes,– Changes made to product may lead to modification of the test cases

• Regression testing may seem to be a waste of time but the introduction of regression faults are too great to bear.

CASE Tools for Maintenance

• It is useful for tracking revision number each time a module is updated. Version control tool is needed: – sccs (source code control system)– rcs (revision control system) – CVS (concurrent version system)– Subversion, etc.

• CASE tools that can assist in reverse engineering and reengineering may be needed:– Battlemap – Teamwork– and Bachman Reengineering Product Set.