Software Engineering Process II

1
Software Engineering Process II

• Product Implementation
• INFO 637
• Glenn Booker

2
Implementation Process

• The Implementation phase includes
• Detailed (low level) design
• Actual coding and product implementation
• Unit testing

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

4
Design Levels

• From largest to smallest, the levels of design
  are (here) called
• System
• Subsystem
• Product
• Component
• Module

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

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 isnt affected
• Pieces may be implemented in parallel if the
  design permits and time is essential

7
Implementation Standards

• Standards again play an important role in
  implementation
• This could include using external industry
  standards, or developing your organizations own
  internal standards
• For example, IBM has an internal standard for
  counting LOC

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

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)

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

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

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

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

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)

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

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

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

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

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)

20
Quality Map Regions