The Unified Software Development Process: Classification of Iterations

1
The Unified Software Development Process
Classification of Iterations

• Inception iterations preliminary interaction
  with stakeholders
• primarily customer
• users
• financial backers etc.
• Elaboration iterations finalization of whats
  wanted and needed set architecture baseline
• Construction iterations results in initial
  operational capability
• Transition iterations completes product release

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
2
USDP vs. Standard Terminology ½ (Booch, Jacobson
Rumbaugh)
Classification of iterations
Individual iteration
Elaboration
Inception
Construction
Transition
Iter. k
Iter. 1
Iter. n
Iter. n1
Iter. m
Iter. m1
Prelim. iterations
..

..
Requirements Analysis
USDP calls these core workflows (Classically
called phases)
Design Implemen- tation Test
3
Unified Process Matrix
Jacobson et al USDP
Elaboration
Inception
Construction
Transition
Prelim. iterations
Iter. 1
Iter. n
Iter. n1
Iter. m
Iter. m1
Iter. k
..
..
..
Requirements Analysis
Amount of effort expended on the requirements
phase during the first Construction iteration
Design Implemen- tation Test
4
The Six USDP Models (Views of the Application)
Use-case model
Test model
Analysis model
Implementation model
Design model
Deployment model
Graphics reproduced with permission from Corel.
5
Undocumented Code
int a( int i, char c ) if( c m ) if( ilt
1000 ) return 0 else if( ilt 10000 )
return 500 else return
1200 else return 1300
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
6
Somewhat Documented Code
int tax( int anEarning, char aStatus ) if(
aStatus m ) if( anEarning lt 1000 )
return 0 // no tax for married, lt
1000 else if( anEarning lt 10000 )
return 500 // married, 1000-10000 else
return 1200 // married, gt10000 // If not
married, apply single tax rate of 1300
regardless else return 1300
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
7
Documented Code
/ This method implements requirement 4.3
State tax effective 9/1/98 -12/31/99
_at_author Eric J. Braude _at_version 2.3.4
(8/6/98) _at_param anEarning earnings 9/1/98
thru 12/31/99 _at_param aStatus m signifies
married (anything else designates
unmarried) / int tax( int anEarning, char
aStatus )
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
8
Project Documentation
SVVP software validation verification plan
Verification validation
SQAP software quality assurance plan
Quality assurance
SCMP software configuration management plan
Configuration
SPMP software project management plan
Project status
Customer-oriented
SRS software requirements specifications
Requirements
Developer-oriented
SDD software design document
Architecture
Design
Detailed design
Source Code
Code
STD software test documention
Testing
Users manual
Operation
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
9
Identify Your Documentation Needs
One way to ...

• 1. Document the way documents code are accessed
• otherwise, chaos results
• Software Configuration Management Plan --
  section tbd
• 2. Specify who will do what, and when they will
  do it
• Software Project Management Plan -- chapter 2
• 3. Document what is to be implemented
• for yourself, your customer, and your team
• Software Requirements Specification --
  chapters 3 and 4
• 4. Document the design of the application
• i.e., prior to programming
• Software Design Document -- chapters 5 and 6
• 5. Write and document code
• the code base -- chapter 7
• 6. Document the tests you perform
• so that they can be re-run, extended etc.
• Software Test Documentation -- chapters 8 and 9

the IEEE standard, which can be used
to organize this documentation
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
10
1. Specify how to manage project documents
2. Identify process
QAInvolvement
2. QA reviews process for conformance
to organizational policy
1. QA Develops and/or reviews configuration manag
ement plans, standards ...
QA
3. QA develops and/or reviews provision for QA
activities
4. QA reviews, inspects tests
5. QA reviews, inspects tests
5. Deliver main- tain the product
3. Plan
4. Design and build
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
11
IEEE 730-1989 Software Quality Assurance Plans
Table of Contents
1. Purpose 2. Referenced documents 3. Management
3.1 Organization 3.2 Tasks 3.3
Responsibilities 4. Documentation
4.1 Purpose 4.2 Minimum documen-
tation requirements 4.3
Other 5. Standards, practices, conventions and
metrics 5.1 Purpose 5.2 Content
6. Reviews and audits 6.1 Purpose 6.2
Minimum requirements 6.2.1 Software
requirements review
6.2.2 Preliminary design review
6.2.3 Critical design review 6.2.4
SVVP review 6.2.5 Functional audit
6.2.6 Physical audit 6.2.7
In-process audits 6.2.8 Managerial
review 6.2.9 SCMP review
6.2.10 Post mortem review 6.3 Other 7. -
15. -- see next chapter
12
IEEE 1012-1986 Software Verification validation
Plans Table of Contents (Reaffirmed 1992)
1. Purpose 2. Referenced documents 3.
Definitions 4. VV overview 4.1 Organization
4.2 Master schedule 4.3 Resource
summary 4.4 Responsibilities 4.5
Tools, techniques
methodologies 5. Lifecycle VV
5.1 Management of VV 5.2 Concept phase
VV 5.3 Requirements phase VV 5.4
Design phase VV 5.5 Implementation phase
VV
5.3 Test phase VV 5.4 Installation
checkout phase VV 5.5
Operation maintenance phase VV 6.
Software VV reporting 6.1 Required reports
6.2 Optional reports 7. VV administrative
procedures 7.1 Anomaly reporting
resolution 7.2 Task iteration policy
7.3 Deviation policy 7.4 Standards,
practices conventions
13
Produce a Quality Product
One way to ...

• 1. Quantify your quality goals
• minimum number of defects per KLOC
• team defective requirements classes missing
  from design
• defects in testing defects found in
  operation.
• personal apply defects to code, compile, unit
  test separately
• 2. Build inspections and reviews into the
  schedule
• (see scheduling, next chapter)
• follow the inspection procedure (see figure 1.27
  on page ??)
• 3. Document your quality goals and procedures
• use a documentation standard to avoid missing
  issues
• SQAP (see case study for example) If time
  allows SVVP

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
Example of Hyperlinked Documentation Set (with
Dynamic Content shown)
STP software test plan
Test results
SPMP software project management plan
Project status
SRS software requirements specifications
Direction of hyperlink
Updates
References to all other documents
Source Code
SCMP software configuration management plan
SDD software design document
Configuration
Updates
Dynamic component
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.