<<

Process Models Projects Process

„ If a project chooses a model, it will generally tailor it „ A process model specifies a general to suit the project process, usually as a set of stages „ This produces the spec for the projects process „ This model will be suitable for a class of „ This process can then be followed in the project „ i.e. process is what is actually executed; process spec projects is plan about what should be executed; process „ i.e. a model provides generic structure model is a generic process spec „ Many models have been proposed for the of the process that can be followed by development process some projects to achieve their goals

CSIS0521 Process Models 1 CSIS0521 Process Models 2

Typical Student Process Model Common Process Models

„ Get problem statement – code – do „ Waterfall – the oldest and widely used

some testing – deliver/demo „ Prototyping

„ Why this process model cannot be used „ Iterative – currently used widely for commercial projects? „ „ Cannot ensure desired quality for industrial-strength

CSIS0521 Process Models 3 CSIS0521 Process Models 4

Waterfall Model

„ Linear sequence of stages/phases

„ – System – Detailed Design – Code – Test – Deploy

„ A phase starts only when the previous has completed; no feedback

„ The phases partition the project, each addressing a separate concern

CSIS0521 Process Models 5 CSIS0521 Process Models 6

1 Waterfall… Waterfall Advantages

„ Linear ordering implies each phase should „ Conceptually simple, cleanly divides the have some output problem into distinct phases that can be „ The output must be validated/certified performed independently

„ Outputs of earlier phases: work products „ Natural approach for problem solving „ Common outputs of a waterfall: SRS „ Easy to administer in a contractual (Software Specification), setup – each phase is a milestone project plan, design docs, test plan and reports, final code, supporting docs

CSIS0521 Process Models 7 CSIS0521 Process Models 8

Waterfall disadvantages Waterfall Usage

„ Assumes that requirements can be „ Has been used widely

specified and frozen early „ Well suited for projects where „ May fix hardware and other requirements can be understood easily technologies too early and technology decisions are easy

„ all or nothing delivery; too risky „ i.e. for familiar type of projects it still

„ Very document oriented, requiring docs may be the most optimum at the end of each phase

CSIS0521 Process Models 9 CSIS0521 Process Models 10

Prototyping Prototyping

„ Prototyping addresses the requirement specification limitation of waterfall „ Instead of freezing requirements only by discussions, a prototype is built to understand the requirements „ Helps alleviate the requirements risk „ A small replaces the requirements stage

CSIS0521 Process Models 11 CSIS0521 Process Models 12

2 Prototyping Prototyping

„ Development of prototype „ Cost can be kept low

„ Starts with initial requirements „ Build only features needing clarification „ “quick and dirty” – quality not important, „ Only key features which need better understanding are included in prototype scripting etc can be used „ Things like exception handling, recovery, „ No point in including those features that standards are omitted are well understood „ Cost can be a few % of the total „ Feedback from users taken to improve the „ Learning in prototype building will help in understanding of the requirements building, besides improved requirements

CSIS0521 Process Models 13 CSIS0521 Process Models 14

Prototyping Iterative Development

„ Advantages: requirements will be more stable „ Counters the “all or nothing” drawback of the and frozen later, experience helps in the main waterfall model

development „ Combines benefit of prototyping and waterfall

„ Disadvantages: Potential hit on cost and „ Develop and deliver software in increments schedule „ Each increment is complete in itself „ Applicability: When requirements are hard to „ Can be viewed as a sequence of waterfalls elicit and confidence in requirements is low; i.e. where requirements are not well „ Feedback from one iteration is used in the understood future iterations

CSIS0521 Process Models 15 CSIS0521 Process Models 16

Iterative Enhancement Iterative Development

„ Products almost always follow it

„ Used commonly in customized development also

„ Businesses want quick response for sw

„ Cannot afford the risk of all-or-nothing

CSIS0521 Process Models 17 CSIS0521 Process Models 18

3 Iterative Development Timeboxing

„ Benefits: Get-as-you-pay, feedback for „ Iterative is linear sequence of iterations improvement, „ Each iteration is a mini waterfall – „ Drawbacks: Architecture/design may decide the specs, then plan the iteration not be optimal, rework may increase, „ Time boxing – fix an iteration duration, total cost may be more then determine the specs „ Applicability: where response time is „ Divide iteration in a few equal stages important, risk of long projects cannot „ Use pipelining concepts to execute be taken, all requirements not known iterations in parallel

CSIS0521 Process Models 19 CSIS0521 Process Models 20

Time Boxed Iterations Time boxed Iteration

„ General iterative development – fix the „ This itself very useful in many situations

functionality for each iteration, then „ Has predictable delivery times plan and execute it „ Overall product release and marketing „ In time boxed iterations – fix the can be better planned duration of iteration and adjust the „ Makes time a non-negotiable parameter functionality to fit it and helps focus attention on schedule „ Completion time is fixed, the „ Prevents requirements bloating functionality to be delivered is flexible „ Overall dev time is still unchanged CSIS0521 Process Models 21 CSIS0521 Process Models 22

Timeboxing – Taking Time Boxed Iterations Further Timeboxing Model – Basics

„ What if we have multiple iterations „ Development is done iteratively in fixed executing in parallel duration time boxes „ Each time box divided in fixed stages „ Can reduce the average completion „ Each stage performs a clearly defined task time by exploiting parallelism that can be done independently „ For parallel execution, can borrow „ Each stage approximately equal in duration pipelining concepts from hardware „ There is a dedicated team for each stage „ When one stage team finishes, it hands over „ This leads to Timeboxing Process Model the project to the next team

CSIS0521 Process Models 23 CSIS0521 Process Models 24

4 Timeboxing Example

„ With this type of time boxes, can use „ An iteration with three stages – , pipelining to reduce cycle time Build, Deploy „ These stages are approximately equal in „ Like hardware pipelining – view each many situations iteration as an instruction „ Can adjust durations by determining the „ As stages have dedicated teams, boudaries suitably simultaneous execution of different „ Can adjust duration by adjusting the team iterations is possible size for each stage „ Have separate teams for A, B, and D

CSIS0521 Process Models 25 CSIS0521 Process Models 26

Pipelined Execution Timeboxing Execution

„ AT starts executing it-1 Software

„ AT finishes, hands over it-1 to BT,

Requirements Build Deploy starts executing it-2 TB1

„ AT finishes it-2, hands over to BT; BT Requirements Build Deploy TB2 finishes it-1, hands over to DT; AT

Requirements Build Deploy starts it-3, BT starts it-2 (and DT, it-1) TB3

Requirements Build Deploy „ … TB4

CSIS0521 Process Models 27 CSIS0521 Process Models 28

Timeboxing execution Timeboxing execution

„ First iteration finishes at time T „ Duration of each iteration still the same

„ Second finishes at T+T/3; third at T+2 „ Total work done in a time box is also T/3, and so on the same „ In steady state, delivery every T/3 time „ Productivity of a time box is same „ If T is 3 weeks, first delivery after 3 wks, 2nd after 4 wks, 3rd after 5 wks,… „ Yet, average cycle time or delivery time has reduced to a third „ In linear execution, delivery times will be 3 wks, 6 wks, 9 wks,…

CSIS0521 Process Models 29 CSIS0521 Process Models 30

5 Team Size Team Size

„ In linear execution of iterations, the „ Merely by increasing the team size we cannot same team performs all stages reduce cycle time - Brook’s law „ Adding manpower to a late software project „ If each stage has a team of S, in linear makes it later. execution the team size is S „ Timeboxing allows structured way to add „ In pipelined execution, the team size is manpower to reduce cycle time three times (one for each stage) „ Note that we cannot change the time of an „ i.e. the total team size in timeboxing is iteration – Brook’s law still holds larger; and this reduces cycle time

CSIS0521 Process Models 31 CSIS0521 Process Models 32

Work Allocation of Teams Timeboxing

„ Advantages: Shortened delivery times, other Requirements Requirements Requirements Requirements Requirements adv of iterative, distributive execution Team Analysis for TB1 Analysis for TB2 Analysis for TB3 Analysis for TB4 „ Disadvantages: Larger teams, proj mgmt is Build Team Build for TB1 Build for TB2 Build for TB3 Build for TB4 harder, high synchronization needed

„ Applicability: When short delivery times very Deployment Deployment for TB1Deployment for TB2Deployment for TB3 Team important; architecture is stable; flexibility in feature grouping

CSIS0521 Process Models 33 CSIS0521 Process Models 34

Summary Summary – waterfall

„ Process is a means to achieve project Strength Weakness Types of Projects objectives of high quality and productivity Simple All or nothing – too Well understood Easy to execute risky problems, short „ Process models define generic process, which Intuitive and logical Requirement frozen duration projects, automation of can form basis of project process Easy contractually early May chose outdated existing manual „ Process typically has stages, each stage hardware/tech systems focusing on an identifiable task Disallows changes „ Many models for development process have No feedback from been proposed users Encourages requirement bloating

CSIS0521 Process Models 35 CSIS0521 Process Models 36

6 Summary – Prototyping Summary – Iterative

Strength Weakness Types of Projects Strength Weakness Types of Projects Regular deliveries, Overhead of For businesses Helps requirement Front heavy Systems with novice leading to biz benefit planning each where time is imp; elicitation users; or areas with Possibly higher cost Can accommodate iteration risk of long projects requirement Reduces risk and schedule changes naturally Total cost may cannot be taken; uncertainty. Better and more Encourages increase requirement not Heavy reporting Allows user feedback stable final system requirement bloating System arch and known and evolve based systems can Avoids requirement with time Disallows later bloating design may suffer change benefit from UI prototyping Naturally prioritizes Rework may increase requirement Allows reasonable exit points Reduces risks CSIS0521 Process Models 37 CSIS0521 Process Models 38

Summary – Timeboxing

Strength Weakness Types of Projects All benefits of Where very short iterative becomes more delivery times are Planning for complex very important iterations somewhat Team size is larger Where flexibility in easier Complicated – lapses grouping features Very short delivery can lead to losses Arch is stable times

CSIS0521 Process Models 39

7