SE-381Software Engineering

BEIT-VLecture no. 11

Software Process Models – 3 of 4

Prototyping Model

• Can be used to clarify Requirements, to design User Interface, demonstrate feasibility, verify the new technology will work, or to provide a training system

• Cannot be used for embedded software, real-time control software or scientific or Engineering numerical computational software

• Tools for developing good quick prototypes are scarce, some HLLs are providing routine libraries, whereas systems like Smalltalk could not survive or capture market

Prototyping Model

• Ensures that customer gets what s/he wanted• Customer is provided a working version of software i.e.

prototype at a very early stage• Customer plays with it and suggests needed

amendments and developer incorporates them into the prototype

• User/customer needs/requirements are thus refined and defined, and the software could be developed using these requirements

Prototyping ModelPrototyping Model could be of two types:• Rapid or Throwaway prototype Model• Evolutionary Prototype Model

Rapid or Throwaway Prototyping ModelUses rapid techniques to construct prototypes that are thrown away once users’ requirements have been established

Evolutionary Prototyping ModelEvolves the initial prototype into the final software as the requirements are clarified

Prototyping Model

Pressman (1992) – SEPA3

Prototyping Model• Problems & Real-life

– Prototyping is a historical technique of Engineering Discipline, Chemical Engg, Aerodynamics

– User not aware what he wants

– Developer not sure how good his Algorithms or Code would perform

– Client ignorant of expected output. Changes to come by use of the Sw Product

• Different Types– Paper Prototype– PC Based Screen layouts– Software developed to

initiate User Interaction with the system

• How Done– Client & Developer meet

and sort out Requirements– A quick design– Implementation– Accommodation of user

Feedback

Prototyping Model .

• Cons• The developed Prototype should not be taken as Product• According to Brooks 1975, it should be a ‘Throwaway Version’ of

the product but is it possible?• Customer Pressure to take Prototype as Product, and Developer

Shortcuts to get the Prototype working• Should be used as a tool for Requirement Phase

• Client be explained at the outset that after getting Prototype accepted the ‘Product’ will be re-engineered.

Rapid Prototyping Model

Jal05 – Prototyping Model

[Bel05] Throwaway Prototype Model

Rapid Prototyping Model• Pros

– A new model, using the developed Prototype as a Front-end to your SD process, to gather – User

Requirements,– Clients’

experience with the Sw (Prototype)

– Insight to the Algorithms used and how efficient these are

– A tool/guide for all who are involved in SD of the product to improve their area

• Prototype used as– A tool for

Requirements phase

• Rest Follow the remaining phases linearly

• Iteration introduced by– Maintenance phase, for

– Corrective– Adaptive and– Perfective changes

[Bel05] Evolutionary Prototype Model

Evolutionary Versus Rapid Prototypes

– Rapid Prototypes start from incomplete specifications, go through a ‘quick’ design and development and these are improved on users’ or clients’ response. The final output is the clarified Requirements. These are used to develop the system

– Evolutionary Prototypes start from initial specifications, designed thoroughly and incorporate the users’/clients’ response. The evolved system turns out to be the final system

Prototyping Model – An Example

Problem Statement

Write a software program that can check the general knowledge of a user, specifically his/her knowledge about geography and history of Indo-Pakistan.

This is to be used by general public, so its implementation in national language will be preferred.

References

[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping

[Jal97] Pankaj Jalote (1997); An Integrated Approach to Software Engineering; 2nd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes

[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle Models

The relevant parts of the above chapters to be read at home.

Software Process Models

Commonly used SDLC Models– Build-n-Fix Model– Classical and Water Fall Model– Prototyping (Rapid and Evolutionary) Model– Incremental Model– Timeboxing Model– Risk Based Models

• Spiral Model– eXtreme Programming– Synchronise and Stabilize Model Object Oriented Life

Cycle Models - Fountain Model– Unified Process Model– Open Source Software Development Model

Incremental Model• Real-life

– Artifacts or buildings, large projects are built incrementally

• In this Model we– Design an Open-ended

architecture in mind to support incremental growth

– Compile a “Project Control List” (PCL) containing all tasks or functions

– Different functions/parts supported in different ‘builds’

• The Product is– Designed, implemented,

integrated and tested as series of incremental ‘Builds’ where a build consists of code pieces from various modules interacting to provide a specific functional capability

– Product goes through the cycle of Design, Implementation and Analysis

– In Analysis you decide what is to be included from PCL into the next build or Iteration

Incremental or Iterative Process

Design0

Implementation0

Analysis0

Design1

Implementation1

Analysis1

Designn

Implementationn

Analysisn

Iterations

.

.

.

Build 0 Build 1 Build n

Formulate Project Control List (PCL)

Decide the Contents of Different Builds

Incremental Model

Incremental Model ..

• Pros• Software Products are models of Real-life which is prone to

Change, Incremental Model has in-built capability to handle change

• Early delivery of Operational product• Smooth transition of Users of the Product from manual to

automated system• Simple and financially/functionally crucial builds can be developed

earlier and complex ones later• All, to be supported tasks, are listed, prioritized and high priority

tasks are put in earlier builds and more complex tasks are included in later builds (Millers law – At any one time, we humans are capable of concentrating on 5 ± 2 chunks of information 1956)

• Lesser financial burden on the client as it is developed and delivered incrementally, the benefits from use of the product start pouring in early

Incremental Model …• Cons

– Incomplete system as compared to well tested/documented product produced by WF or RP models

– Well thought and flexible architectural design needed– Each new build has to strengthen, co-exist and conform to the already

built system– Too many builds may blur the boundaries or configurations of the

product and can loosen the developers control on the product, whereas too few builds can also transform the model to Build-n-fix or Waterfall model by de-linking the development process from the client for a longer time. Hence a balance on number of builds is to be maintained.

– Two different views for Design and Development are confusing

• Can the skill-set specific to different phases be shared ?

Incremental Model ….

• Skill-set specific to different phases can be shared!• After Requirements and specification, a team can be assigned

to specify the Build1• As they finish the Specification of Build 1, the second team

can be assigned to Design Build 1, and the first team can start specifying Build 2, and so on

• The work on multiple Builds can be taken in Parallel, and experience/skills learnt by the teams from previous Builds can be used in the development of subsequent builds

• What are possible problems?

Concurrent Incremental Model

SE-381Software Engineering

BEIT-VLecture no. 12

Software Development Life Cycle (SDLC) Models4 of 4

Incremental or Iterative Enhancement Model Contd.

• Douglas Bell 2005 has emphasized the implementation part of Incremental Model

– Architectural Design has to be done thoroughly and should be flexible and open ended

– Can be implemented using several approaches• Top Down Approach• Bottom Up Approach• Middle Out Approach• Use Case Based Approach

– The implementation approach to SD is like scaffolding to building construction

– Scaffolding provides » Support to structure and » Access to structure, like an Arch Stone in an Arch,

similarly– Test bed has to provide support and Access to the Sw

components

Test Beds, Test Drivers or Test Harnesses/Oracles are the programs which are used to call the other component programs so as if these are called and used in the actual environment

Stubs are dummies, written with the same interface and name, for the program components which are still not ready

Top Down Approach for Software Development

Bottom Up Approach for Software Development - 1

Bottom Up Approach for Software Development - 2

• Middle Out Approach– We take components from the middle of the

hierarchy (Architectural Design) and develop and test them and then their related ones and so proceed on.

• Use Case Based Approach– We write Use Cases for the respective system and

start developing Use Case by Use Case– ‘Use Case’ is Usage Case, how the user will be

interacting with the system, and usually it is the implementation of some Functional Requirement of the system.

Incremental Model

• Pros• Product is made available (though with limited

functionality) within weeks as compared to Waterfall or Rapid Prototyping Models output which might take months or years

• Slow and productive transition of users/clients working environment with the evolution of developed product

• Phased delivery relieves client from high initial capital costs and gives higher RoI (Return on Investment) due to early use of product

Incremental Model• Cons

• Too few builds degenerate the Incremental Model into Build-n-Fix model or WF Model

• Too many builds will waste more time on Integration testing, and blur configuration boundaries

• Open ended Architectural Design needed for required flexibility, demands expertise which is scarce,

• More effort is required to support all sorts of maintenance and extension in the later builds

• Concurrent Incremental model is risky, more than one builds constructed simultaneously without stabilising the lower level builds.

Timeboxing

• Is iterative, has linear sequence of iterations• Each iteration is a mini waterfall – decide the

specs, then plan the iteration• Time boxing – fix an iteration duration, then

determine the specs• Divide iteration in a few equal stages• Use pipelining concepts to execute iterations

in parallel

Time Boxed Iterations

• General iterative development – fix the functionality for each iteration, then plan and execute it

• In time boxed iterations – fix the duration of iteration and adjust the functionality to fit-in

• Completion time is fixed, the functionality to be delivered is flexible

Time boxed Iteration

• 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 / freezing• Overall development time is still unchanged,

instead improved i.e. cycle time reduced

Timeboxing Model – 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, can borrow pipelining concepts from hardware

• This leads to Timeboxing Process Model

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

Timeboxing

• With this type of time boxes, can use pipelining to reduce cycle time

• Like hardware pipelining – view each iteration as set of instructions being executed on an artifact

• As stages have dedicated teams, simultaneous execution of different iterations is possible

Example

• An iteration with three stages – Analysis, Build, Deploy– These stages are approximately 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 - Analysis, B - Build,

and D - Design

Pipelined Execution

• AT (Analysis Team) starts executing it-1• AT finishes, hands over it-1 to BT (Build Team),

starts executing it-2• AT finishes it-2, hands over to BT; BT finishes

it-1, hands over to DT (Design Team); AT starts it-3, BT starts it-2 (and DT, it-1)

• …

Timeboxing Execution

Software

Requirements Build Deploy

TB1

TB2

Requirements Build Deploy TB2

Requirements Build Deploy TB3

Requirements Build Deploy TB4

Timeboxing execution

• First iteration finishes at time T• Second finishes at T+T/3; third at T+2 T/3, and

so on• In steady state, delivery every T/3 time• If T is 3 weeks, first delivery after 3 wks, 2nd

after 4 wks, 3rd after 5 wks,…• In linear execution, delivery times will be 3

wks, 6 wks, 9 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

Team Size

• In linear execution of iterations, the same team performs all stages

• If each stage has a team of size S, in linear execution the team size is S

• In pipelined execution, the team size is three times (one for each stage)

• That is, the total team size in timeboxing is larger; and this reduces cycle time

Team Size

• Merely by increasing the team size we cannot reduce cycle time - Brook’s law

• Time boxing 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

Work Allocation of Teams

Requirements Team

RequirementsAnalysis for TB1

RequirementsAnalysis for TB3

RequirementsAnalysis for TB2

RequirementsAnalysis for TB4

Build Team

Deployment Team

Build for TB1 Build for TB2 Build for TB3

Deployment for TB1Deployment for TB2

Build for TB4

Deployment for TB3

Requirements Team

RequirementsAnalysis for TB1

RequirementsAnalysis for TB3

RequirementsAnalysis for TB2

RequirementsAnalysis for TB4

Build Team

Deployment Team

Build for TB1 Build for TB2 Build for TB3

Deployment for TB1Deployment for TB2

Build for TB4

Deployment for TB3

Timeboxing

• Advantages: Shortened delivery times, other advantage of iterative and distributed execution

• Disadvantages: Larger teams, project mgmt is harder, high synchronization needed, Configuration Management is harder

• Applicability: – When short delivery times is emphasized;– Architecture is stable; – Flexibility in feature grouping is possible

Summary

• Process is a means to achieve project objectives of high Quality and Productivity

• Process models define generic process, which can form basis of project process

• Process typically has stages, each stage focusing on an identifiable task

• Many models for development process have been proposed

Summary – waterfall

Strength Weakness Types of Projects

SimpleEasy to executeIntuitive and logicalEasy to sign contracts

All or nothing – too riskyRequirements frozen earlyMay choose outdated hardware/technologyDisallows changesNo feedback from usersEncourages requirem-ents bloating

Well understood problems, short duration projects, automation of existing manual systems

Summary – PrototypingStrength Weakness Types of Projects

• Helps Requirements elicitation

• Stabilized User Requirements

• Reduces risk• Better and more

stable final system

•Front heavy•Possibly higher cost and schedule•Disallows later change•Encourages requirements bloating

•Systems with novice users; or areas with requirements uncertainty.•Heavy reporting based systems can benefit from UI prototypes

Summary – Iterative

Strength Weakness Types of Projects

•Regular deliveries, leading to business 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 architecture and design may suffer•Rework may increase

•For businesses where time is important; •risk of long projects cannot be taken; Requirements not known and evolve with time

Summary – TimeboxingStrength 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 there is flexibility in grouping features•Architecture is stable

References

[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping

[Jal97/05] Pankaj Jalote (1997,2005); An Integrated Approach to Software Engineering; 2nd /3rd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes

[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle Models

The relevant parts of the above chapters to be read at home.

Assignment no 2Deadline to be handed in on Oct 15, 2012 (Monday)Individual Assignment, 3-paged preferably hand-

written, Cheated will earn Zero marks, delayed submissions will loose 1 mark per delayed working day, will be evaluated by viva, if required.

Choose the topic on the basis of your registration no, [mod(Reg#,5)+1=n where n has a value given below]1. Spiral Model2. eXtreme Programming3. Synchronise and Stabilize Model4. Unified Process Model5. Open Source Software Development Model

References

[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping

[Jal97] Pankaj Jalote (1997); An Integrated Approach to Software Engineering; 2nd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes

[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle Models

The relevant parts of the above chapters to be read at home.