Upload
tuomasniinimaki
View
690
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Leftovers from Tuesday
… and excellent bridge to today’s topic
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
28% (34%)
23% (15%)
49% (51%)
ChallengedSucceededFailed
Software project success rates 2000 (2003)
Successful: on time, on budget, all features
Challenged: Completed and operational, but over-budget, over time, fewer features
Failed: Cancelled
(Standish Group, based on US data)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Failure statistics – Improvements? Average cost overrun 189 % (1994)->45 % (2000)-> 43% (2003) Average time overrun 222% (1994)->63 % (2000)-> 82% (2003) On average 61 % (1994) of required features were delivered -> 67
% (2000) -> 52% (2003)
(Standish Group, based on US data)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Reasons for success and failure
Reasons for failure: “Most projects failed for lack
of skilled project management and executive support”
“Underestimating project complexity and ignoring changing requirements are basic reasons why projects fail”
“The problem – and the solution – lay in people and processes”
Recipe for success: Smaller project size and
shorter duration More manageable
“Growing”, instead of “developing”, software engages the users earlier and confers ownership. -> Iterative and
interactive process
(Standish Group, based on US data)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.5612 Software Project Management Spring 2010
2: Selecting a Process Model
Tuomas Niinimäki
Department of Computer Science and Engineering Helsinki University of Technology
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Process
A sequence of steps performed for a given purpose
[IEEE Std 610.12-1990]
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
“A set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products”
Reasons for failure: “Most projects failed for lack of skilled project management and
executive support” “Underestimating project complexity and ignoring changing
requirements are basic reasons why projects fail” “The problem – and the solution – lay in people and processes”
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Why do we need processes in software projects?
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Process modeling objectives Harmonize and standardize work at the project level
Support project planning and management
Enable understanding and communication about the process
Gain better overall control of the projects in the process
Facilitate process reuse
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Software Development Process Models Waterfall model Iterative and incremental models
Synchronize and Stabilize Unified Process
Agile models XP (eXtreme Programming) Scrum
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Project constraints
Time
Resources
Scope
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Different viewpoints on a project
Project X Temporary organization
Collection of products
Sequence of work to be done
€ $£
Cost / Benefit
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
The waterfall model
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
The Waterfall Model The “classical” model for
software development Royce 1970
Document driven Each phase produces
documents Freeze Change management process
used after each phase “The whole application is
developed in one go” “Limited scope for iteration”
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
The Waterfall Model What Royce actually said:
1. Complete program design before analysis and coding begins
2. Documentation must be current and complete
3. Do the job twice if possible 4. Testing must be planned,
controlled and monitored 5. Involve the customer
Fig 3. Hopefully, the iterative interaction between the various phases is confined to successive steps
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
The Waterfall Model
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
“[Figure above] summarizes the five steps that I feel necessary to transform a risky development process into one that will provide the
desired product. I would emphasize that each item costs some additional sum of money.
If the relatively simpler process without the five complexities described here would work successfully, then of course the additional money is not
well spent.
In my experience, however, the simpler method has never worked on large software development efforts and the costs to recover far exceeded
those required to finance the five-step process listed.”
Royce 1970
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Under what conditions waterfall model could be
applicable?
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
The Waterfall Model Strengths
Easily manageable process (manager’s favorite?) Probably the most effective model, if you know the requirements Extensive documentation
Weaknesses Inflexible partitioning of the project into distinct stages Difficult to respond to changing customer requirements Feedback on system performance available very late and changes
can be very expensive Applicability
Appropriate when the requirements are well-understood Short, clearly definable projects Very large, complex system development, that requires extensive
documentation, safety critical systems
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Iterative and incremental development
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Iterative and incremental development (IID) Divide the project into iterations
Each iteration builds on previous iteration = adds new functionality = increment
Freeze requirements during each iteration Each iteration is a self-contained mini-project composed of
nearly all software development activities (e.g. requirements analysis, design, implementation, testing)
At the end of each iteration: an iteration release = a stable, integrated and tested partially complete system Most intermediate releases are internal Release from the final iteration is the complete product
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Timeboxing Fixing the iteration end date and not allowing it to change
1-6 weeks is normal length for a timeboxed iteration Over 2 months is usually too long and misses the point and value Shorter steps have:
Lower complexity and risk, better feedback, and higher productivity and success rates
Higher overhead due to administrative tasks, planning, releasing etc.
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Timeboxing and requirements Prioritize user requirements
MOSCOW priorities: must, should, could, want High-priority requirements into early iteration
Involve developers and the customer in planning Freeze requirements during each iteration
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Timeboxing and scoping If iteration goals are not going to be met:
The iteration scope is to be reduced, rather than moving the iteration end date further
=> Lower priority requests back on the wish list
Timeboxing should not be used to pressure developers to work long hours to meet the deadline If normal pace of work is not enough, do less!
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Concurrent iterations At least in a larger software project/program, iterations / tasks
can be concurrent:
RE 1
Impl 1
Testing 1
RE 2
Impl 2
Testing 2
RE 3
Impl 3
Testing 3
RE 4 RE 5
Impl 4
Testing 4
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Concurrent iterations At least in a larger software project/program, iterations / tasks
can be concurrent:
RE 1
Impl 1
Testing 1
RE 2
Impl 2
Testing 2
RE 3
Impl 3
Testing 3
RE 4 RE 5
Impl 4
Testing 4
Feedback!
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Iterative and incremental development
In the beginning: Prioritize features Make a release plan Plan the scope for
the first iteration
Starting date Predefined
Delivery date
Release 3
Release 1
Release 4
Release 2
Release 5
Iteration 1 Iteration 2 Iteration 5 Iteration 4 Iteration 3
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Iterative and incremental development
Plan B: project’s outcome if something goes wrong
Plan A: project’s outcome if everything goes fine
Starting date Predefined
Delivery date
Release 3
Release 1
Release 4
Release 2
Release 5
Iteration 1 Iteration 2 Iteration 5 Iteration 4 Iteration 3
Synchronize & Stabilize!
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Under what conditions iterative and incremental development (IID) model
could be applicable?
Starting date Predefined
Delivery date
Release 3
Release 1
Release 4
Release 2
Release 5
Iteration 1 Iteration 2 Iteration 5 Iteration 4 Iteration 3
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
IID advantages Added value for the customer value is delivered at the end of each
increment System functionality is available earlier
Early increments act as a prototype to help elicit requirements for later increments get feedback on system performance increase the job satisfaction and motivation of the development
team, as results of their work is seen earlier Smaller sub-projects are easier to control and manage
A meaningful progress indicator: tested software Final product better matches the true customer needs
Lower risk of overall project failure The highest priority system services tend to receive the most testing
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
IID disadvantages
Can be more difficult to plan and control than waterfall development Can end up being more expensive than waterfall development Later increments may require modifications to earlier increments System architecture must be adaptive to change May require more experienced staff Software project contracts are still mostly drawn according to the
waterfall model and all changes cause renegotiations
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Agile software development
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
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.
http://agilemanifesto.org/ 2001
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Agile software development Agile software development methods are a subset of IID methods
Scrum, eXtreme Programming (XP), ...
Timeboxed, iterative and evolutionary development Adaptive planning Evolutionary delivery
Rapid and flexible response to change Self-organized, self-directed and cross-functional teams Programming over documenting
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Agile software development methods Deliver something useful to the client Cultivate commited stakeholders Employ a leadership-collaboration style Build competent, collaborative teams Enable team decision making Use short timeboxed iterations to deliver quickly features Encourage adaptability Focus on delivery, not process-compliace activities
(Jim Highsmith)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Scrum
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Scrum - terms and definitions Scrum meeting:
Stand-up meeting for 15 minutes (usually daily) with 3 questions
Heartbeat: Time between two scrum meetings (usually 24h)
Sprint: = iteration (usually 2-4 weeks)
Release: Product delivered to a customer
Backlog: Prioritized list of backlog items (“tasks”)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Scrum - roles ScrumMaster:
Primary job is to remove impediments (obstacles) in order to make the team able to fulfill the sprint goals
Ensures that Scrum process is used as intended Product owner:
Represents the customer Ensures that the Scrum team works efficiently in business
point of view Team:
Responsible for delivering the product
Strategic Release Management
Release Project Cycle
Sprint
Release process with go/kill gates
Sprint backlog
Parts allocated into
Allocated into roadmap as
Product backlog
Release backlogs
1 month
3 months
Business Development
Example: Using Scrum based Framework
(R&D Process)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Selecting the Process Model
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Process Choice
There are several factors that affect which type of process you should use: Product type Business type Project size Project initial
uncertainty Environmental
uncertainty Organizational culture …
Plan-driven
Risks ~ - novelty of methods, tools, application domain - fuzziness of requirements Incremental
Iterative, prototyping
Product size/complexity
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Process Choice There is no uniformly applicable process which
should be standardized within an organization if there are, e.g., different types of products and/or markets! High costs may occur if you force an inappropriate process on a
development team However, one organization cannot have a large number of different
processes in use Sometimes you don’t have a possibility to choose A chosen process model can be tailored to suite the organization/
project Taking a new process into use is always a large task – that should be
planned from the point of view of the whole organization
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Process Choice For large systems, management is usually the principal problem
so you need a strictly managed process For smaller systems more informality is possible
Hybrid models: Large systems are usually made up of several sub-systems The same process model need not be used for all
subsystems, e.g. Prototyping for high-risk specification Waterfall model for well-understood developments
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Application:
• Primary goals: Predictability, stability, high assurance • Size: Larger teams and projects • Environment: Stable, low change, project and organization focused
Application:
• Primary goals: Rapid value, responding to change • Size: Smaller teams and projects • Environment: Turbulent, high-change, project focused
Plan-driven (e.g. Waterfall) Agile
(Boehm & Turner 2003)
Plan-driven vs. agile (Boehm & Turner 2003)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Management:
• Customer relations: As-needed customer interactions, focused on contract provisions • Planning and control: Documented plans, quantitative control • Communications: Explicit documented knowledge
Management:
• Customer relations: Dedicated onsite customers, focused on prioritised increments • Planning and control: Internalised plans, qualitative control • Communications: Tacit interpersonal knowledge
Plan-driven (e.g. Waterfall) Agile
(Boehm & Turner 2003)
Plan-driven vs. agile (Boehm & Turner 2003)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Technical:
• Requirements: Formalized project, capability, interface, quality, foreseeable evolution requirements • Development: Extensive design, longer increments, refactoring assumed expensive • Test: Documented test plans and procedures
Technical:
• Requirements: Prioritised informal stories and test cases, undergoing unforeseeable change • Development: Simple refactoring, short increments, refactoring assumed inexpensive • Test: Executable test cases define requirements, testing
Plan-driven (e.g. Waterfall) Agile
(Boehm & Turner 2003)
Plan-driven vs. agile (Boehm & Turner 2003)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Personnel:
• Customers: Knowledgeable, not always collocated • Developers: 50 % Level 3s early; 10 % throughout; 30 % 1B’s workable; No level -1s • Culture: Comfort and empowerment via framework of policies and procedures (thriving on order)
Personnel:
• Customers: Knowledgeable, dedicated and collocated (customer proxy) • Developers: At least 30 % full-time level 2 and 3 experts; No level 1B or Level -1 personnel • Culture: Comfort and empowerment via many degrees of freedom (thriving on chaos)
Plan-driven (e.g. Waterfall) Agile
(Boehm & Turner 2003)
Plan-driven vs. agile (Boehm & Turner 2003)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
People-factor: A Developer Classification
(Boehm & Turner 2003, modified from Cockburn)
Level Characteristics
3 Able to revise a method (break its rules) to fit an unprecedented new situation
2 Able to tailor a method to fit a precedented new situation
1A With training able to perform discretionary method steps (e.g., sizing stories to fit increments). With experience, can become Level 2.
1B With training, able to perform procedural method steps (e.g., simple refactoring). With experience, can master some Level 1A skills.
-1 May have technical skills, but unable or unwilling to collaborate or follow shared methods
Dimensions Affecting Process Model Selection (Boehm & Turner 2003) Personnel
Size Culture
DynamismCriticality
(Percent thriving on chaos versus order)(Number of personnel)
(Loss due to impacton defects)
(Percent level 1B) (Percent level 2 and 3)40
30
20
10 30
0 35
25
20
15
(Percent requirementschange/month)
Agile Plan-driven
5030
105
1
90
70
50
30
10
3
10
30
100
300
Manylives
Singlelife
Essentialfunds
Discretionaryfunds
Comfort
Size (# of personnel)
Culture (% of thriving on chaos vs. order)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Size: • Methods evolved to handle large products and teams; hard to tailor down to small projects
Criticality: • Methods evolved to handle highly critical products; hard to tailor down efficiently to low-criticality products
Size: • Well matched to small products and teams; reliance on tacit knowledge limits scalability
Criticality: • Untested on safety-critical products; potential difficulties with simple design and lack of documentation
Dynamism: • Simple design and continuous refactoring are excellent for highly dynamic environments, but present a source of potentially expensive rework for highly stable environments
Plan-driven discriminators Agility discriminators
(Boehm & Turner 2003)
Dynamism: • Detailed plans and "big design up front" excellent for highly stable environment, but a source of expensive rework for highly dynamic environments
Plan-driven vs. Agile: 5 Critical Factors
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Personnel: • Need a critical mass of scarce level 2 and 3 experts during project definition, but can work with fewer later in the project - unless the environment is highly dynamic • Can usually accommodate some level 1B people.
Culture: • Thrive in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures • Thrive on order.
Culture: • Thrive in a culture where people feel comfortable and empowered by having many degrees of freedom • Thrive on chaos
Plan-driven discriminators Agility discriminators
(Boehm & Turner 2003)
Personnel: • Require continuous presence of critical mass of scarce level 2 and 3 experts • Risky to use non-agile level 1B people
Plan-driven vs. Agile: 5 Critical Factors
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Plan-driven vs. Agile: Conclusions Neither agile nor plan-driven methods provide a silver bullet
Both have areas where one may suit better than the other Both agility and discipline are critical to future software success
Increasingly rapid pace of change E.g. larger projects using agile methods need plan-driven
process aspects to be integrated and to be successful
Build your method up – don’t tailor it down
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
“[Figure above] summarizes the five steps that I feel necessary to transform a risky development process
into one that will provide the desired product. I would emphasize that each item costs some
additional sum of money.
If the relatively simpler process without the five complexities described here would work
successfully, then of course the additional money is not well spent.
In my experience, however, the simpler method has never worked on large software development efforts
and the costs to recover far exceeded those required to finance the five-step process listed.”
“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.”
vs.
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Recipe for success
Smaller project size and shorter duration More manageable
“Growing”, instead of “developing”, software engages the users earlier and confers ownership. -> Iterative and interactive process
(Standish Group, based on US data)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Thank you.
Questions?
Tuomas Niinimäki