Transcript Software Engineering Process II Product Implementation INFO 637 Glenn Booker INFO 637 Lecture #7 Implementation Process The Implementation phase includes: Detailed (low level) design Actual coding and product.

Software Engineering Process II
Product Implementation
INFO 637
Glenn Booker
INFO 637
Lecture #7
1
Implementation Process
The Implementation phase includes:
Detailed (low level) design
Actual coding and product implementation
Unit testing
INFO 637
Lecture #7
2
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
INFO 637
Lecture #7
3
Design Levels
From largest to smallest, the levels of
design are (here) called:
System
Subsystem
Product
Component
Module
INFO 637
Lecture #7
4
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
INFO 637
Lecture #7
5
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
INFO 637
Lecture #7
6
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
INFO 637
Lecture #7
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
INFO 637
Lecture #7
8
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)
INFO 637
Lecture #7
9
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
INFO 637
Lecture #7
10
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
INFO 637
Lecture #7
11
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
INFO 637
Lecture #7
12
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
INFO 637
Lecture #7
13
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)
INFO 637
Lecture #7
14
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
INFO 637
Lecture #7
15
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
INFO 637
Lecture #7
16
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
INFO 637
Lecture #7
17
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
INFO 637
Lecture #7
18
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)
INFO 637
Lecture #7
19
Quality Map Regions
Compile
Defects/
KLOC
Not to scale!
Region IV
50
III
II and
III
I
II
10
0
0
INFO 637
5
20
Unit Test Defects/KLOC
Lecture #7
20