CS8113g: Introduction

1
SQA 1Formal Technical Reviews
Engineering quality
2
Agenda

• Questions
• modified lecture schedule
• no testing readings, new Brooks chapter
• student note-taking and C2000
• Software Quality Assurance
• Testing overview
• Formal Technical Reviews

3
Software Quality Assurance

• Roots in early 1900s
• manufacturing (Bell Labs 1915)
• 50s-60s software
• programmer responsibility
• 70s
• military required organizations
• 80s-90s
• ISO 9000, SEI CMM

4
SQA activities

• SQA usually a separate entity
• Formal technical reviews
• Testing
• Enforce standards/methods/tools
• Configuration management
• Record-keeping/measurement reporting

5
Testing

• A whole course can be devoted to this
• Brooks views
• Lifecycle view

6
Brooks comments

• Ch. 13
• Integration produces most pernicious bugs
• mismatch of interfaces
• Importance of control in testing
• Testing begins with specification/plan

7
Life cycle issues

• Takes up 40-50 of real project development time
• The intent is to find errors
• a good test case has high probability of
  discovering error
• a good test finds an as yet undiscovered error

8
Two testing activities

• Verification
• correct implementation of a function
• Validation
• link to customer requirements

9
Recall the V-model

• Pfleeger, p. 52
• coordinating development and testing

10
Formal Technical Reviews

• Stylized meetings to filter problems in
• requirements
• design/architecture
• code
• Artifact walkthroughs

11
New in 3302...

• You will do a design review
• should perform review next week
• evidence of review turned in with Design Doc.
• 4-member teams do not have to do this

12
Purpose of technical reviews

• V ariation management
• E rror prevention
• S tandards checks
• T rain junior staff

13
Review guidelines

• keep attendees low
• internal and external
• assure advance preparation
• 24 hours minimum lead time
• limit review time
• 2 hours

14
How to meet guidelines

• Focus review on artifcat
• product, not producer
• Appoint review leader and team
• Insist upon advance preparation

15
Uncover vs. Solve

• Review is to uncover problems
• not to fix them
• Set agenda and stick to it
• Limit debate and rebuttal
• Take written notes, aided by checklists
• Assign follow-up responsibility

16
Review team

• Facilitator/Organizer
• Recorder
• Artifact producer
• Internal/external reviewers

17
Requirements review

• Did anyone do this?
• What problems resulted
• Lack of customer contact a problem.

18
Macroscopic vs. Microscopic

• Review should focus on macro issues
• Reviewers should provide micro comments separately

19
Microscopic issues

• spelling/grammar
• persuasive connectors (certainly)
• vague terms (sometimes)
• incomplete lists (etc.)
• demand proof for certainty

20
Macroscopic issues

• Completeness
• Clarity
• Correct scope
• Realistic
• Omissions
• Effective diagrams
• Consistent language

21
3302 Design Review

• See template on Web
• Done in coordination with Design Doc.
• Should be performed on pre-V 1.0 of Design Doc.