1 PROCESS. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 1 Focus

1PROCESS

Plan project

Integrate & test system

Analyze requirements

Design

Maintain

Test unitsImplement

Software Engineering Roadmap: Chapter 1 Focus

Identify corpor-ate practices- assess capability- specify standards- e.g. CMM level

Development phases

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

next chapter: Plan development process

Plan configuration management- how to manage documents & code- document: SCMP

Plan quality assurance - how to ensure quality- document: SQAP

Integrate & test system

Analyze requirements

Design

Maintain

Test unitsImplement

Software Engineering Roadmap:

Chapter 1 Focus

Identify corpor-ate practices- assess capability- specify standards- e.g. CMM level

Development phases

Plan verification & validation - verify the product satisfies requirements- validate each phase by showing it succeeded document: SVVP

Plan project


Chapter Learning Goals

• 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


1. Introduction to the software engineering process

• 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

Some Application Types


Typical Project Roadmap

1. Understand nature & scope of proposed product

2. Select the development process, and create a plan-- section 4 and chapter 2

4. Design and build the product -- chapters 5, 6, and 7

6. Deliver and maintain the product -- chapter 10

3. Gather requirements -- chapters 3 and 4

5. Test the product -- chapters 8 and 9


2. Historical and contemporary perspectives on software engineering

process

Structured Programming

Function definition handleAccount(…)getDetailsFromUser(…)getAccount(…)doTransaction(…)……

Function definition getDetailsFromUser (…)getName(…)…...

Function definition getAccount(…)getFirstName(…)…...

…...

TOP

DOWNAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Object Orientation

Real world concepts

Software design entities

SkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjk

AccountgetDetails()

Transactionexecute()

CustomergetFirstName()

Direct correspondence

Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The COM Idea

Identification interface

getName()

setName()

getSSN()

setSSN()

Computation interface

Asset interface

account

COM object


3. Expectations for process, project, product and people

Five Key Expectations (Humphrey)

Influencedby people

Used forprocess development

Part oftheproject

Aspectof the product

3. Keep all work visible

5. Measure quality

4. A. Design onlyagainst requirements

B. Programonly against designsC. Test only against

requirements and designs

1. Predetermine quantitative quality goals

2. Accumulate data for subsequent use

Artifacts and Roles

Artifacts: the entities that software engineering deals with.

Document Model-- a viewof the

application(design etc.)

Component-- physical

(source code etc.)

Workers: responsibilities allocated to people (roles).

USDP term Symbol & examples

Worker Worker instance(e.g., Joe Smith)


4. Process alternatives

The Waterfall Model

Requirementsanalysis

Design

Implementation

Integration

Produces … specification (text)

... diagrams & text

... code & comments

... entire code

Test... test report, including defect descriptions


More Detailed Waterfall Version

Design

Implementation& unit testing

Integration

System testing

Conceptanalysis

Analysis

MaintenanceAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

completetargeted

requirements

Step n:Analyzerequirements

Step n+3: Test

Step n+2: Implement

Step n+1: Design

Product:classmodels +

Product: requirementsspecifications

Product: code + Product: test results +

Spiral Development


Iteration No.

Incremental Development

Analyzerequirements

Test whole

Implement

Design

Test units

Integrate

1 2 3 867 868

Update SRS3

Update SDD2

Update source code

Update Test documentation

Update SPMP1

1 Software Project Mangement Plan (chapter 2); 2 Software Design Document (chapter 5); 3 Software Requirements Specification (chapter 3);


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.

ElaborationInception Construction Transition

Requirements

Analysis

Iter.#1

Iter.#n

Iter.#n+1

Iter.#m

Iter.#m+1

Iter.#k

….. …..Prelim.iterations

USDP vs. Standard Terminology ½ (Booch, Jacobson & Rumbaugh)

Design

Implemen-tation

Test

USDP calls these “core workflows”

(Classically called “phases”)

Classification of iterations

Individual iteration

Requirements

Analysis

USDP vs. Standard Terminology 2 of 2

Design

Implementation

Test

Requirements analysis

Implementation

USDP Terminology

Classical Terminology

Integration

Design

Test


Elaboration

Unified Process Matrix

Inception Construction Transition

Requirements

Analysis

Jacobson et al: USDP

Prelim.iterations

Iter.#1

Iter.#n

Iter.#n+1

Iter.#m

Iter.#m+1

Iter.#k

….. …..

Design

Implemen-tation

Test

..

Amount of effort expendedon the requirements phaseduring the first Constructioniteration

The Six USDP Models (Views of the Application)

Use-casemodel

Analysismodel

Designmodel

Deploymentmodel

Implementationmodel

Testmodel

Graphics reproduced with permission from Corel.

Identify the Process You Will Use

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

incremental2. 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.)


5. Documentation

Undocumented Code

int a( int i, char c ){

if( c== “m” )if( i< 1000 )

return 0;else

if( i< 10000 ) return 500;

elsereturn 1200;

elsereturn 1300;

}


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 < 10000 )

return 500; // married, $1000-$10000

else

return 1200; // married, >=$10000

// If not “married”, apply single tax rate of $1300 regardless

else

return 1300;

}

Documented Code/**

* This method implements requirement 4.3:

* “State tax effective 9/1/98 -12/31/99”

* @author Eric J. Braude

* @version 2.3.4 (8/6/98)

* @param anEarning: earnings 9/1/98 thru 12/31/99

* @param aStatus: ‘m’ signifies “married” (anything

* else designates unmarried)

*/

int tax( int anEarning, char aStatus )

{


Project Documentation

SCMPsoftware configuration management plan

SPMPsoftware project management planProject status

Configuration

SQAPsoftware quality assurance plan Quality assurance

SVVPsoftware validation & verification plan Verification & validation


Project Documentation

SRSsoftware requirements specifications

STDsoftware test documention


SDDsoftware design document

SPMPsoftware project management plan

Source Code

Project status

Configuration

Testing

Requirements

Design

Code

User’s manualOperation

SQAPsoftware quality assurance planQuality assurance

SVVPsoftware validation & verification planVerification & validation

Customer-orientedDeveloper-orientedArchitectureDetailed design


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

Identify Your Documentation Needs

* the IEEE standard,which can be used toorganize this documentation


6. Quality

QAInvolvement

3. Plan4. Design and build5. Deliver & main-tain the product

1. Specify how to manageproject documents 2. Identify process

QA

1. QA Developsand/or reviews configurationmanagementplans, standards ...

3. QA developsand/or reviews provision for QA activities

2. QA reviews process forconformance toorganizational policy

5. QA reviews,inspects & tests

4. QA reviews,inspects & tests


Principle of Inspection

AUTHORS CAN USUALLY

REPAIR DEFECTS

THAT THEY RECOGNIZE


Principle of Inspection

AUTHORS CAN USUALLY

REPAIR DEFECTS

THAT THEY RECOGNIZE

COROLLARY:Have their peers seek defects.

COROLLARY:Help authors to recognize defects

before they deliver their work.


OVERVIEW

CAUSAL

ANALYSIS

4. REWORK

5. FOLLOW-UPInspection Process & Example Times

Non-nominalprocess

6. IMPROVE PROCESS

2. PREPARATION

3. INSPECTION

Nominal process 1. PLANNING


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 1 hr (3-5) ]

Total: approx. 7 - 21 person-hours

* lines of non-commented codeAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Hours Per Defect: One estimate

… at inspection … at integration

time time

Hours to ..

.. detect 0.7 to 2 0.2 to 10

.. repair 0.3 to 1.2 9+

Total 1.0 to 3.2 9.2 to 19+

If defect found ...


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


IEEE 730-1989 Software Quality Assurance Plans

Table of Contents

1. Purpose2. Referenced documents3. Management 3.1 Organization 3.2 Tasks 3.3 Responsibilities4. Documentation 4.1 Purpose 4.2 Minimum documentation requirements 4.3 Other5. Standards, practices, conventions and metrics 5.1 Purpose 5.2 Content

IEEE 730-1989 Software Quality Assurance Plans Table of Contents

1. Purpose2. Referenced documents3. Management 3.1 Organization 3.2 Tasks 3.3 Responsibilities4. Documentation 4.1 Purpose 4.2 Minimum documentation requirements 4.3 Other5. 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 Other7. - 15. -- see next chapter

Verification:are we building the thing right?

Validation:are we building the right thing?

Meaning of “V&V” (Boehm)


IEEE 1012-1986 Software Verification & validation Plans Table of Contents (Reaffirmed 1992)

1. Purpose2. Referenced documents3. Definitions4. V&V overview 4.1 Organization 4.2 Master schedule 4.3 Resource summary 4.4 Responsibilities 4.5 Tools, techniques & methodologies5. 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

IEEE 1012-1986 Software Verification & validation Plans Table of Contents (Reaffirmed 1992)

1. Purpose2. Referenced documents3. Definitions4. V&V overview 4.1 Organization 4.2 Master schedule 4.3 Resource summary 4.4 Responsibilities 4.5 Tools, techniques & methodologies5. 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 phase V&V6. 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

Produce a Quality Product

1. Quantify your quality goalsminimum: 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 proceduresuse a documentation standard to avoid missing issues

SQAP (see case study for example); If time allows: SVVP


7. Documentation management

Example of Hyperlinked Documentation Set

(with Dynamic Content shown)

SRSsoftware requirements specifications

STPsoftware test plan


SDDsoftware design document

SPMPsoftware project management plan

Source Code

References to all other documents

Projectstatus*

Configuration*

Testresults*

Direction of hyperlink

*Dynamic component

Updates*

Updates*Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Configuration Items (CI’s)

Units tracked officially– down to the smallest unit worth tracking– includes most official documents

A1S6

E3

C4

D5

Payroll v. 0.3.4.2

Payrollv. 0.4.1

Payroll v. 0.3.4.3


Configuration Items (CI’s)

Units tracked officially– down to the smallest unit worth tracking– includes most official documents

A1S6

E3

C4

D5

A1S7

E3

C4

D5

Payroll v. 0.3.4.2

A1

D5

Payrollv. 0.4.1

S7C4

E3F1

Payroll v. 0.3.4.3


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

Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

IEEE 828-1990 SCMP Table of Contents 3.2 Configuration control

3.2.1 Requesting changes 3.2.2 Evaluating changes 3.2.3 Approving or dis-

approving changes 3.2.4 Implementing

changes 3.3 Configuration status accounting 3.4 Configuration audits & reviews 3.5 Interface control 3.6 Subcontractor / vendor control4. SCM schedules5. SCM resources6. SCM plan maintenance

1. Introduction2. SCM management 2.1 Organization 2.2 SCM responsibilities 2.3 Applicable policies, directives & procedures3. SCM activities 3.1 Configuration identification 3.1.1 Identifying configuration items 3.1.2 Naming configuration items 3.1.3 Acquiring configuration itemsAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Plan Configuration Management

1. Roughly sketch out your SCMPDetermine 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 toolFor class use, maybe only locking and backup

3. Evaluate affordable tools against your needs and budgetCommercial 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 SCMPAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8. Introduction to capability assessment

The PSP Evolution (Humphrey)

(Adapted from [Hu1] )

PSP0Current personal process

Basic measurements

PSP0.1Coding standards

Process improvement proposalSize measurement

PSP1Size estimation

Test report

PSP1.1Task planning

Schedule planning

PSP2Code reviews

Design reviews

PSP2.1Design templates

PSP3Cyclic development

Additionalcapability at the same level

Skills addedto prior stage

100’s of lines

1000’s of lines

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


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”

The Capability Maturity Model(CMM)


1. Initial (Software Engineering Institute)

Process: undefined, ad hoc

Result: outcome depends on individuals

Lacking: any reasonable process

2. Repeatable (Software Engineering Institute)

1. INITIAL Process undefined, ad hoc, depends on individuals

Processtracks documents, cost, schedule, functionality (after fact)

Resultrepeatable only on similar projects

Lacking: complete process

3. Defined (Software Engineering Institute)

2. REPEATABLE Basic project management totrack cost & schedule, repeatable on similar projects

Processdocumented, standardized, tailorable

Resultconsistency

Lacking: predictable outcomes

4. Managed (Software Engineering Institute)

3. DEFINED Consistent: Documented, standardized, tailorable

Processdetailed measurement; control

Resultprocess and products with quantified quality predictability

Lacking mechanism for process improvement

5 Optimized (Software Engineering Institute)

4. MANAGED Predictable: process & products measured

ProcessContinual process improvement

through quantitative feedback; Extensible scopeInnovative ideas and technologies


Level Focus Key Process Area PSP TSP

Requirements management X

Software project planning X X

Software project tracking X X

Software quality assurance X

Software configurationmanagement

X2. Repeatable

Projectmanagement

Software subcontract managementGet permission

Relating PSP, TSP & CMM (Humphrey)

CMM Level Focus Key Process Area PSP TSPDefect prevention X X

Technology change management X X5. OptimizingContinuousprocessimprovement Process change management X X

Quantitative process management X X

4. ManagedProduct &processquality Software quality management X X

Organization process focus X X

Organization process definition X X

Training programIntegrated software management X X

Software product engineering X X

Inter-group coordination X

3. Defined

Engineeringprocess

Peer reviews X X

Requirements management X

Software project planning X X

Software project tracking X X

Software quality assurance X

Software configurationmanagement

X2. Repeatable

Projectmanagement

Software subcontract managementGet permission

Relating PSP, TSP &

CMM (Humphrey)

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

Summary


Case Study: SCMP

Configuration Management Schedule

Month 1

1 2 3 4

Month 2

1 2 3 4

Month 3

1 2 3 4

Month 4

1 2 3 4

Month 5

1 2 3 4

Stable CM

CM reviews

CM process improvement session

Vendor backup plan due

Random IV&V audits


Documents

1 PROCESS. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 1 Focus