You are on page 1of 73

Software Processes

Sofware Process


Software Process

 

Process is distinct from product – products are outcomes of executing a process on a project. SW Engg. focuses on process. Proper processes will help to achieve project objectives of high Q Product.

Sofware Process


Software Process…
 

Process: A particular method, generally involving a number of activities Software Process: A set of activities, along with ordering constraints on execution, to produce software with desired result. Process that deals with the technical and management issues of software development is called a software process. Many types of activities performed by different people in a software project Better to view software process as comprising of many component processes. Component processes ????
Sofware Process 3

Component Software Processes  Two major processes   Development – focuses on development and quality steps needed to engineer the software Project management – focuses on planning and controlling the development process   Development process is the heart of software process. process project manager executes the mgmt process Sofware Process 4 . other processes revolve around it These are executed by different people   developers execute engg.

    Configuration management process: manages the evolution of artifacts Change management process: how changes are incorporated Process management process: management of processes themselves Inspection process: How inspections are conducted on artifacts Sofware Process 5 .Component Processes…  Other processes affect software development activity.

SDD. results in too many work products or documents.etc)    Having too many steps. How to perform a particular phase /step is addressed by methodologies for that activity. a process typically consists of a few steps. Prototype. each satisfying a clear objective and producing a document which can be verified.Code.Process Specification    Process is generally a set of phases(steps / activitities) Each phase performs a well defined task and generally produces an output Intermediate outputs – work products (SRS. Sofware Process 6 . Due to this.. At top level.

ETVX Specification  ETVX approach to specify a step     Entry criteria: what conditions must be satisfied for initiating this phase Task: what is to be done in this phase Verification: the checks done on the outputs of this phase eXit criteria: when can this phase be considered done successfully  A phase also produces info for mgmt Sofware Process 7 .

ETVX approach (A step in a development process) Sofware Process 8 .

Desired Characteristics of Software process      Predictability Support testability and Maintainability Support change Early defect removal Process improvement and feedback Sofware Process 9 .

past performance can be used to predict future performance Sofware Process 10 . or say anything about quality or productivity With predictability. outcome of a project should be predictable using a process Without predictability.e. cannot estimate.Predictability  Process should repeat its performance when used on different projects    i.

Predictability…   Predictable process is said to be under statistical control A process is under control if following the same process produces similar results-results will have some variation. but the variation is mostly due to random causes and not due to process issues.   Repeatedly using the process produces similar results To consistently develop sw with high Q&P. process must be in control Sofware Process 11 .

Sofware Process 12 .Example (estimating the cost of B from the project A)    Cost of B is similar to Cost of A (done 2 years back) Implies that process used to implement B is same as A That is. it assumes that process is predictable.

during the early phases of development process the prime issues should be “ Can it be easily tested ?” “Can it be easily modified?” Sofware Process 13 . Both testing and maintenance depend heavily on quality of design and code.Support testability and maintainability      Goal of the process should not be to reduce the effort of design and coding. Hence . but to reduce the cost of testing and maintenance.

  Support testability as testing is the most expensive task.Contd. over life up to 80% of total cost Sofware Process 14 .. testing can consume 30 to 50% of total development effort Support maintainability as maintenance can be more expensive some times than development.

example Requirement ----10%  Design -----------10%  Coding------------30%  Testing-----------50% (depends on organization)  Sofware Process 15 .

Support Change     Software changes for various reasons Requirements change is a key reason Requirement changes cannot be wished away or treated as “bad” They must be accommodated in the process for sw development Sofware Process 16 .

the process must support early defect removal That is why there is a Verification in ETVX. fixing a requirement defect in operation can cost a 100 times the cost of fixing it in requirements itself Hence.e. for high Q&P. and quality control tasks in the sw process Sofware Process 17 . as cost of removing defects increases with latency i.Early Defect Removal…     Remove defects early.

Early Defect Removal… Sofware Process 18 .

Software process is considered as closed loop process. the software process must be improved.Process improvement and feedback     Process is not a static entity. and each project done using the existing process must feed information back to facilitate this improvement. Sofware Process 19 . the process must be improved based on previous experiences. To satisfy the objectives of quality improvement and cost reduction. That is.

.Contd.Taking feedback from other processes and improve it.Taking feedback from early parts of projects and improve the rest of the project. Sofware Process 20 .  Process mgmt process involves in process improvement by : . .

each stage focusing on an identifiable task Stages have methodologies Software process consists of methods for developing software Best to view it as comprising of multiple processes Sofware Process 21 .Summary      Process – method for doing something Process typically has stages.

predictability. Other processes support development. and support for change Sofware Process 22 . Sw process should have high Q&P.Summary      Goal is to produce software with high quality and productivity Development process is central process Mgmt process is for controlling development.

Development Process and Process Models Sofware Process 23 .

Process Models  A model provides generic structure of the process that can be followed by some projects to achieve their goals Sofware Process 24 .

process model is a generic process specification Many models have been proposed for the development process Sofware Process 25 . process is what is actually executed.e. process specification is plan about what should be executed. it will generally tailor it to suit the project I.Process model    If a project chooses a model.

Typical Student Process Model

Get problem stmt – Code – do some testing – deliver/demo Why this process model cannot be used for commercial projects?

Produces student-software, which is not what we are after Cannot ensure desired quality for industrial-strength software
Sofware Process 26

Common Process Models

2. 3. 4.

Waterfall – the oldest and widely used Prototyping Iterative – currently used widely Timeboxing

Sofware Process


Waterfall Model

Phases are organized in Linear sequence of stages/phases A phase starts only when the previous has completed; no feedback The phases partition the project, each addressing a separate concern

Sofware Process


Sofware Process 29 .

project plan. final code. It has to be prepared before the other phase begins.Waterfall…      Linear ordering implies each phase should have some output The output must be verified and validated Outputs of earlier phases: work products Planning usually overlaps with the requirements analysis. software manuals Sofware Process 30 . test plan and reports. Common outputs of a waterfall: SRS. design docs.

Waterfall Advantages     Conceptually simple Cleanly divides the problem into distinct phases that can be performed independently Natural approach for problem solving Easy to monitor as each phase is completed & work product is produced. Sofware Process 31 .

too risky as the user doesnot know until the very end what they are getting Very document oriented.Waterfall disadvantages  Assumes that requirements can be specified and frozen before design begins Follows the “big bang”(one shot at end) approach – all or nothing delivery. requiring docs at the end of each phase May choose outdated hardware technology as requirements need to be freezed earlier User feedback not allowed Cycle time is too long Sofware Process 32      .

Waterfall Usage   Has been used widely Well suited for well understood problems. automation of existing manual systems Sofware Process 33 . short duration project.

Prototyping    Prototyping addresses the requirement specification limitation of waterfall Instead of freezing requirements only by discussions before design and coding phase. a prototype is built to understand the requirements Helps alleviate(ease) the requirements risk Sofware Process 34 .

Prototyping Sofware Process 35 .

Prototyping  Development of prototype    Starts with initial known requirements Only key features which need better understanding are included in prototype Feedback from users taken to improve the understanding of the requirements Sofware Process 36 .

Using prototype. design documents. the client get an actual feel of the system “quick and dirty” – quality not important Because the prototype is to be thrown away. a test plan. only minimal documentation needs to be produced during prototyping.coding & testing are not done formally. For example.Prototype…     The phases like designing. and a test case specification are not needed during the development of the prototype Sofware Process 37 .

Effective method of demonstrating the feasibility of a certain approaches ( not clear.Advantages …      Helps in requirements elicitation(better understanding). Leads to a better system Sofware Process 38 . to meet certain constraints and algorithms) Reduces risk Costs incurred due to later changes in the requirements are substantially reduced due to later changes in the requirements are substantially reduced.

Disadvantages   Possibly higher cost and schedule. so cost can be kept low By building only features needing clarification Disallows later changes Sofware Process 39 .

Usage of prototype    Suitable for complicated and large systems for which there is no manual process or existing system to help determine the requirements Systems with novice users When GUI is very important Sofware Process 40 .

Iterative Development       Counters the “all or nothing” drawback of the waterfall model (i.e the output/product is produced only at the end is solved in this model) Combines benefit of prototyping and waterfall Develop and deliver software in increments Each increment is complete in itself Can be viewed as a sequence of waterfalls Feedback from one iteration is used in the future iterations Sofware Process 41 .

Iterative development…. 2. 1. Iterative enhancement model Spiral model Sofware Process 42 .

Iterative Enhancement Sofware Process 43 .

Sofware Process 44 . implementation phase and analysis phase.Iterative enhancement…     First simple initial implementation is done for a subset of the overall problem Each increment provide a feedback to the client that is useful for determining the final requirements of the system A project control list is prepared which contain the tasks that must be performed to obtain the final implementation Each iteration removes the next task from the list and implements the task which include design phase.

The process is iterated until the project control list is empty.Contd…     Each iteration gives feedback to the next iteration Selection of tasks in this manner will minimize the chances of error and reduce the redesign work. Sofware Process 45 . The design and implementation phases of each step can be performed in a top-down manner or by using some other technique.

Inner most loop is concerned with the system feasibility. next loop with the requirement specification. Risks are explicitly assessed and resolved throughout the process.Spiral development      Process is represented as a spiral rather than as a sequence of activities with backtracking. No fixed phases such as specification or design . the next loop with system design & so on Sofware Process 46 . Each loop in the spiral represents a phase in the process.loops in the spiral are chosen depending on what is required.

Spiral model of the software process Sofware Process 47 .

Risk assessment and reduction  Risks are assessed and activities put in place to reduce the key risks. Sofware Process 48 . Planning  The project is reviewed and the next phase of the spiral is planned.Spiral model sectors     Objective setting  Specific objectives for the phase are identified. Development and validation  A development model for the system is chosen which can be any of the generic models.

Reduces risks Avoids requirements bloating(excess). Provide regular / quick deliveries. customer need not wait until entire system is implemented.Advantages       Get-as-you-pay. feedback for improvement Accommodates changes. Priorities requirements Better product Sofware Process 49 .

It may not be optimal.Disadvantages    Architecture/design may change due to frequent changes. rework may increase. total cost may be more as we need to undo the things Each iteration may have planning overhead Sofware Process 50 .

Usage    For business where time is of essence Risks are more Where requirements are not known and will be known only with time Sofware Process 51 .

then determine the specs Divide iteration in a few equal stages Use pipelining concepts to execute iterations in parallel Sofware Process 52 .Timeboxing      Iterative is linear sequence of iterations Each iteration is a mini waterfall – decide the specs. then plan the iteration Time boxing – fix an iteration duration.

then plan and execute it In time boxed iterations – fix the duration of iteration and adjust the functionality to fit it Completion time is fixed. the functionality to be delivered is flexible Sofware Process 53 .Time Boxed Iterations    General iterative development – fix the functionality for each iteration.

Time boxed Iteration       This itself very useful in many situations Has predictable delivery times Overall product release and marketing can be better planned Makes time a non-negotiable parameter and helps focus attention on schedule Prevents requirements bloating Overall dev time is still unchanged Sofware Process 54 .

can borrow pipelining concepts from hardware This leads to Timeboxing Process Model Sofware Process 55 .Timeboxing – Taking Time Boxed Iterations Further     What if we have multiple iterations executing in parallel Can reduce the average completion time by exploiting parallelism For parallel execution.

Timeboxing Model – Basics       Development is done iteratively in fixed duration time boxes Each time box divided in fixed stages Each stage performs a clearly defined task that can be done independently Each stage approximately equal in duration There is a dedicated team for each stage When one stage team finishes. it hands over the project to the next team Sofware Process 56 .

Timeboxing    With this type of time boxes. simultaneous execution of different iterations is possible Sofware Process 57 . can use pipelining to reduce cycle time Like hardware pipelining – view each iteration as an instruction As stages have dedicated teams.

Build.Example  An iteration with three stages – Analysis. B. Deploy    These stages are appx equal in many situations Can adjust durations by determining the boundaries suitably Can adjust duration by adjusting the team size for each stage  Have separate teams for A. and D Sofware Process 58 .

starts executing it-2 AT finishes it-2. hands over to DT. BT finishes it-1.Pipelined Execution     AT starts executing it-1 AT finishes. hands over it-1 to BT. AT starts it-3. it-1) … Sofware Process 59 . BT starts it-2 (and DT. hands over to BT.

Timeboxing Execution Software TB1 Requirements Build Deploy TB2 Requirements Build Deploy TB3 TB4 Requirements Build Requirements Deploy Build Deploy Sofware Process 60 .

Timeboxing execution      First iteration finishes at time T Second finishes at T+T/3. third at T+2 T/3. 3rd after 5 wks.… In linear execution. 9 wks. 2nd after 4 wks. first delivery after 3 wks. delivery every T/3 time If T is 3 weeks. and so on In steady state. 6 wks.… Sofware Process 61 . delivery times will be 3 wks.

Timeboxing execution     Duration of each iteration still the same Total work done in a time box is also the same Productivity of a time box is same Yet. average cycle time or delivery time has reduced to a third Sofware Process 62 .

and this reduces cycle time Sofware Process 63 . the total team size in timeboxing is larger. the same team performs all stages If each stage has a team of S.e.Team Size     In linear execution of iterations. the team size is three times (one for each stage) I. in linear execution the team size is S In pipelined execution.

Brook’s law Timeboxing allows structured way to add manpower to reduce cycle time Note that we cannot change the time of an iteration – Brook’s law still holds Work allocation different to allow larger team to function properly Sofware Process 64 .Team Size     Merely by increasing the team size we cannot reduce cycle time .

Work Allocation of Teams Requirements Requirements Requirements Requirements Requirements Analysis for TB1 Analysis for TB2 Analysis for TB3 Analysis for TB4 Team Build Team Build for TB1 Build for TB2 Build for TB3 Build for TB4 Deployment Team Deployment for TB1Deployment for TB2 Deployment for TB3 Sofware Process 65 .

Advantages   Shortened delivery times Planning and negotiations are easy Sofware Process 66 .

project mgmt is harder. Possibly increased cost Not suitable for projects where different iterations require different stages of different time length. Sofware Process 67 . high synchronization needed.Disadvantages      Larger teams.

. flexibility in feature grouping Sofware Process 68 .Usage    When short delivery times very imp. architecture is stable.

each stage focusing on an identifiable task Many models for development process have been proposed Sofware Process 69 . which can form basis of project process Process typically has stages.Summary     Process is a means to achieve project objectives of high QP Process models define generic process.

automation of existing manual systems 70 .Summary – waterfall Strength Simple Easy to execute Intuitive and logical Easy contractually Weakness All or nothing – too risky Req frozen early May chose outdated hardware/tech Disallows changes No feedback from users Encourages req bloating Sofware Process Types of Projects Well understood problems. short duration projects.

Heavy reporting based systems can benefit from UI proto Sofware Process 71 .Summary – Prototyping Strength Weakness Types of Projects Helps req elicitation Reduces risk Better and more stable final system Front heavy Possibly higher cost and schedule Encourages req bloating Disallows later change Systems with novice users. or areas with req uncertainity.

Summary – Iterative Strength Weakness Types of Projects Regular deliveries. leading to biz benefit Can accommodate changes naturally Allows user feedback Avoids req bloating Naturally prioritizes req Allows reasonable exit points Reduces risks Overhead of planning each iteration Total cost may increase System arch and design may suffer Rework may increase For businesses where time is imp. req not known and evolve with time Sofware Process 72 . risk of long projects cannot be taken.

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