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

2. INFO 637Lecture #72 Implementation Process The Implementation phase includes:  Detailed (low level) design  Actual coding and product implementation  Unit testing

3. INFO 637Lecture #73 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

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

5. INFO 637Lecture #75 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

6. INFO 637Lecture #76 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

7. INFO 637Lecture #77 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

8. INFO 637Lecture #78 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

9. INFO 637Lecture #79 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)

10. INFO 637Lecture #710 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

11. INFO 637Lecture #711 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

12. INFO 637Lecture #712 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

13. INFO 637Lecture #713 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

14. INFO 637Lecture #714 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)

15. INFO 637Lecture #715 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

16. INFO 637Lecture #716 Implementation Script IMP1 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 p. 152

17. INFO 637Lecture #717 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

18. INFO 637Lecture #718 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

19. INFO 637Lecture #719 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)

20. INFO 637Lecture #720 Quality Map Regions Not to scale! Compile Defects/ KLOC Unit Test Defects/KLOC 50 10 0 0520 Region IV II I II and III III