Download
1 / 20
200 likes | 345 Vues
Software Engineering Process II. Product Implementation INFO 637 Glenn Booker. Implementation Process. The Implementation phase includes: Detailed (low level) design Actual coding and product implementation Unit testing. Check High Level Design.
E N D
Software Engineering Process II Product Implementation INFO 637 Glenn Booker Lecture #7
Implementation Process • The Implementation phase includes: • Detailed (low level) design • Actual coding and product implementation • Unit testing Lecture #7
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
Design Levels • From largest to smallest, the levels of design are (here) called: • System • Subsystem • Product • Component • Module Lecture #7
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
