development processes printable
TRANSCRIPT
California Institute for Telecommunications and Information TechnologiesLa Jolla, CA 92093-0405, USA
Department of Computer Science & EngineeringUniversity of California, San Diego
La Jolla, CA 92093-0114, USA
CSE 210: Development ProcessesAgile and Plan-Driven Development
Ingolf H. [email protected], http://sosa.ucsd.edu
with contributions from Michael Meisinger, Massimiliano Menarini, Bernhard Rumpe
Ā© Ingolf H. Krueger 2April 12, 2005 CSE
Quote of the Day
The software field is not a simple one and, if anything, it is getting more complex at a faster rate than we
can put in order.
B.W. Boehm*
* B.W. Boehm: Software Engineering ā As it is. In:Proc. 4th International Conference on Software Engineering, IEEE Cat. 79CH1479-5C, IEEE Computer Socienty Press, 1979
Ā© Ingolf H. Krueger 3April 12, 2005 CSE
ā¢ Background and Motivation
ā¢ Software Project Risks
ā¢ Development Processes ā Basics
ā¢ Agile Development
ā¢ Plan-Driven Development
ā¢ Balancing Agility and Discipline
ā¢ Process Models ā Time for Tailoring
ā¢ Summary and Outlook
Overview
Ā© Ingolf H. Krueger 4April 12, 2005 CSE
Software Engineering Topics
RequirementsEngineering
Software Architectureand Design
SoftwareMaintenance
Re-Engineering
Project Management
Process Modeling
Software Development Methods
Notations and Languages (UML, Java, ...)
Tool Support (incl. CASE, CVS, make)
Quality Management (incl. Testing)
Ā© Ingolf H. Krueger 5April 12, 2005 CSE
Software Engineering Topics
RequirementsEngineering
Software Architectureand Design
SoftwareMaintenance
Re-Engineering
Project Management
Process Modeling
Software Development Methods
Notations and Languages (UML, Java, ...)
Tool Support (incl. CASE, CVS, make)
Quality Management (incl. Testing)
Ā© Ingolf H. Krueger 6April 12, 2005 CSE
June 4, 1996: āAriane-5ā Catastrophe
ā¢ Superfluous calibration program for inertia sensors runs in-flight; the software was āreusedā from Ariane-4
ā¢ Measured values in Ariane-5 exceed those assumed for the Ariane-4 software.
ā¢ The corresponding (Ada-) exception is handled by stopping the control computer and switching over to a redundant system.
ā¢ The second system contains the same error and deals with the exception the same way...
ā¢ Costs of the Ariane-5-program until 1996:~ $ 8 Billion
ā¢ Value of destroyed satellite: ~ $ 500 Million
Ā© Ingolf H. Krueger 7April 12, 2005 CSE
Software Catastrophes Abound
ā¢ Financial Catastrophes:ā 1993: Stopped CA project aiming at integration of systems for
driver licenses and vehicle registrations: $ 44 Mioā 1997: Stopped CA project State Automated Child Support System
āSACSSā: $ 300 Mioā¢ Deadlines:
ā 1994: Denver International Airport delayed 18 Months due to software problems of the luggage transportation system
ā 2003: Toll Collect: start date for German road toll system delayed to 1/2005, claimed losses > 4 Billion Euro
ā¢ Technical Catastrophes:ā 3/1999: Launch failure of Titan/Centaur-Rocket due to wrong
software versionā 9/1999: Loss of āMars Climate Orbiterā due to wrong unit
conversion
ā¢ USA: Losses during year 2000 due to software defects: $ 100 Billion.
Ā© Ingolf H. Krueger 8April 12, 2005 CSE
Why is High-Quality Software Difficult to Build?
ā¢ Software-Quality is difficult to measure
ā¢ Software is easily changeable at any stage during the development process
ā¢ Implementation platforms and technologies change rapidly
ā¢ Complexity is rapidly increasing
ā For every 25% increase in problem complexity there is a 100% increase in complexity of the software solution [Glass02]
ā¢ Adequate methods and tools do not exist or are only partially adopted
ā¢ Requirements change
Ā© Ingolf H. Krueger 9April 12, 2005 CSE
Why is High-Quality Software Difficult to Build?
ā¢ 0.1%-defect rate means:ā per year:
ā¢ 20,000 errors in medication ā¢ 300 failing heart pacers
ā per week:ā¢ 500 errors in medical surgeries
ā per day:ā¢ 16,000 lost letters in the postal systemā¢ 18 airplane crashed
ā pro hour:ā¢ 22,000 checks posted incorrectly
ā¢ Therefore:ā Massive QA efforts required also in the future.
Ā© Ingolf H. Krueger 10April 12, 2005 CSE
How Complex are These Systems Anyhow?
ā¢ Telecommunications
ā¢ Networking
ā¢ Embedded Systems, Automotive
ā¢ Business Information Systems (Web Services)
ā¢ Mobile, dynamic services, ad-hoc networks
Ā© Ingolf H. Krueger 11April 12, 2005 CSE
Growing Complexity (1)
10 MOI
20 MOI
30 MOI
40 MOI
50 MOI
60 MOI1960 1970 1980 1990 2000
MOI: Millionen Objektcode-InstruktionenEWSD: Elektronisches WƤhlsystem Digital
MERCURY
APOLLO
SPACESHUTTLE
EWSD-APSDBP-14
EWSD fĆ¼rBB-ISDN
LUNARMISSIONCONTROL
EWSD-APSWM4.2
GEMINI
7 % jƤhrlichesProduktivitƤts-wachstum
ā¢ Siemens EWSD V8.1: 12,5 Million LOC, ~190.000 pages of documentation
7% yearly productivity growth
Ā© Ingolf H. Krueger 12April 12, 2005 CSE
Growing Complexity (2)
ā¢ SAPās Enterprise-Resource-Planning Software R/3Ā®
ā¢ Further info on R/3 Release 4:ā 11 000 external database tablesā 500 000 table fields (external and internal)
year LOC # function points 1994 7 Million 14 000 1997 (Rel. 3.1) 30 Million 200 000 1999 (Rel. 4.5) 50 Million 400 000
Ā© Ingolf H. Krueger 13April 12, 2005 CSE
Growing Complexity (3)
ā¢ Total size of software used in select corporations (beginning of 2000):ā Chase Manhattan Bank: 200 Mio. LOCā Citicorp Bank: 400 Mio. LOCā AT&T: 500 Mio. LOCā General Motors: 2 Billion LOC
Ā© Ingolf H. Krueger 14April 12, 2005 CSE
Complexity Growth and Error Rate
#errors in 1000 LOC
20
0,2
1977 1994
Program size (1000 LOC)
10
800
1977 1994Resulting #errors (absolute)
200160
True quality increase requires overcompensating the increase in program
complexity!
(Averages, source: Balzert 96)
1977 1994
animated
Ā© Ingolf H. Krueger 15April 12, 2005 CSE
Increasing Quality Requirements
ā¢ Found defects in 1000 LOC:ā 1977: 7 - 20
ā 1994: 0,05 - 0,2
ā¢ Quality increased by factor 100 over 17 years.
ā¢ But: must compensate complexity increase!ā ~ factor 10 in 5 years
ā¢ Increasing concern for ālegacy debtsā: ā Business systems exist for 20 years and more.
ā In some companies 60-70% of software costs spent on
adaptation of legacy software!
Ā© Ingolf H. Krueger 16April 12, 2005 CSE
Success of IT Projects
Source: CHAOS Report, Standish Group International, Inc.
Ā© Ingolf H. Krueger 17April 12, 2005 CSE
Top 10 Project Success Factors
1. Executive support (18%)
2. User involvement (16%)
3. Experienced project manager (14%)
4. Clear business objectives (12%)
5. Minimized scope (10%)
6. Standard software infrastructure (8%)
7. Firm basic requirements (6%)
8. Formal methodology (6%)
9. Reliable estimates (5%)
10.Other criteria (5%)
Source: CHAOS Report, Standish Group International, Inc.
A software development process can have significant influence on these success criteria
Ā© Ingolf H. Krueger 18April 12, 2005 CSE
ā¢ Background and Motivation
ā¢ Software Project Risks
ā¢ Development Processes ā Basics
ā¢ Agile Development
ā¢ Plan-Driven Development
ā¢ Balancing Agility and Discipline
ā¢ Process Models ā Time for Tailoring
ā¢ Summary and Outlook
Overview
Ā© Ingolf H. Krueger 19April 12, 2005 CSE
Core Software Project Risks
ā¢ Schedule Flawā Underestimate the size of the project
ā Lack of estimation
ā¢ Requirements Inflationā Requirements do change
ā¢ Turnover
ā¢ Specification Breakdownā Problem areas avoided early in the process resurface during
construction
ā¢ Under-Performance
see [DML03]
Ā© Ingolf H. Krueger 20April 12, 2005 CSE
Risk Management
ā¢ There is a risk-list capturing general software project risks and risks specific to the project at hand.
ā¢ Risk-discovery is performed throughout the project duration.
ā¢ Uncertainty due to risk is captured.
ā¢ Goals and Estimates are captured separately.
ā¢ Each risk is associated withā Transition indicator (when does risk materialize?)
ā Contingent actions/Mitigation strategy
ā Likelihood
ā¢ Project value is assessed.
ā¢ Perform incremental development.
see [DML03]
Ā© Ingolf H. Krueger 21April 12, 2005 CSE
ā¢ Background and Motivation
ā¢ Software Project Risks
ā¢ Development Processes ā Basics
ā¢ Agile Development
ā¢ Plan-Driven Development
ā¢ Balancing Agility and Discipline
ā¢ Process Models ā Time for Tailoring
ā¢ Summary and Outlook
Overview
Ā© Ingolf H. Krueger 22April 12, 2005 CSE
Facts of the Trade
ā¢ Requirements deficiencies are the prime sources of project failures.
ā¢ Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed.
ā¢ Prototyping (significantly) reduces requirement and design errors, especially for user interfaces.
Coding Unit-Test Component-Test System-Test Field
Cost
adapted from [ER03]
Ā© Ingolf H. Krueger 23April 12, 2005 CSE
Facts of the Trade
ā¢ Individual developer performance varies considerably.
ā¢ Development effort is a (non-linear) function of product size.
ā¢ Mature processes and personal discipline enhance planning, increase productivity, and reduce errors.
ā¢ Adding people-power to a late project makes it later.
ā¢ Project risks can be resolved or mitigated by addressing them early.
adapted from [ER03]
Ā© Ingolf H. Krueger 24April 12, 2005 CSE
Phase- and Process Models
ā¢ Phase Model:Separation of the development process of a (software-) product into defined and distinct phases ā Specification of an order in the execution of phasesā Guidelines for the definition of intermediate results/artifacts
ā¢ Process Model:Detailed phase model + Definition of artifacts
ā¢ What process models do you know?discuss
Ā© Ingolf H. Krueger 25April 12, 2005 CSE
Activities in Software Development
ā¢ Distinguish between timed phases and activities occurring within a phase.
ā¢ Basic activities:discuss
Ā© Ingolf H. Krueger 26April 12, 2005 CSE
Activities in Software Development
ā¢ Distinguish between timed phases and activities occurring within a phase.
ā¢ Basic activities:
ā Analysis
ā Design
ā Implementation
ā Test (unit + integration, synonym: validation)
ā Deployment (installation, training)
ā Evolution (maintenance)
ā others (version management, reviews, ...)
Ā© Ingolf H. Krueger 27April 12, 2005 CSE
Classic Waterfall
Design
Implementation
Test,Integration
Maintenance
W. Royce (1970)
Product Definition
Design Spec
Code
ValidatedCode
Change Requests
Analysis
Ā© Ingolf H. Krueger 28April 12, 2005 CSE
Classic Waterfall
Design
Implementation
Test,Integration
Maintenance
W. Royce (1970)
Product Definition
Design Spec
Code
ValidatedCode
Change Requests
Analysis10 %
20 %
50 %
20 %
Ā© Ingolf H. Krueger 29April 12, 2005 CSE
Quality Assurance in the V-Model
Analysis
Coarse Design
Detailed Design
Implementation
Acceptance Test
System test
Integration Test
Unit Test
Test Cases
Test Cases
Test Cases
Boehm 1979 (āV-Modelā)
Ā© Ingolf H. Krueger 30April 12, 2005 CSE
Evolutionary Development
ā¢ Typical for smaller systems/projectsā¢ Increasingly being used also for larger systems
Analysis
Design Validation
Task
Prototypes,Early Versions
Implementation
Ā© Ingolf H. Krueger 31April 12, 2005 CSE
Iterative and Incremental Development
Analysis
Specification
Design
Implementation
Ā© Ingolf H. Krueger 32April 12, 2005 CSE
Process Components (V-Model XT)
ā¢ Project Managementā¢ Quality Assuranceā¢ Configuration Managementā¢ Defect and Change
Managementā¢ Client-side Managementā¢ Contractor-side Managementā¢ Controllingā¢ Metrics and Project
Evaluation
ā¢ Organization wide process Implementation and Improvement
ā¢ Requirements Analysisā¢ System Design & Integrationā¢ Software Developmentā¢ Hardware Developmentā¢ Integrated Logistics Supportā¢ Ready-to-use products
(COTS)ā¢ Usabilityā¢ Safety and Securityā¢ Migration and Software
Evolution
Ā© Ingolf H. Krueger 33April 12, 2005 CSE
Agility vs. Discipline
ā¢ Agile methods:ā Light process, less documentationā Short iterationsā Quality: customer satisfactionā Continuous technical and process improvementā Close relationship with the customer
ā¢ Traditional development: ā Heavy process, lot of documentationā Waterfall approach ā Quality: plan/process complianceā Aims to improve processā Upfront software & systems architecture, design (BDUF)
ā¢ Successful projects need bothā Both approaches have home groundsā Different mixes of agility and discipline are neededā Process should have the right āweightā for the specific project
ā¢ Key to success lies in risk analysis
adapted from [BT03]
Ā© Ingolf H. Krueger 34April 12, 2005 CSE
Agile and Plan-Driven Homegrounds
Stable, low change, project and organization focused
Turbulent, high change, project focused
Environment
Larger teams and projects
Smaller teams and projects
Size
Predictability, stability; high assurance
Rapid value, responding to change
Primary Goals
Application
Plan-Driven Home Ground
Agile Home Ground
Project Characteristics
adapted from [BT03]
Ā© Ingolf H. Krueger 35April 12, 2005 CSE
Agile and Plan-Driven Homegrounds
Explicit documented knowledge
Tacit interpersonal knowledge
Communications
Documented plans, quantitative control
Internalized plans, qualitative control
Planning and Control
As-needed customer interaction, focused on contract provisions
Dedicated on-site customers, focused on prioritized increments
Customer Relations
Management
Plan-Driven Home Ground
Agile Home Ground
Project Characteristics
adapted from [BT03]
Ā© Ingolf H. Krueger 36April 12, 2005 CSE
Agile and Plan-Driven Homegrounds
Documented test plans and procedures
Executable test cases define requirements, testing
Test
Extensive design, longer increments, refactoring assumed expensive
Simple design, short increments refactoring assumed inexpensive
Development
Formalized project, capability, interface, quality, foreseeable evolution requirements
Prioritized informal stories and test cases, undergoing unforeseeable change
Requirements
Technical
Plan-Driven Home Ground
Agile Home Ground
Project Characteristics
adapted from [BT03]
Ā© Ingolf H. Krueger 37April 12, 2005 CSE
Agile and Plan-Driven Homegrounds
Comfort and empowerment via framework of policies and procedures (thriving on order)
Comfort and empowerment via many degrees of freedom (thriving on chaos)
Culture
50% process and architecture experts early, 10% throughout; 30% intermediate programmers workable
At least 30% full-time highly skilled expert programmers
Developers
Crack1 performers, not always colocated
Dedicated, colocatedCrack1 performers
Customers
Personnel
Plan-Driven Home Ground
Agile Home Ground
Project Characteristics
adapted from [BT03]
1Collaborative, representative, authorized, committed and knowledgeable
Ā© Ingolf H. Krueger 38April 12, 2005 CSE
ā¢ Background and Motivation
ā¢ Software Project Risks
ā¢ Development Processes ā Basics
ā¢ Agile Development
ā¢ Plan-Driven Development
ā¢ Balancing Agility and Discipline
ā¢ Process Models ā Time for Tailoring
ā¢ Summary and Outlook
Overview
Ā© Ingolf H. Krueger 39April 12, 2005 CSE
Agile methods
ā¢ Rely on team knowledge instead of on documentation
ā¢ Iterative: several short cycles
ā¢ Incremental: development and delivery in several iterations
ā¢ Self organizing: teams decide on the best way to operate
ā¢ Emergence: processes, principles and work structure emerge during the project.
Verify Select FeatureSet
Implement
Multiple ShortIterations7-30 days
Ā© Ingolf H. Krueger 40April 12, 2005 CSE
Manifesto
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation
Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Kent BeckMike Beedle
Arie van BennekumAlistair Cockburn
Ward CunninghamMartin Fowler
James GrenningJim HighsmithAndrew HuntRon Jeffries
Jon KernBrian Marick
Robert C. MartinSteve Mellor
Ken SchwaberJeff SutherlandDave Thomas
Ā© 2001, the above authors this declaration may be freely copied in any form,but only in its entirety through this notice.
http://agilemanifesto.org/
Ā© Ingolf H. Krueger 41April 12, 2005 CSE
The 12 Principles
1. We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Ā© Ingolf H. Krueger 42April 12, 2005 CSE
The 12 Principles
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity ā the art of maximizing the amount of work not done ā is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Ā© Ingolf H. Krueger 43April 12, 2005 CSE
Examples of Agile Processes
ā¢ SCRUM
ā¢ eXtreme Programming (XP)
ā¢ [Tailored RUP/VModelXT]
Ā© Ingolf H. Krueger 44April 12, 2005 CSE
Scrum
ā¢ Very lightā¢ More a management tool than a software process
ā Product Backlog / Product ownerā Team / Scrum masterā Sprint (30 day iteration)ā Sprint backlogā Daily scrum meetings
ā¢ Empirical process: continuous feedback to control process and obtain desired output
ā¢ Team completely free to organize itselfā¢ Any development process and practice chosen by the
team can be used during each sprintā Example xP@Scrum & XBreed
from [S04]
Ā© Ingolf H. Krueger 46April 12, 2005 CSE
XP
ā¢ 4 values:
ā Communication (most projects fail because of poor communication)
ā Simplicity (YAGNI = You Aināt Gonna Need It)
ā Feedback (from costumer and other developers)
ā Courage (make hard decisions and support other principles and practices)
Ā© Ingolf H. Krueger 47April 12, 2005 CSE
XP
ā¢ Practicesā Customer continuously present on site
ā Planning game (requirements captured on index cards)
ā Metaphor support single vision of success
ā Short cycle time (no more than 3 weeks)
ā Collective ownership of code
ā Simple designā Pair programmingā Refactoringā Coding standardsā Test first approachā Continuous integrationā 40-hour work week
Ā© Ingolf H. Krueger 48April 12, 2005 CSE
ā¢ Background and Motivation
ā¢ Software Project Risks
ā¢ Development Processes ā Basics
ā¢ Agile Development
ā¢ Plan-Driven Development
ā¢ Balancing Agility and Discipline
ā¢ Process Models ā Time for Tailoring
ā¢ Summary and Outlook
Overview
Ā© Ingolf H. Krueger 49April 12, 2005 CSE
Plan Driven Methods
ā¢ Goals:ā Predictabilityā Stabilityā High assurance
ā¢ Well defined processā¢ Plans and specifications
are required for certification
ā¢ Fit well with complex and safety critical projects
ā¢ Scale up very wellā¢ Work best with stable
requirements
Perform Project
Define Process
Improve Process Measure Process
Control Process
adapted from [BT03]
Ā© Ingolf H. Krueger 50April 12, 2005 CSE
Examples of Plan-Driven Processes
ā¢ CMM/PSP/TSP
ā¢ Cleanroom
ā¢ [Tailored RUP/VModelXT]
Ā© Ingolf H. Krueger 51April 12, 2005 CSE
Capability Maturity Model (CMM)
ā¢ CMU-developed maturity assessment method
Stufe 1:Initialer ProzessStep 1:Initial
Step 2:Repeatable
Step 3:Defined
Step 4:Managed
Step 5:Optimizing
Cost, time and qualityunpredictable
Stable time, butvarying cost and quality
Stable cost and time, butvarying quality
Control overproduct quality
Control overprocess quality
Ā© Ingolf H. Krueger 52April 12, 2005 CSE
Capability Maturity Model (CMM)
ā¢ CMMI & SW-CMM
ā¢ Set of practices that improve organization process capability
ā¢ Aims at eliminating main causes of poor quality and poor productivity
ā¢ Maturity levels for SW-CMM (build upon each other):1. Initial: No particular process
2.Repeatable: Requirements Management, SW Project Planning, SW project tracking, SW Subcontract Management, SW Quality Assurance, SW Configuration Management.
3.Defined: Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, SW Product engineering, Intergroup coordination, Peer reviews
4.Managed: Quantitative process management, Software quality management
5.Optimizing: Defect prevention, Technology Change Management, Process Quality Management
Ā© Ingolf H. Krueger 53April 12, 2005 CSE
Cleanroom
ā¢ Mathematically-based verification with certified reliability
ā¢ Computer programs are complex mathematical functions and desired operations can be precisely specified
ā¢ Focus is on defect-free code
ā¢ Include processes for:ā Planning
ā Specification
ā Design
ā Verification
ā Coding
ā Testing
ā Certify software
ā¢ Software specified as a black-box, development generates a clear-box
Ā© Ingolf H. Krueger 54April 12, 2005 CSE
ā¢ Background and Motivation
ā¢ Software Project Risks
ā¢ Development Processes ā Basics
ā¢ Agile Development
ā¢ Plan-Driven Development
ā¢ Balancing Agility and Discipline
ā¢ Process Models ā Time for Tailoring
ā¢ Summary and Outlook
Overview
Ā© Ingolf H. Krueger 55April 12, 2005 CSE
Balancing Agility and Discipline
ā¢ Three possible approaches:ā Use plan to scale up Agile Methodsā Use agility to streamline Plan-Driven Methodsā Tailor a life cycle process as needed for the project
ā¢ Agile Methods:ā Effort to add features does not increase with timeā Tacit knowledge is enough to capture informationā YAGNI.
ā¢ Plan-Driven Methods:ā Requirements are fixedā Development process can be predictedā Technology is stableā The environment is not changing
ā¢ When do these assumptions break down?
adapted from [BT03]
Ā© Ingolf H. Krueger 56April 12, 2005 CSE
Using Risks
ā¢ Identify risks in using practices and techniques of agile and plan-driven methodsā If necessary use prototyping, data collection, and analysis to
gather information about risks
ā¢ Compare agile and plan driven risksā If agile riskier than plan-driven go for a risk-based plan-
driven processā If plan-driven riskier then agile go for a risk-based agile
processā If the project does not fit either agile or plan-driven methods
tailor an architecture where agile parts are encapsulated
ā¢ Tailor the life cycle process for the projectā¢ Execute and monitor
ā If needed modify the process
adapted from [BT03]
Ā© Ingolf H. Krueger 57April 12, 2005 CSE
Development Process Risks
ā¢ Environmental:ā E-Tech: Technology uncertaintiesā E-Coord: Many diverse stakeholders to coordinateā E-Cmplx: Complex systems of systems
ā¢ Agile risks:ā A-Scale: Scalability and criticalityā A-YAGNI: Use of simple designā A-Churn: Personnel turnover or churnā A-Skill: Not enough people skilled in agile methods
ā¢ Plan-Driven risks:ā P-Change: Rapid changeā P-Speed: Need for rapid resultsā P-Emerge: Emergent requirementsā P-Skill: Not enough people skilled in plan-driven methods
Ā© Ingolf H. Krueger 59April 12, 2005 CSE
ā¢ Background and Motivation
ā¢ Software Project Risks
ā¢ Development Processes ā Basics
ā¢ Agile Development
ā¢ Plan-Driven Development
ā¢ Balancing Agility and Discipline
ā¢ Process Models ā Time for Tailoring
ā¢ Summary and Outlook
Overview
Ā© Ingolf H. Krueger 60April 12, 2005 CSE
CONSIDERING?
What is a Process Model?
Definition: Process ModelA process model describes systematic, quantifiable engineering approaches to solve tasks of specific classes repeatably. A process model is based on a number of principles.It consists of a product model, activity model, role model and workflow model and considers methods, (de facto) standards and tools to implement the principles of the process model.
WHAT?Product Model
HOW?Activity Model
WHO?Role Model WH
EN?
Workflow
Model
Standards, etc.
Methods To
ols
Ā© Ingolf H. Krueger 61April 12, 2005 CSE
Rational Unified Process
ā¢ Derived from several object-oriented analysis and design methods
ā¢ It is possible to tailor it toward a more agile or a more document centric process (Tailor down approach)
ā¢ Risk-driven spiral processā¢ Fundamental tenets:
ā Reduce size or complexity of what needs to be developedā Improve the development processā Create more proficient teamsā Use integrated tools and exploit automation
ā¢ Four phases (each consisting of multiple iterations)1. Inception2.Elaboration3.Construction4.Transition
Ā© Ingolf H. Krueger 62April 12, 2005 CSE
Rational Unified Process
Activity
Time
AnalysisDesignImplementation
Test
ConfigurationManagement
ProjectManagement
Inception Elaboration Construction Transition
adapted from [RUP98]
Ā© Ingolf H. Krueger 63April 12, 2005 CSE
Rational Unified Process
Activity
Time
AnalysisDesignImplementation
Test
ConfigurationManagement
ProjectManagement
Inception Elaboration Construction Transition
adapted from [RUP98]
Ā© Ingolf H. Krueger 64April 12, 2005 CSE
V-Model XT (Germany, 2004)ā¢ The V-Model XT describes a Process Model to
Control and Organize system development projects considering the entire system life cycle.
ā¢ The V-Model XT providesā concrete Workflows and Activities (WHEN)ā the description of respective Work Results (WHAT)ā and responsible Roles (WHO)
ā¢ The V-Model XT aims atā minimizing project risks
ā¢ increase project transparencyā¢ improve the ability of project planningā¢ facilitate project execution
ā increasing and guaranteeing result qualityā reducing total cost over the entire system life cycleā improving communication between all stakeholders
ā¢ Goal: Improved controllabilityof the āMagic Triangleā
Time
Cost Function
Ā© Ingolf H. Krueger 65April 12, 2005 CSE
V-Model XT Philosophy: Goal and result oriented
ā¢ Products are in the center of interest. They form THE
actual project results
ā¢ Project execution scenarios and decision points
determine the order of product completion and
therefore the basic structure of the project progress
ā¢ Detailed project planning and control is based on the
editing and completion of products
ā¢ Every product has an associated responsible role; in the
project this is a defined person playing that role
ā¢ Product quality is verifiable by checking the defined
product requirements and explicit descriptions of
dependencies to other products
Ā© Ingolf H. Krueger 66April 12, 2005 CSE
V-Model XT ā What do you get?
ā¢ Model sizeā 3 project types (client, contractor, process improvement project)ā 7 process execution strategiesā 18 decision pointsā 18 process componentsā 99 products and 99 activities (each with multiple subjects/steps)ā 72 explicit product dependencies of different typesā 30 role descriptionsā mappings to 6 standards, conventions (AQAP 150, CMMI, ISO 9000,
ISO 15288, CPM, V-Model 97)ā Tutorial, glossary, method and tool references, ā¦
ā¢ V-Model documentation and tool supportā PDF/Word documents (635 pages)ā HTML versionā 76 generated Word product templatesā Process editing tool (Open Source), process tailoring tool
Ā© Ingolf H. Krueger 67April 12, 2005 CSE
ā¢ Background and Motivation
ā¢ Software Project Risks
ā¢ Development Processes ā Basics
ā¢ Agile Development
ā¢ Plan-Driven Development
ā¢ Balancing Agility and Discipline
ā¢ Process Models ā Time for Tailoring
ā¢ Summary and Outlook
Overview
Ā© Ingolf H. Krueger 68April 12, 2005 CSE
Summary
ā¢ High-quality software is difficult to develop.
ā¢ Software complexity key problem.
ā¢ Various development processes have been devised to address aspects of software complexity
ā¢ One size does not fit all.
ā¢ It is possible to combine agility and discipline.
ā¢ Risk based assessment helps in creating the right mix.
ā¢ Analysis of real projects shows that often successful projects have applied a balanced mix of agility and discipline.
Ā© Ingolf H. Krueger 69April 12, 2005 CSE
Literature
[BCK98] Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, SEI Series in Software Engineering, Addison-Wesley, 1998
[BD03] Bernd Bruegge, Alan Dutoit: Object-Oriented Software Engineering: Using UML, Patterns and Java, 2nd Edition. Prentice Hall, 2003
[BT03] Barry Boehm, Richard Turner: Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, 2003
[DML03] Tom DeMarco and Timothy Lister: Waltzing With Bears: Managing Risk on Software Projects, Dorset House Publishing Company, 2003.
[DW98] Desmond F. DāSouza, Alan C. Wills: Objects, Components and Frameworks with UML ā the Catalysis Approach, Addison-Wesley, 1998
[E03] Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003
[F99] Martin Fowler: Refactoring ā Improving the Design of Existing Code, Addison-Wesley, 1999
[Glass02] Robert L. Glass: Facts and Fallacies of Software Engineering, Addison-Wesley, 2002
Ā© Ingolf H. Krueger 70April 12, 2005 CSE
Literature
[GOF95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns āElements of Reusable Object-Oriented Software, Addison-Wesley, 1995
[ER03] Endres, Rombach: A Handbook of Software and Systems Engineering. Empirical Observations, Laws and Theories, Addison Wesley, 2003
[H03] Luke Hohmann: Beyond Software Architecture: Creating and Sustaining Winning Solutions, Addison-Wesley, 2003
[PKB+02] A. Pink, H. KoĆmann, M. Broy, E. Kargl, M. Lagally, M. Schimper: Software-Entwicklung fĆ¼r Kommunikationsnetze, Springer, 2002
[POSA96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal: Pattern-Oriented Software Architecture ā A System of Patterns, Wiley, 1996
[RUP98] Philippe Kruchten: The Rational Unified Process ā An Introduction, Addison-Wesley, 1999