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? Timeboxing Cannot ensure desired quality for industrial-strength software
CSIS0521 Process Models 3 CSIS0521 Process Models 4
Waterfall Model
Linear sequence of stages/phases
Requirements – System Design – 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 Requirement 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 waterfall model 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 – Analysis, 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 Project Management 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