1. Implementation & Integration Phase Implementation, then integration: Implementation, then integration:  Each module is implemented by member of programmer team and tested by SQA;  Then, the modules are put together and tested as a whole.  Weaknesses: no fault isolation/ major design faults show up later

2. Top-down implementation and integration  E.g., (a, b, c, d, e, f, g, h, i, j, k, l, m)  E.g., (a, b, e, h, c, d, f, i, g, j, k, l, m)  Code and test the logic modules before coding and testing the operational modules  logic modules: incorporate the decision-making flow of control aspects of the product (a, b, c, d, g, j)  operational modules: perform the actual operations of the product (e, f, h, i, k, l, m)

3. Top-down implementation and integration  Strengths:  major design faults show up early  fault isolation Weaknesses: potentially reusable modules (operational modules) are not adequately tested. Weaknesses: potentially reusable modules (operational modules) are not adequately tested.

4. Bottom-up implementation & integration  E.g., (l, m, h, i, j, k, e, f, g, b, c, d, a)  E.g., ((h, e, b), (i, f, c), (l, m, k, g), d, a)  Strengths:  fault isolation  potentially reusable modules are adequately tested  Weaknesses: major design faults show up late

5. Sandwich implementation and integration  Logic modules: a, b, c, d, g (implemented and integrated top-down)  Operational modules: e, f, h, I, k, l (implemented and integrated bottom- up)  Strengths: fault isolation, major design faults show up early, potentially reusable modules are adequately tested

6. Implementation & integration of object oriented products  Top-down implementation and integration: stubs are used for each method in the same way with classical methods.  Bottom-up implementation and integration: the objects that do not send any message to other objects are implemented and integrated first, then other.  Sandwich implementation and integration: class methods are implemented top-down and then integrated with other objects.

7. Implementation & integration testing  The CASE tool runs each test case in turn, compare the actual results with the expected results, reports to the user on each case  Automated testing (special script) for GUI proceeds as if there were no GUI (e.g., QAPartner, Xrunner)

8. Production Test  COTS (shrink-wrapped) software: to ensure that the product as a whole is free of faults.  Acceptance test for custom software by SQA group  Must run Black-box test cases for the product as a whole (module-by-module, object-by- object)  Must test the robustness of the product as a whole (stress testing, volume testing)

9. Production Test  Must check that the product satisfies all its constraints  Must review all documentation that is to be handed over to the client  Inspect on a scenario-by-scenario basis to ensure that the behavior of the product is precisely as specified (useful for object-oriented software)

10. Acceptance Test  For client to determine whether the product indeed satisfies its specifications as claimed by the developer (SQA group)  It must be performed on actual data.  When a new product is to replace an existing product, both products must run in parallel until the client is satisfied with the new product.  When the product has passed its acceptant test, the task of the developers is complete.

11. CASE Tools for the Implementation & Integration  A single tool (online interface checker or build tool)  Workbench: combined tools; support one or two activities within the software process (configuration control or coding)  Environment: provides computer-aided support for most of the process

12. Integrated Environment User interface integration User interface integration Process Integration: the environment supports one specific software process (technique based environment) Process Integration: the environment supports one specific software process (technique based environment)  Formalization of the manual processes for software development  Forces users to utilize the technique step by step in the way intended by its author, providing graphical tools, a data dictionary, and consistency checking

13. Integrated Environment  Stick to a specific technique and use it correctly  E.g., Rose (UML), Analysis/Designer (Yourdon’s methodology), Statemate (Statecharts)

14. Integrated Environment Tool Integration: all the tools communicate via the same data format  Data stream tool integration: UNIX programmer’s workbench (the input and output from each individual tool is an ASCII stream)

15. Integrated Environment Front-end tool integration: via a common front end into which all the tools are embedded  SoftBench: (metaCASE tool) [Riehle, 1991]  A tool sends a message to another tool to request on performing an action; if a test fail, send a message to mail tool telling it to inform the manager as which test failed.  In order to achieve integration, the front end may have to transform the way data are stored by one tool so that information can be used by a different tool

16. Integrated Environment Back-end tool integration:  All tools are interfaced with a common back end (software project database)  Integrated CASE tools modify the common data stored in the repository.  Well defined interface between repository and tools are required.

17. Integrated Environment Team integration: the CASE environment promotes effective team coordination and communication Team integration: the CASE environment promotes effective team coordination and communication Management integration: the CASE environment supports management of the process (report, plans, contracts, etc) Management integration: the CASE environment supports management of the process (report, plans, contracts, etc)