The document discusses various software production process models, including traditional waterfall models, iterative models like the spiral model, and agile methodologies. Waterfall models involve sequential phases from requirements to maintenance but lack flexibility. Iterative models divide the process into increments with feedback between phases. Agile methods like Scrum, Extreme Programming, and Smart emphasize rapid, incremental delivery, automating processes, and customer involvement. The choice of model depends on factors like requirements volatility, team experience, and project priorities.

1. The software production process
Projectmanagement or software
proces models?

2. Goal
• Choose the best process
(or combination of
processes) for your
project.

3. What is Project Management?
• Project management encompasses all the
activities needed to plan and execute a project:
– Deciding what needs to be done
– Estimating costs
– Ensuring there are suitable people to undertake the
project
– Defining responsibilities
– Scheduling
– Making arrangements for the work
– Describe and handle risks
– continued ...

4. Software Process Models
• Software process models are general
approaches for organizing a project into
activities.
– Helps to decide:
• What work should be done;
• In what sequence to perform the work.
– The models should be seen as aids to thinking, not
rigid prescriptions of the way to do things.
– Each project ends up with its own unique plan.

6. Analysis
2%
Specification
5%
Module Testing
7%
Integration
8%
Maintenance
67%
Cost of making software?
Module Coding
5%
Design
6%
[Schach]

7. Life cycle
• The life cycle of a software product
– from inception of an idea for a product through
• requirements gathering and analysis
• architecture design and specification
• coding and testing
• delivery and deployment
• maintenance and evolution
• retirement

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

9. Level 1 – Ad Hoc

10. 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
• JBF 

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

12. Models are needed

13. 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?"

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

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

16. Overview of software process
models

17. Level 2 - Repeatable

18. Waterfall models (1)
• 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

20. Waterfall models (2)
• Organizations adopting them standardize
the outputs of the various phases
(deliverables)
• May also prescribe methods to follow in
each phase
– organization of methods in frameworks often
called methodology
• Example: Military Standard (MIL-STD-2167)
“If the computer program in question is being
developed for the first time, arrange matters so
that the version finally delivered to the customer is
actually the second version.”

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

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

23. Waterfall?

24. Example of list of documentation in a
waterfall project (DeGrace and Stahl)
• Original Problem Statement
• Options Analysis Document
• Cost-Benefit Analysis
Document
• Requirements document
• Preliminary Program Plan:
• Alternatives Analysis
Document
• Functional Specification
Document
• Preliminary Design
Document
• User's Guide
• Programmer's Guide
• User Test Plan
• User Training Plan
• Test Plan Outlines
• Test Reports
• Installation Plan
• ….

25. Alternatives – Sashimi

26. Alternatives – Staged Delivery

27. Level 3 - Defined

28. Evolutionary models
• Many variants available
• Product development evolves through
increments
– Evolutionary prototyping (McConnell)
– Evolutionary process model (B. Boehm, 1988)

29. Spiral Model (Boehm)

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

31. Level 4 - Managed

32. Unified Process
• Development of an OO system
• Uses the UML notation throughout the
process
• Supports an iterative and incremental process
• Decomposes a large process into controlled
iterations (mini projects)
• Different flavours available: UP, RUP, AUP,
UPEDU, EUP

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

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

35. RUP
Inception Elaboration ConstructionTransition

36. Iteration
CYCLE
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
PREPARATION
RELEASE
OnetoFour Weeks

37. 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++;
}

38. Distribution of workflows over
phases

39. Level 5 - Optimized

40. Remember waterfall?

41. Work together!

42. Agile methodologies
• A group of methodologies developed in the 90ties
• Addresses changes in industry: SE processes to sluggish for
quickly developing business processes
• Examples: Evo, Extreme Programming, Feature Driven
Development, Scrum, Smart
• Common features:
– Avoid big upfront design, requirements will change anyway
– Only address some priority features at a time
– Automate standard routines, in particular build and deployment
– Validate results automatically (automated testing)
– Design evolves, tool supported refactoring is used

43. Scrum
• Focus on softwaredevelopment without defining
phases and workproducts, only focus on
increments through sprints
• “Getting things done”
• Roles:
– Scrum Master
– Product Owner
– Teammember
• Ceremonies
• Especially useful for experienced developers

44. Scrum

45. Agile & UX
CYCLE
INTERFACEDESIGN
VISUALDESIGN
DEVELOPMENT
BUILD-OUT
TWOWEEKS
CYCLE
INTERFACEDESIGN
VISUALDESIGN
DEVELOPMENT
BUILD-OUT
TWOWEEKS
USER RESEARCH?
USER TESTING?
ORIGINAL THOUGHT?

46. Agile & UX
CYCLE
INTERFACEDESIGN
VISUALDESIGN/ BUILD-OUT
DEVELOPMENT
TWOWEEKS

47. Extreme programming
• Approach to development based on the
development and delivery of very small
increments of functionality
• Relies on constant code improvement, user
involvement in the development team and
pairwise programming

48. Extreme Programming

49. Extreme Programming

50. Smart
• Collection of lots of agile best practices
– Stand-ups
– Iterative and Incremental
– Describes workproducts and phases
– Planning poker
– Smart use cases and smart estimation
– On-site customer

51. Selection criteria for lifecycle models

52. Conclusion

53. Resources
• http://computerworld.nl/article/11491/wat-is-sdm.html
• http://www.infoq.com/news/2010/02/flavors-of-unified-process
• http://www.extremeprogramming.org/
• http://www.scrumalliance.org/learn_about_scrum
• http://www.accelerateddeliveryplatform.com/SmartIterationCycle.
ashx
• http://alistair.cockburn.us/Incremental+versus+iterative+developm
ent
• http://www.slideshare.net/whafro/design-and-ux-in-an-agile-
process-presentation
• McConnell, S. (1996). Rapid Development, Redmond: Microsoft
Press. ISBN 1-55615-900-5