2 Process

SoberIT Software Business and Engineering Institute

HELSINKI UNIVERSITY OF TECHNOLOGY

Leftovers from Tuesday

… and excellent bridge to today’s topic



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)



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)




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




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



Process

A sequence of steps performed for a given purpose

[IEEE Std 610.12-1990]



“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”



Why do we need processes in software projects?



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



Software Development Process Models   Waterfall model   Iterative and incremental models

  Synchronize and Stabilize   Unified Process

  Agile models   XP (eXtreme Programming)   Scrum



Project constraints

Time

Resources

Scope



Different viewpoints on a project

Project X Temporary organization

Collection of products

Sequence of work to be done

€ $£

Cost / Benefit



The waterfall model



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”



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



The Waterfall Model



“[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



Under what conditions waterfall model could be

applicable?



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



Iterative and incremental development



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



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.



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



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!



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



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!




  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




Plan B: project’s outcome if something goes wrong

Plan A: project’s outcome if everything goes fine


Delivery date

Release 3

Release 1

Release 4

Release 2

Release 5


  Synchronize & Stabilize!



Under what conditions iterative and incremental development (IID) model

could be applicable?


Delivery date

Release 3

Release 1

Release 4

Release 2

Release 5




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



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



Agile software development



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



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



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)



Scrum



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”)



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)



Selecting the Process Model



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



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



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



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)



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






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






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)






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)



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


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



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


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



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



“[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.



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




Thank you.

Questions?

Tuomas Niinimäki

[email protected]

Date post:	12-Jan-2015
Category:	Documents
Upload:	tuomasniinimaki
View:	686 times
Download:	1 times

2 Process

Documents