Software Engineering, Lectures

1. SE-381
Software Engineering
BEIT-V
Lecture no. 11
Software Process Models – 3 of 4
Incremental, Iterative

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. 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. 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. Incremental Model

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. 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. 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. Concurrent Incremental Model

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. – 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. Top Down Approach for Software
Development

13. Bottom Up Approach for Software
Development - 1

14. Bottom Up Approach for Software
Development - 2

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. 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. 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. SE-381
Software Engineering
BEIT-V
Lecture no. 12
Software Process Models – 4 of 4
Time Boxing Model & Summary

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. 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. 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. 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. 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. 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. 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. 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. 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. Timeboxing Execution
Software
Requirements Build Deploy
TB1
TB2
Requirements Build Deploy
TB2
Requirements Build Deploy
TB3
Requirements Build Deploy
TB4

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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