Post on 20-Jan-2016
transcript
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.