cs 551 – software life cycle
DESCRIPTION
CS 551 – Software Life Cycle. Key Question. What’s the problem?. “…[I]n software there has always been a great willingness to make changes in the specifications, and this makes the job tenuous; hardware people have a habit of freezing a design and not letting a - PowerPoint PPT PresentationTRANSCRIPT
CS 551 – Software Life Cycle
Key Question
What’s the problem?
“…[I]n software there has always been a great willingness to make changes in the specifications, and this makes the job tenuous; hardware peoplehave a habit of freezing a design and not letting a large number of new things be incorporated into it.When you allow changes you risk errors, delays and cost overruns.”
R.W. Hamming, preeminent softwarephilosopher
Journal of Systems Integration, Vol. 6, Number 1/2, March 1996, Kluwer AcademicPublishers Boston ISSN: 0925-4676, p. 6
Software Requirements Process
Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype Requirements Management
Five Great Processes
Solo Virtuoso
Code Ownership
Engage QA
Divide and Conquer Prototype
Reference: Technical Memorandum by J. O. Coplien Document No. BL0112650-940906-50TM
Product Size Reduction
TRADITIONAL PROCESS PROTOTYPING
40% REDUCTION
20%
80%
40%
30%
45%
25%
SystemsEngineering
Design,Develop,
Test,Install
FinalDevelopment,Deployment
SystemsEngineering &
Prototype
FinalDevelopment
Deployment
‘Code then fix’
Test
Fix
Code
Run
This approach leads to unstructured, unstable software that sometimes meets users’ needs. Problems are hard to find and harder to fix.
Analysis
Design
Coding
Testing
Integration
• Document Focused
• Phases in lockstep
• Encourages point solutions
• Mistakes found late
• Leads to tightly coupled systems
The Waterfall Model
•Risk Focused
•Incremental and iterative
•Evolutionary Feature Discovery
•Prototyping with quick feedback
•Continuous integration
Analysis Design
Testing Coding
The Spiral Model
Extreme Programming (XP)
Test before Coding Pair Programming On-Site Customers Ad hoc functionality Evolutionary Development Continuous Integration Short Cycles with Feedback Incremental Development
Vision
People Process Product Project (control, risk, schedule, trustworthiness) Technology and Platforms (rules, tools, assets) People work days, computers work nights Work, not people, needs to be mobile Productivity must continue to double with no loss of
reliability or performance
CHAOS
Customer Interests
I N S T A L L A T I O N
Before
• Features• Price• Schedule
After
• Reliability• Response Time• Throughput
• Customer buys off-the-shelf
• System works with 40-60% flow- through
• Developers complies with enhancements
BUT
• Customer refuses critical Billing Module
• Customer demands 33 enhancements and tinkers with database
• Unintended system consequences
Why bad things happen to good systems
Lessons Learned
One common process is not the goal Commonly managed processes are possible Scalability is essential
CMM LEVEL FOCUS KEY PROCESS AREAS
5 Optimizing
Continual Process Improvement
Defect prevention, Technology change management,Process change management
4 Managed Product and process quality
Quantitative process management,Software quality management
3 Defined Engineering processes and organizational support
Organization process focus, Organization process definition, Training program, Integrated software management, Software product engineering, Intergroup coordination, Peer reviews
2 Repeatable
Project management processed
Requirements management, Software project planning, software project tracking and oversight, Software subcontract management, Software QA, Software configuration management
1 Initial Competencies And heroics and small teams
Brooks: System Production
Program Programming System
Programming Product Programming System Product
x3
x3
x9
Techniques for Project Planning
Some sort of work breakdown structure, tasks into subtasks with constraints
Beware of over and under analysis Beware of diffuse responsibility Gantt chart - Microsoft project (do not represent
dependencies between activities) Identify critical path activities (should know w/o
automation) Sensitivity analysis - “what if” questions Also informal methods -- milestones
Mindset
Move from a culture of minimal change to one of maximal change.
Move to "make it work, make it work right, make it work better" philosophy through prototyping and delaying code optimization.
Give the test teams the "right of refusal" for any code that was not reasonably tested by the developers.
Productivity
Productivity =
F {people,
system nature,
customer relations,
capital investment}
As of 8/31/06
People 20:1
20:1 difference between people but ‘20:1ers’ are 1% of population
Code ownership with one developer making module changes; apprentice permitted
Source module size = 20-40 new function points; smaller modules carry too much overhead; larger modules become too big for people to understand
Production module size - constrained only by the execution environment
System Nature 10:5:1
If Report Generation Software =1, then On-line Software =5, and Communications or Real-time =10 1:5:10 is the degree of difficulty or complexity
which impacts productivity
Customer Relations 2:1
Projects that team with customers are twice as productive as those that have contracts
Prototypes build customer relations and increase productivity by 40%.
Capital Investment
100:1 improvement every 20 years measured by the expansion factor
OOT coming with 3:1 potential Objects in the large, and 80% reuse by turn of the
century
Function Point MetricFunction Point MetricF
un
ctio
n P
oin
ts/S
taff
Mo
nth
Technology
0
2
4
6
8
10
12
14
16
18
20
IDMS IMS MVS Oracle UNIX VM Composite
80 Projects 98 Projects
Benefits of Objects:
1. Manages complexity
2. Speeds development
3. Encourages module reuse
4. Enables scaling
Prerequisites for Supporting Object-Oriented Design:
1. Software technologies and techniques
2. Tools and infrastructure
3. Management process and culture
4. Know-how
Objects
3
15
3037.5
47
75
113142
475
638
81
1
10
100
1000
1960 1965 1970 1975 1980 1985 1990 1995 2000
ExpansionFactor
TechnologyChange:
RegressionTesting
4GL Small ScaleReuse
MachineInstructions
High LevelLanguages
MacroAssemblers
DatabaseManagers
On-LineDev
Prototyping SubsecTimeSharing
ObjectOrientedProgramming
Large ScaleReuse
Order of MagnitudeEvery Twenty Years
Each date is an estimate of widespread use of a software technology
The ratio ofSource line of code to a machine level line of code
Trends in Software Productivity
Barry Boehm
USC Center for Systems and Software Engineering
Keynote Address, EQUITY 2007
March 19, 2007
Revisiting Software Engineering Economics
Implications for the future
Estimation Value-based approaches Agility Systems-of-Systems
Software Estimation: 1980’s Expectations
Unprece-dented
Prece-dented
EstimationError
Domain Understanding
Software Estimation: The Receding Horizon
Unprece-dented
Prece-dented
Component-based
RADOpen Source
Systems of Systems
A B C D
RelativeProductivity
EstimationError
Domain Understanding
RAD: Rapid Application Development
The Future of Systems and Software
Eight surprise-free trends1. Increasing integration of SysE and SwE2. User/Value focus3. Software Criticality and Dependability4. Rapid, Accelerating Change5. Distribution, Mobility, Interoperability, Globalization6. Complex Systems of Systems7. COTS, Open Source, Reuse, Legacy Integration8. Computational Plenty
Three surprises9. Autonomy and Adaptable Software10. Combinations of Biology and Computing11. Multi-threading returns
Why Software Projects Fail
Pareto 80-20 distribution of test case value [Bullock, 2000]
Actual business value
% of Valuefor
CorrectCustomer
Billing
Customer Type
100
80
60
40
20
5 10 15
Automated test generation tool
- all tests have equal value
% of Valuefor
CorrectCustomer
Billing
Customer Type
100
80
60
40
20
5 10 15
Automated test generation tool
- all tests have equal value
Business Case for Value-Based Testing
-1
-0.5
0
0.5
1
1.5
2
0 20 40 60 80 100
% Tests Run
Ret
urn
on
Inve
stm
ent
(RO
I)
Pareto testing ATG testing
Defect Removal Estimates- Nominal Defect Introduction Rates
60
28.5
14.37.5
3.5 1.60
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects/ KSLOC
Composite Defect Removal Rating
Trustworthy Trends
Software increasingly success-critical to product and services• Provides competitive differentiation, adaptability to change
Dependability is generally not vendors’ top-priority• “The IT industry spends the bulk of its resources… on rapidly bringing
products to market.” – US PITAC Report By 2025, there will be a “9/11” – magnitude software failure
that will raise trustworthiness to priority 1• Major loss of life or collapse of world financial system• Market demand; stronger warranties and accountability• Value-based trustworthy processes and tools
But other trends will make trustworthy solutions harder• System complexity, globalization, rapid change