Successfully reported this slideshow.
SE-381
Software Engineering
BEIT-V
Lecture no. 11
Software Process Models – 3 of 4
Incremental, Iterative
Software Process Models
Commonly used SDLC Models
– Build-n-Fix Model
– Classical and Water Fall Model
– Prototyping (Rapi...
Incremental Model
• Real-life
– Artifacts or buildings, large
projects are built
incrementally
• In this Model we
– Design...
Incremental or Iterative Process
Design0
Implementation0
Analysis0
Design1
Implementation1
Analysis1
Designn
Implementatio...
Incremental Model
Incremental Model ..
• Pros
• Software Products are models of Real-life which is prone to
Change, Incremental Model has in...
Incremental Model …
• Cons
– Incomplete system as compared to well tested/documented product
produced by WF or RP models
–...
Incremental Model ….
• Skill-set specific to different phases can be
shared!
• After Requirements and specification, a tea...
Concurrent Incremental Model
Incremental or Iterative Enhancement
Model Contd.
• Douglas Bell 2005 has emphasized the
implementation part of Incrementa...
– Scaffolding provides
» Support to structure and
» Access to structure, like an Arch Stone in an
Arch, similarly
– Test b...
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 th...
Incremental Model
• Pros
• Product is made available (though with limited
functionality) within weeks as compared to
Water...
Incremental Model
• Cons
• Too few builds degenerate the Incremental Model into
Build-n-Fix model or WF Model
• Too many b...
SE-381
Software Engineering
BEIT-V
Lecture no. 12
Software Process Models – 4 of 4
Time Boxing Model & Summary
Software Process Models
Commonly used SDLC Models
– Build-n-Fix Model
– Classical and Water Fall Model
– Prototyping (Rapi...
Timeboxing
• Is iterative, has linear sequence of iterations
• Each iteration is a mini waterfall – decide the
specs, then...
Time Boxed Iterations
• General iterative development – fix the
functionality for each iteration, then plan and
execute it...
Time boxed Iteration
• Useful in many situations
• Has predictable delivery times
• Overall product release and marketing ...
Timeboxing Model – Taking Time
Boxed Iterations Further
• What if we have multiple iterations executing
in parallel
• Can ...
Timeboxing Model – Basics
• Development is done iteratively in fixed duration
time boxes
• Each time box divided in fixed ...
Timeboxing
• With this type of time boxes, can use
pipelining to reduce cycle time
• Like hardware pipelining – view each ...
Example
• An iteration with three stages –
Analysis, Build, Deploy
– These stages are approximately equal in many
situatio...
Pipelined Execution
• AT (Analysis Team) starts executing it-1
• AT finishes, hands over it-1 to BT (Build
Team), starts e...
Timeboxing Execution
Software
Requirements Build Deploy
TB1
TB2
Requirements Build Deploy
TB2
Requirements Build Deploy
TB...
Timeboxing execution
• First iteration finishes at time T
• Second finishes at T+T/3; third at T+2 T/3, and
so on
• In ste...
Timeboxing execution
• Duration of each iteration still the same
• Total work done in a time box is also the same
• Produc...
Team Size
• In linear execution of iterations, the same
team performs all stages
• If each stage has a team of size S, in ...
Team Size
• Merely by increasing the team size we cannot
reduce cycle time - Brook’s law
• Time boxing allows structured w...
Work Allocation of Teams
Requirements
Team
Requirements
Analysis for TB1
Requirements
Analysis for TB3
Requirements
Analys...
Timeboxing
• Advantages: Shortened delivery times, other
advantage of iterative and distributed
execution
• Disadvantages:...
Summary
• Process is a means to achieve project
objectives of high Quality and Productivity
• Process models define generi...
Summary – waterfall
Strength Weakness Types of Projects
Simple
Easy to execute
Intuitive and logical
Easy to sign contract...
Summary – Prototyping
Strength Weakness Types of Projects
• Helps
Requirements
elicitation
• Stabilized User
Requirements
...
Summary – Iterative
Strength Weakness Types of Projects
•Regular deliveries,
leading to business
benefit
•Can accommodate
...
Summary – Timeboxing
Strength Weakness Types of Projects
•All benefits of iterative
•Planning for iterations
somewhat easi...
References
[Bel05] Douglas Bell (2005); Software Engineering for
Students, 4th Edition, Pearson Education, New Delhi – Ch ...
Assignment no 1
Deadline to be handed in on March 24, 2012 (Friday)
Individual Assignment, 3-paged preferably hand-
writte...
Upcoming SlideShare
Loading in …5
×

Beit 381 se lec 11,12 - 41 - 12 mar16 - 3 & 4 of 4 - sdlc incremental and tb models

676 views

Published on

Software Engineering, Lectures

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

Beit 381 se lec 11,12 - 41 - 12 mar16 - 3 & 4 of 4 - sdlc incremental and tb models

  1. 1. SE-381 Software Engineering BEIT-V Lecture no. 11 Software Process Models – 3 of 4 Incremental, Iterative
  2. 2. 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
  3. 3. 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, integ rated 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
  4. 4. 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
  5. 5. Incremental Model
  6. 6. 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
  7. 7. 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 ?
  8. 8. 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?
  9. 9. Concurrent Incremental Model
  10. 10. 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
  11. 11. – 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 Drivers and 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
  12. 12. Top Down Approach for Software Development
  13. 13. Bottom Up Approach for Software Development - 1
  14. 14. Bottom Up Approach for Software Development - 2
  15. 15. • 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. – Use Cases can also help in Project Management, Tracking and Control
  16. 16. 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
  17. 17. 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.
  18. 18. SE-381 Software Engineering BEIT-V Lecture no. 12 Software Process Models – 4 of 4 Time Boxing Model & Summary
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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) • …
  28. 28. Timeboxing Execution Software Requirements Build Deploy TB1 TB2 Requirements Build Deploy TB2 Requirements Build Deploy TB3 Requirements Build Deploy TB4
  29. 29. 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,…
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. Work Allocation of Teams Requirements Team Requirements Analysis for TB1 Requirements Analysis for TB3 Requirements Analysis for TB2 Requirements Analysis 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 Requirements Analysis for TB1 Requirements Analysis for TB3 Requirements Analysis for TB2 Requirements Analysis 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
  34. 34. 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
  35. 35. 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
  36. 36. Summary – waterfall Strength Weakness Types of Projects Simple Easy to execute Intuitive and logical Easy to sign contracts All or nothing – too risky Requirements frozen early May chose outdated hardware/technology Disallows changes No feedback from users Encourages requirem- ents bloating Well understood problems, short duration projects, automation of existing manual systems
  37. 37. Summary – Prototyping Strength 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
  38. 38. 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
  39. 39. 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 there is flexibility in grouping features •Architecture is stable
  40. 40. 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.
  41. 41. Assignment no 1 Deadline to be handed in on March 24, 2012 (Friday) 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 Model 2. eXtreme Programming 3. Synchronise and Stabilize Model 4. Unified Process Model 5. Open Source Software Development Model

×