1. Page 1 MODEL TEST in the small GENERALIZE PROGRAM PROCESS allocated maintenance changes management documents initial requirement project infrastructure project funding project charter potential roles during this phase: project manager software application documentation requirement allocation matrix models, source code management documents team leader software conf. manager test manager architectural modeler domain programmer subject matter expert quality assurance engineer domain modeler mentor infrastructure engineer technical writer component engineer reuse engineer test engineer proof-of-concept engineer from maintain & support phase CONSTRUCT PHASE The main goal of the construct phase is to build working software that is ready to be tested and delivered to its user community.

2. Page 2 MODEL ARCHITECTU- RAL MODELING requirement documentation modeling standards TECHNICAL MODELING HUMAN INTERACTION DOMAIN MODELING PROBLEM DOMAIN MODELING MANAGE METRICS TASK MODELING models (diagrams, docs) test plan requirement alloc. matrix The developers first need to understand what the are supposed to build. This “software analysis and design” process should be performed iteratively, because of developers do not need to do all of the analysis first time, then do all of the design and then all of the coding.

3. Page 3 PROGRAM PROCESS UNDERSTAND MODELS models project infrastructure MAKE SOURCE CODE PREPARE PROJECT INTEGRATION PLAN PREPARE CODE FOR INSPECTIONS INTEGRATE AND PACKAGE INTEGRATE AND PACKAGE SYNCHRONIZE SOURCE CODE WITH MODELS packaged application source code software components OPTIMIZE CODE BUILD SOFTWARE APPLICATION REUSE EXISTING CODE AND COMPONENTS DOCUMENT SOFTWARE APPLICATION DOCUMENT SOURCE CODE PERFORM METRICS During this process the source code is written, documented, reviewed, tested and packaged for delivery. For this to be successful, the models must drive the development of the source code. This process is far more to writing source code of programs.

4. Page 4 GENERALIZE IDENTIFY POTENTIAL REUSABLE ITEMS project deliverables HOLD GENERALIZA- TION SESSIONS RELEASE MAKE DOCUMENTA- TION PERFORM METRICS REFACTOR CODE reusable items This is the recognition that the short-term pressures of software development result in the temptation for developers to settle for specific, non-reusable solutions. In this process, application specific items are identified and then reworked to be reusable by other development teams.

5. Page 5 TEST IN THE SMALL DEVELOP TEST PLAN DEVELOP TEST PLAN models source code requirements master test quality assurance plan SCENARIO AND PROCESS TEST RECORD DEFECTS WALK- THROUGH MODELS WALK- THROUGH MODELS USER INTERFACE TESTING PROGRAM CODE TESTING PROGRAM CODE TESTING REVIEW TECHNICAL DESIGN INSPECT SOURCE CODE REVIEW PROTOTYPES tested artifacts test results master test quality assurance plan This process focuses on the verification, validation, and testing of documents, models, and source code produced. In many ways it is quality assurance techniques such as peer reviews and inspections combined with unit testing techniques for validating code.

6. Page 6 CONSTRUCT to be performed checklist  the models for the application have been developed and validated  the source code for the application have been developed and validated  reusable artifacts have been identified  potential artifacts to be generalized for reuse have been identified and potentially generalized  user documentation has been developed  decisions (both made and forgone) were documented into group memory  metrics have been collected

7. Page 7 CONSTRUCT exit conditions checklist  requirement allocation matrix has been updated  project plan was updated appropriately  models, source code and documentation were baselined  test plan has been updated for for the test in the large  user, support and operations documentation is ready for testing  application has been packaged for testing  training, release, and project plans have been updated appropriately

8. CONSTRUCT PHASE model

9. Page 9 Model entrance conditions checklist  initial requirements have been documented and accepted  modeling and programming tools were prepared  subject matter experts have been scheduled  team members have been given the appropriate training

10. Page 10 Model to be performed checklist  models were assembled and validated  user interface prototype was developed and validated  assumptions made during modeling were challenged and documented appropriately  manual processes, legacy applications, and new system development was identified and modeled accordingly  requirement allocation matrix was updated/developed  reusable artifacts have been identified and used  risk assessment document has been updated  decisions (both made and forgone) were documented into group memory  metrics have been collected

11. Page 11 Model exit conditions checklist  models have been appropriately documented  models have been validated  test plan has been updated  models have been accepted by the team  models have been accepted by senior management

12. CONSTRUCT PHASE program

13. Page 13 Program entrance conditions checklist  appropriate models are available  development tools are installed  professional programmers are available  team members have appropriate training

14. Page 14 Program to be performed checklist  programmers worked with the designers to understand models  source code was written and documented  source code was synchronized with models  source code was prepared for inspection during test in the small  integration plan was prepared  reusable artifacts have been used  risk assessment document has been updated  decisions (both made and forgone) were documented into group memory  metrics have been collected

15. CONSTRUCT PHASE generalize

16. Page 16 Generalize entrance conditions checklist  project deliverable  experienced reuse engineers are available  organizational support for reuse exists  team members have been given the appropriate training

17. Page 17 Generalize to be performed checklist  potential reusable items have been identified  generalization sessions were held  potentially reusable items were refactored  reusable items were documented  examples of how to reuse reusable items were documented  reusable items were released into the repository and made accessible to all developers  risk assessment document has been updated  decisions (both made and forgone) were documented into group memory  metrics have been collected

18. Page 18 Generalize exit conditions checklist  generalized items have been submitted to the reuse repository  all developers have been made aware of new items

19. CONSTRUCT PHASE Test in the small

20. Page 20 Test in the small entrance conditions checklist  there are artifacts to be tested  test plan exists  requirements have been documented  team members have appropriate training

21. Page 21 Test in the small to be performed checklist  test plan was updated appropriately  models were reviewed and walked through and accepted  user interface prototypes were reviewed and tested  source code was inspected and improved before being tested  perform software testing  defects were recorded and analyzed  risk assessment document has been updated  decisions (both made and forgone) were documented into group memory  metrics have been collected

22. Page 22 Test in the small exit conditions checklist  all items have been tested, reviewed and updated accordingly  master test has been updated for “test in the large”