1. 1 PROCESS

2. Software Engineering Roadmap: Chapter 1 Focus
Identify corpor-
ate practices
- assess capability
- specify standards
- e.g. CMM level
Plan
project
Analyze
requirements
Maintain
Development
phases
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Software Engineering Roadmap: Chapter 1 Focus
Plan configuration
management
- how to manage documents & code
- document: SCMP
Plan quality
assurance
- how to ensure quality
- document: SQAP
Identify corpor-
ate practices
- assess capability
- specify standards
- e.g. CMM level
Plan verification
& validation
- verify the product
satisfies requirements
- validate each phase by
showing it succeeded
document: SVVP
next chapter: Plan
development process
Plan
project
Analyze
requirements
Maintain
Development
phases
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. Chapter Learning Goals
Goals of this chapter
One goal of this chapter is to distinguish between the software process that software engineers utilize and the projects that they build. The other goal is to outline the challenges that each of these presents.
Distinguish among development processes
Indicate benefits and disadvantages
Define software “quality” quantitatively
Institute collection
Understand documentation needed
Approximately one for each waterfall phase
Plan for configuration management
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

5. 1. Introduction to the software engineering process

6. Some Application Types
Stand-alone
residing on a single computer
not connected to other software or hardware
e.g., word processor
Embedded
part of unique application involving hardware
e.g., automobile controller
Realtime
functions must execute within small time limit
typically microseconds
e.g., radar software
Network
consist of parts interacting across a network
e.g., Web-based video game
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. Typical Project Roadmap
1. Understand nature & scope of proposed product
2. Select the development process, and create a plan
-- section 4 and chapter 2
3. Gather requirements
-- chapters 3 and 4
4. Design and build the product
-- chapters 5, 6, and 7
5. Test the product
-- chapters 8 and 9
6. Deliver and maintain the product
-- chapter 10
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8. 2. Historical and contemporary perspectives on software engineering process

9. Structured Programming
Function definition handleAccount(…)
getDetailsFromUser(…)
getAccount(…)
doTransaction(…) ……
Function definition getDetailsFromUser (…)
getName(…)
…...
Function definition getAccount(…)
getFirstName(…)
TOP
DOWN
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

10. Customer Transaction Account
Object Orientation
Real world concepts
Skljkvjkvjfkavjafkk
saovjsdvjfvkfjvkfjk
Direct correspondence
Customer
getFirstName()
Transaction
execute()
Account
getDetails()
Software design entities
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.

11. account COM object The COM Idea Computation interface
Identification interface
getName()
setName()
getSSN()
setSSN()
Asset interface
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

12. 3. Expectations for process, project, product and people

13. Five Key Expectations (Humphrey)
1. Predetermine quantitative quality goals
Five Key Expectations (Humphrey)
Used for
process
development
Part of
the
project
2. Accumulate data for subsequent use
3. Keep all work visible
4. A. Design only
against requirements
B. Program
only against designs
C. Test only against
requirements and designs
Aspect
of the
product
Influenced
by people
5. Measure quality

14. Artifacts and Roles
USDP term
Symbol & examples
Artifacts: the entities that software engineering deals with.
Document
Model
-- a view
of the
application
(design etc.)
Component
-- physical
(source
code etc.)
Workers: responsibilities allocated to people (roles).
Worker
Worker instance
(e.g., Joe Smith)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

15. 4. Process alternatives

16. The Waterfall Model Requirements analysis Design Implementation
Produces … specification (text)
Design
... diagrams & text
... code & comments
Implementation
... entire code
Integration
Test
... test report, including defect descriptions
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

17. More Detailed Waterfall Version
Concept
analysis
More Detailed Waterfall Version
Analysis
Design
Implementation
& unit testing
Integration
System
testing
Maintenance
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18. Product: requirements specifications Product:class models +
Spiral Development
Product: requirements
specifications
Product:class
models +
Step n:
Analyze
requirements
Step n+1: Design
complete
targeted
requirements
Step n+2: Implement
Step n+3: Test
Product: code +
Product: test results +
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19. Incremental Development
Iteration No. 1 2 3
867
868
Update SPMP1
Test whole
Integrate
Update Test documentation
Test units
Update source code
Implement
Design
Update SDD2
Analyze
requirements
Update SRS3
1 Software Project Mangement Plan (chapter 2); Software Design Document (chapter 5);
3 Software Requirements Specification (chapter 3);
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

20. The Unified Software Development Process: Classification of Iterations
Inception iterations: preliminary interaction with stakeholders
primarily customer
users
financial backers etc.
Elaboration iterations : finalization of what’s 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.

21. USDP vs. Standard Terminology ½ (Booch, Jacobson & Rumbaugh)
Classification of iterations
Individual iteration
Inception
Elaboration
Construction
Transition
Prelim.
iterations
Iter. #1
Iter. #n
Iter.
#n+1
Iter. #m
Iter.
#m+1
Iter. #k ..
….. …
Requirements
Analysis
USDP calls these
“core workflows”
(Classically called “phases”)
Design
Implemen-
tation
Test

22. USDP vs. Standard Terminology 2 of 2
USDP Terminology
Classical Terminology
Requirements
Analysis
Requirements analysis
Design
Implementation
Test
Design
Implementation
Integration
Test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

23. Unified Process Matrix
Jacobson et al: USDP
Inception
Elaboration
Construction
Transition
Prelim.
iterations
Iter. #1
Iter. #n
Iter.
#n+1
Iter. #m
Iter.
#m+1
Iter. #k ..
…..
…..
Requirements
Analysis
Amount of effort expended
on the requirements phase
during the first Construction
iteration
Design
Implemen-
tation
Test

24. 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.

25. Identify the Process You Will Use
One way to ...
1. Decide which of waterfall, spiral, and incremental processes is appropriate.
Usually a spiral for a semester project.
Combining parts is OK e.g. start with spiral, end with incremental
2. Decide how many iterations.
Usually two for a semester project (there are many artifacts to coordinate at the end of each iteration).
Three provides lots of practice -- but this is a challenge; make the first increment as minor as possible
Three promotes the collection and use of metric data -- use metric data collected from each iteration on next.
3. Rough out a weekly schedule.
Coordinate with course assignments.
(The next chapter discusses scheduling.)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

26. 5. Documentation

27. Undocumented Code int a( int i, char c ) { if( c== “m” )
if( i< 1000 )
return 0;
else
if( i< )
return 500;
return 1200;
return 1300; }
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28. Somewhat Documented Code
int tax( int anEarning, char aStatus ) {
if( aStatus == ‘m’ )
if( anEarning < 1000 )
return 0; // no tax for married, < $1000
else
if( anEarning < )
return 500; // married, $1000-$10000
return 1200; // married, >=$10000
// If not “married”, apply single tax rate of $1300 regardless
return 1300; }
Somewhat Documented Code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

29. * This method implements requirement 4.3:
Documented Code
/**
* This method implements requirement 4.3:
* “State tax effective 9/1/98 -12/31/99”
Eric J. Braude
(8/6/98)
anEarning: earnings 9/1/98 thru 12/31/99
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.

30. 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
Project Documentation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

31. 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
Architecture
SDD
software design document
Design
Detailed design
Code
Source Code
Project Documentation
STD
software test documention
Testing
Operation
User’s manual
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

32. 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.

33. 6. Quality

34. QA QA Involvement 2. QA reviews 1. QA Develops process for
1. Specify how to manage
project documents
2. Identify process
QA Involvement
2. QA reviews
process for
conformance to
organizational
policy
1. QA Develops
and/or reviews
configuration
management
plans, standards ... QA
3. QA develops
and/or reviews
provision for
QA activities
5. QA reviews,
inspects & tests
4. QA reviews,
inspects & tests
5. Deliver & main-
tain the product
4. Design and build
3. Plan
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

35. Principle of Inspection
AUTHORS CAN USUALLY
REPAIR DEFECTS
THAT THEY RECOGNIZE
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. Principle of Inspection
AUTHORS CAN USUALLY
REPAIR DEFECTS
THAT THEY RECOGNIZE
COROLLARY:
Help authors to recognize defects
before they deliver their work.
COROLLARY:
Have their peers seek defects.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

37. Inspection Process & Example Times
Nominal process
1. PLANNING
OVERVIEW
process
Non-nominal
2. PREPARATION
CAUSAL
ANALYSIS
3. INSPECTION
4. REWORK
Inspection Process & Example Times
5. FOLLOW-UP
6. IMPROVE PROCESS
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

38. Time/Costs per 100 LoC* -- one company’s estimates
Planning 1 hr  (1 person)
[ Overview 1 hr  (3-5) ]
Preparation 1 hr  (2-4 people)
Inspection meeting 1 hr  (3-5 people)
Rework 1 hr  (1 person)
[ Analysis hr  (3-5) ]
Total: approx person-hours
* lines of non-commented code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

39. Hours Per Defect: One estimate
If defect found ...
… at inspection … at integration
time time
Hours to ..
.. detect to to 10
.. repair to
Total to to 19+
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

40. Prepare For & Conduct Inspections
One way to ...
Prepare For & Conduct Inspections
1. Build inspections into the project schedule
plan to inspect all phases, starting with requirements
allow for preparation (time consuming!) & meeting time
2. Prepare for collection of inspection data
include # defects per work unit (e.g., KLOC), time spent
develop forms: include description, severity and type
decide who, where, how to store and use the metric data
default: appoint a single person to be responsible
failure to decide usually results in discarding the data
3. Assign roles to participants
Three adequate (author; moderator/recorder; reader)
Two far better than none (author; inspector)
4. Ensure every participant prepares
bring defects pre-entered on forms to inspection meeting
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

41. 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
IEEE Software Quality Assurance Plans Table of Contents

42. 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
Post mortem review
6.3 Other
see next chapter

43. are we building the thing right? Validation:
Meaning of “V&V” (Boehm)
Verification:
are we building the thing right?
Validation:
are we building the right thing?
Graphics reproduced with permission from Corel.

44. 5.3 Requirements phase V&V 5.4 Design phase V&V
IEEE Software Verification & validation Plans Table of Contents (Reaffirmed 1992)
1. Purpose
2. Referenced documents
3. Definitions
4. V&V overview
4.1 Organization
4.2 Master schedule
4.3 Resource summary
4.4 Responsibilities
4.5 Tools, techniques &
methodologies
5. Lifecycle V&V
5.1 Management of V&V
5.2 Concept phase V&V
5.3 Requirements phase V&V
5.4 Design phase V&V
5.5 Implementation phase V&V

45. 5.3 Requirements phase V&V 5.4 Design phase V&V
IEEE Software Verification & validation Plans Table of Contents (Reaffirmed 1992)
1. Purpose
2. Referenced documents
3. Definitions
4. V&V overview
4.1 Organization
4.2 Master schedule
4.3 Resource summary
4.4 Responsibilities
4.5 Tools, techniques &
methodologies
5. Lifecycle V&V
5.1 Management of V&V
5.2 Concept phase V&V
5.3 Requirements phase V&V
5.4 Design phase V&V
5.5 Implementation phase V&V
5.3 Test phase V&V
5.4 Installation & checkout
phase V&V
5.5 Operation & maintenance
6. Software V&V reporting
6.1 Required reports
6.2 Optional reports
7. V&V administrative
procedures
7.1 Anomaly reporting &
resolution
7.2 Task iteration policy
7.3 Deviation policy
7.4 Standards, practices &
conventions

46. 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.

47. 7. Documentation management

48. 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.

49. Configuration Items (CI’s)
Units tracked officially
down to the smallest unit worth tracking
includes most official documents
Payroll v
Payroll v
Payroll v S6 A1 C4 D5 E3
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

50. Configuration Items (CI’s)
Units tracked officially
down to the smallest unit worth tracking
includes most official documents
Payroll v
Payroll v
Payroll v S6 S7 S7 A1 A1 A1 C4 C4 C4 D5 D5 D5 E3 E3 E3 F1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

51. Configuration Management Requirements
Procedure to identify CI's
Locking
to prevent more than one person working on a CI at one time
Authorization to check out
optional
Check-in procedure
authorization process
involves testing etc.
Historical record of prior groupings of consistent CI’s
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.

52. IEEE 828-1990 SCMP Table of Contents
3.2 Configuration control
Requesting changes
Evaluating changes
Approving or dis-
approving changes
Implementing
changes
3.3 Configuration status
accounting
3.4 Configuration audits &
reviews
3.5 Interface control
3.6 Subcontractor /
vendor control
4. SCM schedules
5. SCM resources
6. SCM plan maintenance
1. Introduction
2. SCM management
2.1 Organization
2.2 SCM responsibilities
2.3 Applicable policies,
directives & procedures
3. SCM activities
3.1 Configuration
identification
Identifying configu-
ration items
Naming configu-
Acquiring configu-
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

53. Plan Configuration Management
One way to ...
1. Roughly sketch out your SCMP
Determine procedures for making changes
Omit tool references unless already identified one
See the case study for an example
2. Specify what you need from a CM tool
For class use, maybe only locking and backup
3. Evaluate affordable tools against your needs and budget
Commercial tools are in wide use
For class use, try free document storage web sites; try simple method of checking out e.g. renaming
5. Finalize your SCMP
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

54. 8. Introduction to capability assessment

55. The PSP Evolution (Humphrey)
Cyclic development
1000’s of lines
The PSP Evolution (Humphrey)
Skills added
to prior stage
PSP2.1
Design templates
PSP2
Code reviews
Design reviews
100’s of lines
Additional
capability at the same level
PSP1.1
Task planning
Schedule planning
PSP1
Size estimation
Test report
PSP0.1
Coding standards
Process improvement proposal
Size measurement
PSP0
Current personal process
Basic measurements
(Adapted from [Hu1] )

56. TSP Objectives 1 (Humphrey)
Build self-directed teams
3-20 engineers
establish own goals
establish own process and plans
track work
Show managers how to manage teams
coach
motivate
sustain peak performance
Graphics reproduced with permission from Corel.

57. TSP Objectives 2 (Humphrey)
Accelerate CMM improvement
make CMM 5 “normal”
“Provide improvement guidelines to high-maturity organizations”
“Facilitate university teaching of industrial-grade teams”

58. The Capability Maturity Model (CMM)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

59. 1. Initial (Software Engineering Institute)
Process:
undefined,
ad hoc
Result:
outcome depends on individuals
Lacking: any reasonable process

60. 2. Repeatable (Software Engineering Institute)
1. INITIAL Process undefined, ad hoc, depends on individuals
2. Repeatable (Software Engineering Institute)
Process
tracks documents, cost, schedule,
functionality (after fact)
Result
repeatable only on similar projects
Lacking: complete process

61. 3. Defined (Software Engineering Institute)
2. REPEATABLE Basic project management to
track cost & schedule, repeatable on similar projects
3. Defined (Software Engineering Institute)
Process
documented,
standardized,
tailorable
Result
consistency
Lacking: predictable outcomes

62. 4. Managed (Software Engineering Institute)
3. DEFINED Consistent: Documented, standardized,
tailorable
4. Managed (Software Engineering Institute)
Process
detailed measurement; control
Result
process and products with
quantified quality predictability
Lacking mechanism for process improvement

63. 5 Optimized (Software Engineering Institute)
4. MANAGED Predictable: process & products measured
5 Optimized (Software Engineering Institute)
Process
Continual process improvement
through quantitative feedback;
Extensible scope
Innovative ideas and technologies
Graphics reproduced with permission from Corel.

64. Relating PSP, TSP & CMM (Humphrey)
Get permission

65. Relating PSP, TSP & CMM (Humphrey)
Get permission

66. 9. Summary

67. Software engineering an extensive challenge
Summary
Software engineering an extensive challenge
Major process models: waterfall; spiral; incremental
Capability frameworks: CMM; TSP; PSP
Quality is the professional difference
metrics to define
inspection throughout
rigorous testing
include continuous self-improvement process
Documentation: SCMP, SVVP, SQAP, SPMP, SRS, SDD, STP, Code, User’s manual
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

68. Case Study: SCMP

69. Configuration Management Schedule
Month 1
Month 2
Month 3
Month 4
Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Stable CM
Vendor backup plan due
CM reviews
CM process improvement session
Random IV&V audits
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.