1. Software Engineering Process 2007. 2 IT projects have a terrible track record –A 1995 Standish...
-
Upload
kirk-chiles -
Category
Documents
-
view
214 -
download
0
Transcript of 1. Software Engineering Process 2007. 2 IT projects have a terrible track record –A 1995 Standish...
2
• IT projects have a terrible track record– A 1995 Standish Group study (CHAOS) found that
only 16.2% of IT projects were successful and over 31% were canceled before completion, costing over $81 B in the U.S. alone
• The need for IT projects keeps increasing– In 2000, there were 300,000 new IT projects– In 2001, over 500,000 new IT projects were started
Motivation for Software Engineering
3
The Four “P’s” of Software Engineering
People
(by whom it is done)
Process(the manner
in which it is done)
Project
(the doing of it)
Product
(the application artifacts)
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
..
4
People
• “It’s always a people problem” Gerald Weinberg, “The Secrets of Consulting”
• Developer productivity: 10-to-1 range
- Improvements:- Team selection- Team organization– Motivation
5
People 2
• Other success factors– Matching people to tasks– Career development– Balance: individual and team– Clear communication
6
Optimal Size for Interaction (Approximate)
Number of people with whom developer must frequently interact
Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help.
Key: = engineer
3
Effectiveness per developer
7
Optimal Size for Interaction (Approximate)
Number of people with whom developer must frequently interact
Developer communicates regularly with eleven people. Communication time outweighs benefits of interaction
Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help.
Key: = engineer
Approximateoptimal range
3 7
Effectiveness per developer
9
Application must satisfy predetermined standards.
Methods to attain quality goals:• Inspection
• team-oriented process for ensuring quality
• applied to all stages of the process.
Quality
10
Application must satisfy predetermined quality level.
Methods to attain quality level:• Inspection
• team-oriented process for ensuring quality• applied to all stages of the process.
• Formal methods• mathematical techniques to convince ourselves and peers that our programs do what they are meant to do• applied selectively
• Testing • at the unit (component) level• at the whole application level
• Project control techniques• predict costs and schedule• control artifacts (versions, scope etc.)
Quality
13
Process
• 2 Types: Management & Technical
• Development fundamentals
• Quality assurance
• Risk management
• Lifecycle planning
15
Development sequence:Waterfall Iterative
Process frameworks:Personal Software ProcessSM Team Software ProcessSM Capability Maturity ModelSM
-- for organizationsStandards:
Institute of Electrical and Electronic Engineers International Standards Organization ...
Process
16
What Is a Project?• A project is “a temporary endeavor undertaken
to accomplish a unique product or service” (PMBOK® Guide 2000, p. 4)
• Attributes of projects– unique purpose– temporary– require resources, often from various areas– should have a primary sponsor and/or customer– involve uncertainty
17
The Triple Constraint
• Every project is constrained in different ways by its– Scope goals: What is the project trying to accomplish?– Time goals: How long should it take to complete?– Cost goals: What should it cost?
• It is the project manager’s duty to balance these three often competing goals
21
The Variables
of Project Management
Can somewhat vary the following factors.
1. The total cost of the project, e.g., increase expenditures
2. The capabilities of the product, e.g., subtract from a list of features
3. The quality of the product, e.g., increase the mean time between failure
4. The date on which the job is completed. e.g., reduce the schedule by 20%
e.g., postpone project's completion date one month
22
Project Variablescost
capability duration
defectdensity
Target :$70K
Target : 30 wks
Target : 4 defects/Kloc
Target:100%
23
Project Variablescost
capability duration
defectdensity
Target :$70K
Actual: 100%
Target : 30 wksTarget :
4 defects/Kloc
thisproject
Actual:1 defect/Kloc
Actual:20 wks
Actual:$90K
Target:100%
24
Product
• The “tangible” dimension
• Product size management
• Product characteristics and requirements
• Feature creep management
26
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
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
27
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
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
28
Typical Project Roadmap
1. Understand nature & scope of proposed product
2. Select the development process, and create a plan
4. Design and build the product
6. Deliver and maintain the product
3. Gather requirements
5. Test the product
29
Planning• Determine requirements
• Determine resources
• Select lifecycle model
• Determine product features strategy
31
Measurements• To date and projected
– Cost– Schedule– Effort– Product features
• Alternatives– Earned value analysis– Defect rates– Productivity (ex: SLOC)– Complexity (ex: function points)
35
Structured ProgrammingFunction definition handleAccount(…)
getDetailsFromUser(…)getAccount(…)doTransaction(…)……
Function definition getDetailsFromUser (…)getName(…)…...
Function definition getAccount(…)getFirstName(…)…...
…...
TOP
DOWN
36
Object Orientation
Software design entities
AccountgetDetails()
Transactionexecute()
CustomergetFirstName()
Direct correspondence
Real world conceptsSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjk
37
Components• Software may be built
using existing services• Reusable Software• Make-or-(better) Buy• Design for
Changeability,• Exchangeability
38
What is a Component?Definition:A component denotes a self-contained entity
that• provides its functionality via standard
interfaces• uses functionality from its environment via
standard interfaces• and may support builder tools in plugging
components and applications together
40
Hajuskomponent
Klient Kliendipoolnev ahendaja
Serveripoolnev ahendaja Server
V õrgu ta rkva ra V õrgu ta rkva ra
1
2
2
2
3
4
5
5
5
6
42
Five Key Expectations
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
43
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).
SW Dev Proc term Symbol & examples
Worker Worker instance(e.g., Joe Smith)
45
Main Phases of Software Process
1. Requirements Analysis (answers “WHAT?”) Specifying what the application must do
2. Design (answers “HOW?”) Specifying what the parts will be, and how they will fit together
3. Implementation (A.K.A. “CODING”) Writing the code
4. Testing (type of VERIFICATION) Executing the application with test data for input
5. Maintenance (REPAIR or
ENHANCEMENT)
Repairing defects and adding capability
46
Software Process Phases
• Requirements Analysis: Text producede.g., “ … The application shall display the balance in the user’s bank account. …”
• Design: Diagrams and text e.g., “ … The design will consist of the classes
CheckingAccount, SavingsAccount, …”• Implementation: Source and object code
e.g., … class CheckingAccount{ double balance; … } …• Testing: Test cases and test results
e.g., “… With test case: deposit $44.92 / deposit $32.00 / withdraw $101.45 / … the balance was $2938.22, which is correct. …”
• Maintenance: Modified design, code, and text e.g., Defect repair: “Application crashes when balance is $0
and attempt is made to withdraw funds. …”e.g., Enhancement: “Allow operation with Pesos.”
47
The Waterfall Model
Design
Implementation& unit testing
Integration
System testing
Conceptanalysis
Analysis
Maintenance
48
The Waterfall Software Process time
RequirementsAnalysis
Design
Milestone(s)
Phases (activities)
Implementation
Testing
Maintenance
Release product X
Two phases may occur at the same time for a short period
49
Why a Pure Waterfall Process is Usually Not Practical
Don’t know up front everything wanted and neededo Usually hard to visualize every detail in advance
We can only estimate the costs of implementing requirements
o To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones
o We will probably need to modify requirements as a result We often need to execute intermediate builds
o Stakeholders need to gain confidenceo Designers and developers need confirmation they're
building what’s needed and wanted Team members can't be idle while the requirements
are being completedo Typically put people to work on several phases at once
50
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 Sequence
51
The Spiral Process time
1 Requirementsanalysis
Design
Coding
Testing
1Iteration #
1
1
2
2
2
3
3
3
Product released XIntermediate version* completed X
*typically a prototype
M I L E S T O N E S
2 3
2 3 1
52
Iteration No.Iterative 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 2 Software Design Document 3 Software Requirements Specification
54
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
55
UP Terminology (1)
ElaborationInception Construction Transition
Requirements
Analysis
Iter.#1
Iter.#n
Iter.#n+1
Iter.#m
Iter.#m+1
Iter.#k
….. …..Prelim.iterations
Design
Implemen-tation
Test
UP calls these “disciplines”
(Classically called “phases”)
Classification of iterations
Individual iteration
56
UP Terminology (2)
Requirements
Analysis
Design
Implementation
Test
Requirements analysis
Implementation
UP Terminology
Classical Terminology
Integration
Design
Test
57
Unified Process MatrixElaborationInception Construction Transition
Requirements
Analysis
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
58
The Six UP Models (Views of the Application)
Use-casemodel
Analysismodel
Designmodel
Deploymentmodel
Implementationmodel
Testmodel
59
Project Documentation
SRSsoftware requirements specifications
STDsoftware test documention
SCMPsoftware configuration management plan
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
61
Verification:are we building the thing right?
Validation:are we building the right thing?
Meaning of “V&V”(Boehm)
62
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
63
OVERVIEW
CAUSAL
ANALYSIS
4. REWORK
5. FOLLOW-UP
Inspection Process & Example Times
6. IMPROVE PROCESS
2. PREPARATION
3. INSPECTION
Nominal process 1. PLANNING Non-nominal
process
64
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 code
65
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 ...
66
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.
68
Project Documentation
SCMPsoftware configuration management plan
SPMPsoftware project management planProject status
Configuration
SQAPsoftware quality assurance plan Quality assurance
SVVPsoftware validation & verification plan Verification & validation
69
Example of Documentation Set (with Dynamic Content shown)
SRSsoftware requirements specifications
STPsoftware test plan
SCMPsoftware configuration management 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*
70
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
71
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
72
• 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