1. Software Engineering Process II Product Implementation INFO 637 Glenn Booker Lecture #7

2. Implementation Process • The Implementation phase includes: • Detailed (low level) design • Actual coding and product implementation • Unit testing Lecture #7

3. Check High Level Design • Before proceeding, make sure the high level design is complete • You should have subdivided the system into smaller pieces, and specified what each piece needs to do • The overall logic of the system needs to be clearly understood Lecture #7

4. Design Levels • From largest to smallest, the levels of design are (here) called: • System • Subsystem • Product • Component • Module Lecture #7

5. Detailed Design • Detailed design takes the larger level pieces (subsystems and products), and keeps breaking them into smaller and smaller pieces (component and module) until the entire system is fully specified • How small do pieces need to be? • Code modules are typically 150 LOC or less Lecture #7

6. Detailed Design • Keep repeating the design scripts (DESn) until every piece is well defined • In some cases, some pieces may be implemented before others are fully defined • This is generally okay as long as the high level structure isn’t affected • Pieces may be implemented in parallel if the design permits and time is essential Lecture #7

7. Implementation Standards • Standards again play an important role in implementation • This could include using external industry standards, or developing your organization’s own internal standards • For example, IBM has an internal standard for counting LOC Lecture #7

8. Types of Standards • Standards for file and variable names • Interface and messaging standards • Code format and style standards • Standards for finding LOC and other sizes • Defect type standards Lecture #7

9. Defect Prevention • Standards can help support defect prevention activities • In addition to defect types (code, documentation, etc.), the cause of the defects should be identified • Focus on defects which cause the biggest problems (e.g. most frequent, or most time consuming) Lecture #7

10. Defect Prevention • Defect Cause types may include • Education (language, environment, application) • Communication (then fix the process) • Transcription (then fix the tools) • Oversight (look for better methods) • Try to identify how to prevent each defect • Change the process to prevent it • And then see if it recurs Lecture #7

11. Review Strategy • While design tends to work from top down (general to specific), review work better from the bottom up • First review the lowest level parts, which call nothing else (fan out = 0) • Then review the parts which call them, and keep working up to bigger parts Lecture #7

12. Reuse Strategy • Simple things help support reuse • Use a common header format for all files, to identify what it does, what it uses for inputs, return formats • Describe all variables, their ranges, limitations, and allowable values • Remember to ask support manager if anyone has a module to meet your needs Lecture #7

13. Reviews and Inspections • This was covered in Appendix C of the text • Keep in mind that typos and other random defects can account for many defects in code (e.g. 28 defects/KLOC for the author) • Many not caught by compiler • Many not logical, hence hard to anticipate • Hard for tests to catch every possible logical path, data value, and operating condition Lecture #7

14. Design Inspections • Detailed designs need to be inspected • Re-inspection later on is not needed unless the fundamental design changed • Code reviews are often more effective at catching defects than testing • Use a code review checklist to ensure consistent and complete reviews (PSP p. 706) Lecture #7

15. Implementation Scripts • To start implementation, need: • Completed development strategy and plan • Completed SRS and SDS • A defined coding standard • Other standards, common terminology, and specifications Lecture #7

16. Implementation Script IMP1 p. 152 • Plan implementation tasks using SUMP and SUMQ • Allocate tasks to team members • Conduct detailed design • Do design review using LOGD and LOGT • Create unit test plan, test cases, procedures, and test data Lecture #7

17. Implementation Script IMP1 • Inspect the detailed design for each component using INS and LOGD • Create the code, and review it using code checklist • Record defects using LOGD and LOGT • Do formal code inspection using INS and LOGD Lecture #7

18. Implementation Script IMP1 • Have quality manager verify every component • Release accepted components • Hence the outputs from this script are: • Completed code • Forms INS, SUMP, SUMQ, LOGD, and LOGT • Test plans and materials (test cases, etc.) • Updated project notebook Lecture #7

19. Quality Map • Judge component quality using the regions shown on the following slide: • Zone I means quality is acceptable • Zone II means design needs to be re-inspected • Zone III means code needs to be re-inspected • Zone IV means program needs to be reworked (start design over) Lecture #7

20. CompileDefects/ KLOC Not to scale! Region IV 50 II and III III 10 II I 0 Unit Test Defects/KLOC 0 5 20 Quality Map Regions Lecture #7