What are software process models, How they differ with each other, Criteria for selecting a specific model for a project.

1. Software Process Models
Spring 2020
Shaukat Wasi
Some slides taken from Roddy

2. Level 1 – Ad
Hoc

3. Code & Fix
• The earliest approach
• Write code
• Fix it to eliminate any errors that have been
detected, to enhance existing functionality,
or to add new features
• Source of difficulties
and deficiencies
– impossible to predict
– impossible to manage

4. Models are needed
• Symptoms of inadequacy: the
software crisis
– scheduled time and cost exceeded
– user expectations not met
– poor quality
• The size and economic value of
software applications required
appropriate "process models"

5. Process model goals
(B. Boehm 1988)
“Determine the order of stages involved in
software development and evolution, and
to establish the transition criteria for
progressing from one stage to the next.
….
Thus a process model addresses the
following software project questions:
– What shall we do next?
– How long shall we continue to do it?"

6. Software Process Model
Attempt to organize the software life cycle by
• defining activities involved in software production
• order of activities and their relationships
Goals of a software process
– standardization, predictability, productivity, high
product quality, ability to plan time and budget
requirements

7. Software Process model with Umbrella
Activities

8. Choosing a Software Process Model

9. Process as a "black box"
Product
Informal
Requirements
Process

10. Process as a "white box"
Product
Informal
Requirements
Process
feedback

11. Waterfall Model

12. Waterfall model
• Invented in the late 1950s for large air
defense systems, popularized in the
1970s
• They organize activities in a sequential
flow
• Exist in many variants, all sharing
sequential flow style

14. Critical evaluation of the
waterfall model
+ software process subject to
discipline, planning, and
management
+ postpone implementation to
after understanding objectives
– linear, rigid, monolithic
– no feedback
– no parallelism
– a single delivery date

15. Problems with waterfall
• Estimates made when limited
knowledge available
• Difficult to gather all requirements once
and for all
– users may not know what they want
– requirements cannot be frozen

16. Best Suited for:
 Mission Critical Projects
 No choice for errors
 Well defined Requirements
 NOT Time critical

17. V Model

18. Waterfall model variation – V Model

19. V and V Combined
 Verification
 In the concept of verification in the V-Model, static analysis technique is carried
out without executing the code. This evaluation procedure is carried out at the
time of development to check whether specific requirements will meet or not.
 Validation
 This concept of V-Model comprises of dynamic analysis practice (both functional as
well as non-functional), and testing is done by code execution. The validation of a
product is done once the development is complete for determining if the software
meets up the customer hope needs.
 So both verification and validation are combined and work in parallel to make
the V-Model fully functional.

20. Incremental Model

21. Increment?
• Increment refers to the quantifiable outcome
of each iteration
• Increment has the obvious implication that
there should be more of something at the
end of an iteration than there was at the
start.
• Incremental development is a staging and
scheduling strategy ‘’in which the various
parts of the system are developed at
different times or rates, and integrated as
they are completed.’’

22. Iteration?
• Iteration refers to the cyclic nature of a
process in which activities are repeated
in a structured manner.
• Iterative development is a rework
scheduling strategy ‘’in which time is set
aside to revise and improve parts of the
system.’’

23. Iterative and
incremental
 Product vs Process:
• Incremental fundamentally
means add onto. Incremental
development helps you improve
your process.
• Iterative fundamentally means
re-do. Iterative development
helps you improve your
product.
In
Code:
while ( project.isRunning() ) {
project.bugsFixed++;
project.featuresComplete++;
}

24. Iterative VS
incremental

25. Incremental development
• Rather than deliver the system as a single
delivery, the development and delivery is
broken down into increments with each
increment delivering part of the required
functionality
• User requirements are prioritised and the
highest priority requirements are included in
early increments
• Once the development of an increment is
started, the requirements are frozen though
requirements for later increments can
continue to evolve

26. Evolutionary Models

27. Evolutionary Models
 Iterative + Incremental
 Usually a set of core product or system requirements is
well understood, but the details and extension have yet to
be defined.
 It is iterative that enables you to develop increasingly
more complete version of the software i.e. evolution of
software.
 Two Types: Prototyping and Spiral

30. Spiral
Model

31. Spiral Model
 Iterative (multiple passes over the circuits) + Incremental
(Each circuit adds next level to development) + Risk
Driven
 Based on Water fall model (Same steps in sequence)
 The first circuit in the clockwise direction might result
in the product specification; subsequent passes
 around the spiral might be used to develop a prototype
and then progressively more sophisticated versions
 of the software. Each pass results in adjustments to
the project plan. Cost and schedule are adjusted based
 on feedback. Also, the number of iterations will be
adjusted by project manager.

32. 3 Concerns on Evolutionary Processes
1. Planning is at Risk in prototyping model due to uncertain
no: of cycles required to reach the final product.
2. Development speed is some what slow as the iterations
need time to cover the improvements. Hence being too
fast will bring the process to chaos and being too slow will
effect the productivity.
3. High Quality VS Timely delivery tradeoff. Iterations do
improve but to what extent iterations are to be added is a
question.

33. Unified Process Modeling (UPM)

34. Unified Process Model (UPM)
 Integrating two seemingly contradicting insights:
 Definitive activities and deliverables as in the Waterfall Model.
 Iterative and incremental processes.
 A project is split into several phases:
 Each phase is split into several iterations.
 Each iteration consists of the traditional process activities, known
as workflow.
 Each workflow places different emphasis on the activities
depending on the current iteration.

36. AGILE Process Models

37. Remember waterfall?

38. Work together!

39. Agile Manifesto
“We are uncovering better ways of developing software by
doing it and helping others do it.
Through this work we have come to value:
•Individuals and interactions over processes and tools
•Working software over comprehensive documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.”
Kent Beck et al

40. Scrum
• Focus on software development without
defining phases and workproducts, only
focus on increments through sprints
• “Getting things done”
• Roles:
– Scrum Master
– Product Owner
– Team member
• Especially useful for experienced developers

41. Scrum

42. Scrum

43. Kanban
Similar to Scrum but Priority Based instead of Time Based

44. SCRUM VS KANBAN
https://www.developmentthatpays.com/files/DevelopmentThatPays-ScrumVsKanban-
CheatSheet-1_6.pdf

45. Extreme Programming

46. Extreme Programming – Top Principles

47. XP vs SCRUM
https://www.visual-paradigm.com/scrum/extreme-programming-vs-scrum/

48. Selection criteria for lifecycle
models

49. Conclusion

50. When to
embrace Agile
Methodologies

51. Choosing a Software Process Model