cs 551 – software life cycle. think like an engineer
Post on 21-Dec-2015
215 views
TRANSCRIPT
What is Engineering?
Engineering is the quantitative & systematic application of knowledge to create and build cost-effective solutions to practical problems.
Making trade-offs.
What is systems engineering?
The systematic synthesis and analysis of solutions to problems with a focus on
1. Understanding the problem domain
2. Defining the clients needs creating a set of feature definitions that satisfy the need
3. Mapping the features to components that perform defined functions
4. Specifying the components and their interfaces
5. Studying the economic viability of the solution
Be able to answer these Four Questions
l Is this proposed software centric system feasible?l If it is, how much will it cost?l If we are willing to pay, how long will it take to
build and to deploy?l What is the development plan, especially the
detailed schedule?
“…[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
l Requirements Elicitation l Requirements Analysisl Use Casesl Requirements Specificationl Prototypel 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
‘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.
HACKING
PROBLEM
Reqts Spec
Tech Spec
Code
SystemReqts Eng
Design
Implem
ent
Tes
t Maintain
Simplified Model
Analysis
Design
Coding
Testing
Integration
• Document Focused
• Phases in lockstep
• Encourages point solutions
• Mistakes found late
• Leads to tightly coupled systems
The Waterfall Model
Waterfall: document-driven milestones
l Baselined Requirements Specificationl Baselined Test Planl Baselined Design Specificationl Baselined Codel Test Results report
Why is Waterfall still used?
l Easy to understand l Familiar to customers, steps make intuitive sensel ‘Natural’ Structure for new staff or teamsl Tight control by project managementl Requirements are stablel Forces documentation
Prototyping by Barry Boehm
Listen to customer Build/revise mockup
Customer test drives mockup
When finished: Design, Implement, Test, Maintain
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
•Risk Focused
•Incremental and iterative
•Evolutionary Feature Discovery
•Prototyping with quick feedback
•Continuous integration
Analysis Design
Testing Coding
The Spiral Model
Extreme Programming (XP)
l Test before Codingl Pair Programmingl On-Site Customers l Ad hoc functionalityl Evolutionary Developmentl Continuous Integrationl Short Cycles with Feedbackl Incremental Development
Vision
l Peoplel Processl Productl Project (control, risk, schedule, trustworthiness)l Technology and Platforms (rules, tools, assets)l People work days, computers work nightsl Work, not people, needs to be mobilel Productivity must continue to double with no loss of
reliability or performance
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
l One common process is not the goall Commonly managed processes are possiblel 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
l Some sort of work breakdown structure, tasks into subtasks with constraints
l Beware of over and under analysisl Beware of diffuse responsibilityl Gantt chart - Microsoft project (do not represent
dependencies between activities)l Identify critical path activities (should know w/o
automation)l Sensitivity analysis - “what if” questionsl 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
l 20:1 difference between people but ‘20:1ers’ are 1% of population
l Code ownership with one developer making module changes; apprentice permitted
l Source module size = 20-40 new function points; smaller modules carry too much overhead; larger modules become too big for people to understand
l Production module size - constrained only by the execution environment
System Nature 10:5:1
l If Report Generation Software =1, thenl On-line Software =5, and l Communications or Real-time =10 l 1:5:10 is the degree of difficulty or complexity
which impacts productivity
Customer Relations 2:1
l Projects that team with customers are twice as productive as those that have contracts
l Prototypes build customer relations and increase productivity by 40%.
Capital Investment
l 100:1 improvement every 20 years measured by the expansion factor
l OOT coming with 3:1 potentiall 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
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
l 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
l Three surprises9. Autonomy and Adaptable Software10. Combinations of Biology and Computing11. Multi-threading returns
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
l Software increasingly success-critical to product and services• Provides competitive differentiation, adaptability to change
l 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
l By 2025, there will be a “9/11” – magnitude software failurethat 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
l But other trends will make trustworthy solutions harder• System complexity, globalization, rapid change