Implementation and Integration Phase

1
Implementation and Integration Phase

• Chapter 15

2
Separate Implementation and Integration Phases

• Problems
• Modules cannot be tested on their own
• Top modules need stubs of bottom modules
• Bottom modules need drivers
• Middle modules need stubs and drivers
• Stubs and drivers are later thrown away wasting
  effort
• Lack of fault isolation
• Solution
• Combine both phases

3
Types of modules

• Logic modules
• Incorporates decision-making flow of control
  aspects of the product
• Should be coded first to ensure design flaws are
  detected early
• Operational modules
• Perform actual operations of the product
• These are typically the reusable modules of the
  product

4
Techniques to Combined Implementation and
Integration

• Top-Down
• Bottom-Up
• Sandwich

5
Top-Down

• Possible top-down ordering
• a, b, e, h, c, d, f, i, g, j, k ,l and m
• Portions of implementation and integration can
  proceed in parallel
• a is coded and tested first
• One programmer uses a to implement b, e, h
• b is coded, linked to a, and tested with e
  implemented as a stub
• e and h are implemented and tested the same way.
• Another programmer can use a to implement and
  integrate the other branches

6
Top-down Pros and Cons

• Cons
• Operational modules are not tested adequately
• Especially true for a well-designed product that
  uses defensive programming
• Operational modules of top-down implementations
  are not reusable.

• Pros
• Eliminate the need for drivers
• Supports fault isolation
• Design flows show up early since the logic
  modules are coded first

7
Bottom-Up

• Possible top-down ordering
• h, e, and b is given to one programmer
• i, f, and c to second programmer
• l, m, j, k and g to a third programmer. When
  this programmer is done, he implements d and
  integrates his work with the second programmer
• When b, c and d are implemented and integrated, a
  can be implemented and integrated.

8
Bottom-Up Pros and Cons

• Pros
• Eliminate the need for stubs.
• Testing is done using drivers, avoids
  fault-shielding of modules through defensive
  programming.
• Supports fault isolation
• Operation modules are tested thoroughly
  supporting code reuse.

• Cons
• Major faults in design are detect late since
  logic modules are coded last
• This can result in huge cost to redesign and
  recode

9
Sandwich Implementation and Integration

• Combines top-down and bottom-up strategies to use
  their strengths and minimize their weaknesses
• a, d, c, d, g and j are implemented top-down
• e, f, h, i, k, l, and m are implemented bottom-up
  
• When all the modules are properly integrated, the
  intefaces (dashed lines) between the two groups
  are tested one by one.

10
Sandwich Implementation and Integration (cont.)

• When using this technique
• Fault isolation is supported
• Major design faults show up early
• Potentially reusable modules are tested
  thoroughly

11
Management Issues During theImplementation and
Integration Phases

• Discovering at integration time modules do not
  fit together
• Which will re-do his work?
• Make certain the SQA group runs the entire
  integration process. The SQA manager must
• be responsible for all aspects of integration
  testing
• decide which modules will be implemented and
  integrated top-down and which ones will be
  integrated bottom-up
• Assign integration testing tasks to appropriate
  individuals

12
Testing

• Each module must be tested and added to what has
  already been integrated
• Test modules as described in chapter 14
• Regression Testing - Test the partially completed
  product to make sure it behaves as it did before
  the new module was integrated

13
Test files

• Non-GUI based
• Store input data for test cases in a test file.
• Execute the product with the test file as input.
• Compare actual results with expected results
• Test files are stored and used for regression
  testing
• CASE tools available (SilkTest)

14
Test files (cont.)

• GUI based
• Need to manually open windows, pull-down menus,
  and click on icons at least once
• Since testing a GUI is time consuming and boring
• use a CASE tool to record mouse click, key
  presses and other user actions.
• Once recorded, the events are kept as a test file
  and run as often as required
• CASE tools available QAPartners and XRunner

15
Product Testing

• Performed after implementation and integration is
  completed
• Different testing goals depending on product type
• COTS
• Custom

16
COTS Product Testing

• Goal
• Ensure the product as a whole is fault-free
• Ship the product to prospective buyers to get
  feedback on residual faults
• Alpha testing
• Beta testing close to final release

17
Custom Software

• Goal
• Make sure the product will pass acceptance
  testing
• To ensure successful acceptance testing
• Perform black-box testing on the whole product
• The robustness of the product
• As a whole
• When operating under peak load stress testing
• When handed large inputs volume testing
• Make sure the product satisfies all constraints
• Review all documentation that will be handed to
  the client
• Perform scenario testing

18
Acceptance Testing

• Done by either by the client, the developer SQA
  group in the presence of the client, or an
  independent SQA group hired by the client.
• Four major components of acceptance testing
• Correctness, robustness, performance and
  documentation
• Key aspect
• Must be performed on actual data, not test data

19
CASE Tools

• Single tool
• Individual tools
• Visual C for coding and building
• ClearCase for configuration management
• Workbench
• Combined tools to support one or two activities
  of the software process
• Environment
• Supports most if not all the SW process

20
Metrics

• Total number of test cases
• Number of test case resulting in failures
• Total number of faults
• To decide if redesign and re-implementation is
  required
• Types of faults detected
• Misunderstanding the design
• Lack of initialization
• Inconsistent use of variables