Академический Документы
Профессиональный Документы
Культура Документы
Alan R. Hevner
University of South Florida
(Formality, Documentation)
30 20
20 25
Criticality
Dynamism
(Loss due to impact of defects) 10 30
(% Requirements-change/month)
Many 0 35
1
Lives Single 5
Essential 10
Life Discretionary
Funds 30
Funds Comfort
50
3 Ag i l
90 e
10
70
30 Disc
ip line
50 d
100
30
300
Size 10
(# of personnel) Culture
(% thriving on chaos vs. order)
Design
Specifications & models
R
i Code and unit test
s
Tested code
k
Subsystem integration
Executable subsystem
System integration
Executable system
Time
RISK ANALYSIS
RISK ANALYSIS
RISK ANALYSIS
OPERATIONAL
COMMITMENT PROTOTYPE
RISK PROTOTYPE3
PARTITION
ANAL. PROTOTYPE2
PROTO-
TYPE1
REVIEW
EMULATIONS
RQTS PLAN MODELS
CONCEPT OF BENCHMARKS
LIFE CYCLE
OPERATION SOFTWARE
PLAN
RQTS
SOFTWARE DETAILED
DEVELOP- PRODUCT DESIGN
REQUIREMENTS
MENT PLAN DESIGN
VALIDATION
CODE
INTEGRATION
DESIGN VALIDATION
AND TEST UNIT
AND VERIFICATION
PLAN NEXT PLAN TEST
PHASES INTEGRA-
TION AND
ACCEPT- TEST
IMPLEMEN- ANCE TEST
TATION DEVELOP, VERIFY
NEXT LEVEL PRODUCT
Engineering Manufacturing
Stage Stage
R D I D R D I D R D I D R D I D
E E M E E E M E E E M E E E M E
Q S P P Q S P P Q S P P Q S P P
Management Management Management Management
RATIONAL
Software Corporation
Customer Acceptance
Requirements Analysis Test Scripts Field Test
System Test
Subsystem
Subsystem Test
Implementation
Unit Test
Figure 1
Customer Acceptance
Requirements Analysis Test Scripts Field Test
Subsystem
Subsystem Test
Incremental Implementation
Development Cycle
Unit Test
Figure 2
Customer Acceptance
Requirements Analysis Test Scripts Field Test
Functional Usage
Specification Specification
Box Structure
Representations
Software Architecture System Test Scripts System Integration
Subsystem Test
Box Structure
Representations
Incremental Implementation
Development Cycle
Unit Test
Figure 3
Customer Acceptance
Requirements Analysis Test Scripts Field Test
Functional Usage
Specification Specification
Box Structure
Representations System Test Scripts
Software Architecture
Box Structure
Representations
Incremental Implementation
Development Cycle
Figure 4
SEI CMMI
http://cmmiinstitute.com/
Plan Driven
Controlled
Flexibility Ad Hoc
Perfect Imperfect
Adaptable controls?
H1 H2
Plan Driven Processes
- -
Controlled Flexible Processes
Unpredictability + Emergent Outcomes + + Product-
-Market •Bounded Scope Market
-Technology Match
+ •Ongoing User Feedback -
Ad-hoc H3
Chapter 3
A Day in the Life of XP Project
A Day in the Life of an TSP Project
Chapter 4
Scaling up Agile Methods – Bad Smells
Lease Management Case Study
Streamlining Plan-Driven Methods
Command Center Processing and Display System
Replacement
Neither dominate
Uncertain No
about
Step 3.
ratings? Architecture
Analysis
Go Risk-driven
Yes Agile in agile
Architect application to
parts; Go Risk-
encapsulate agile parts
Buy information via driven Disciplined
prototyping, data elsewhere
collection and analysis
Step 5.
Execute and Monitor
Deliver incremental
capabilities according to Tailor life cycle process
strategy around anchor point
commitment milestones
Monitor progress and
risks/opportunities,
readjust balance and Step 4.
process as appropriate Tailor Life Cycle
Discipline-oriented risks
Rapid change
Need for rapid results
Emergent requirements
Not enough discipline-capable people
30
A5. Not enough agile-capable people Funds Comfort
50
10
D2. Need for rapid results 70
30
D3. Emergent requirements 50
- minimal risk - Very serious but manageable risk (# of personnel) Culture
(% thriving on chaos vs. order)
- moderate risk - Show-stopper risk
Customer
Management;
Representative
Users
people Size 10
(# of personnel) Culture
Risk rating scale: - Serious but manageable risk (% thriving on chaos vs. order)
- minimal risk - Very serious but manageable risk
- moderate risk - Show-stopper risk
100
people 30
- minimal risk - Very serious but manageable risk (# of personnel) Culture
- moderate risk - Show-stopper risk (% thriving on chaos vs. order)
Plan, specify,
develop stable,
• Develop compatible higher-criticality
Organize module
Stable, Higher-criticality component-level
into increments
Module Teams prototypes, requirements, disciplined
architectures, plans, and agile
critical software, feasibility module Plan, specify,
rationale teams develop dynamic,
• Classify modules by likely
lower-criticality
stability and criticality module
Dynamic, Lower-criticality
Module Teams increments