sample use case templateexample test plan templateProject plan template
ICS 121: Process Models
- Why review process models?
- Some standard standard models
- How to evaluate processes
- What processes do people really use?
- Open source
- Product families
- Concurrent releases
Why review process models?
- Process models help us define the vocabulary that we need to
understand and evaluate particular software development methods.
- We will start with simple, theoretical models of software
- Then, we'll discuss practical concerns that gradually bring us
to the kinds of processes that people really use in industry.
Some Standard Process Models
- Just jump in and build it. Then fix, fix, fix, fix, fix...
- PROs: Very simple. Some immediate results.
- CONs: It looks like it should almost be ready, but it
never is. Customer trust is lost when expectations are not
- Do everything carefully once: requirements, design,
implementation, integration, testing, and deployment.
- PROs: If you do things right the first time, you don't
waste time on rework. Very easy to measure progress.
- CONs: It is very hard to guess right on the first try.
Easy estimate of progress can be misleading. Big cost at start with
no revenue until the end. There is a lot of time for the customer
or industry to change before final delivery.
- Do requirements first, break them into increments. Develop,
integrate, and test each functional increment.
- PROs: Reliably working releases fairly early. Partial revenue
stream fairly early.
- CONs: Still somewhat of a long process before first
release. Still some risk of paying a lot to satisfy the wrong
- Rapid prototyping / Operational prototyping
- Quickly build a prototype and show it to customers to validate
and refine requirements. Either throw away the prototype and start
the real system, or gradually evolve the prototype into a fully
- PROs: Much earlier and more reliable requirements validation.
Can work great when a previous system serves as the prototype.
- CONs: Replacing or evolving the prototype is a lot of rework.
Customers may mistakenly believe that the real system is done.
Doesn't specifically help shorten the time-to-market of the actual
- Iteratively specify and develop the system, but on each
iteration: identify the biggest risks and use small prototypes to
address those risks specifically.
- PROs: Should work pretty well. Risk-driven approach helps
prevent project failure when requirements are fixed, although it
does not do much to optimize productivity.
- CONs: Does not say how to assess or weigh risks against
each other or against limited resources. Does not really take into
account multiple departments working in parallel.
- Like spiral, but start with an assumption of fixed time and
resources for each iteration. Also, have different departments
working in parallel, even if they are an iteration ahead of others.
And, plan buffer time time to deal with unforeseen problems. See Microsoft
- PROs: Manages cost and risk better than spiral when
requirements for each release are negotiable. Always have an
opportunity to adjust release schedule to compete with other
- CONs: Not better than spiral for mission-critical
systems with fixed requirements. Parallel use of employees within a
company, and helps react to competition, but does not address
how to work with partner companies.
- Collaborative development / Global software development
- Use any iterative-type of process model, but involve vendors,
partners, contractors/outsourcers, integrators, and key customers
more directly in the development process.
- PROs: Further shortens time-to-market by parallelizing
activity across organizational boundaries. Allows more freedom in
resource choice. Allows more rapid staffing changes. Can allow
work-at-home and other life-style improvements.
- CONs: Even more communications challenges. Security
challenges. Requires effective collaboration and management without
How to Evaluate Processes
- Evaluate them by the internal qualities that they affect.
- Does the process include key practices that affect those
- The CMM (Capability Maturity Model) defines 5 levels of
process maturity where each level adds new key practices.
- Which qualities are most important/appropriate for your project?
- E.g., safety-critical systems require very rigorous processes to
fully address all safety risks.
- E.g., consumer products tend to be driven by time-to-market
- Larger teams need more insurance against breakdowns, whereas
smaller teams can often be less formal.
- Co-located teams working over short periods of time can rely on
both oral and written communications, whereas distributed teams or
long projects must put everything in writing.
- In contract, government, or regulated markets the customer may
impose process constraints. E.g., FDA approval.
What Processes do People Really Use?
- It varies greatly.
- There are many companies that really have no idea what they
are doing and use very poor processes that they make up
themselves or don't even try.
- There are companies that do try, and still have different
opinions and interpretations of the good processes.
- Often companies would like to use a process that is published in
a book, but they feel stuck dealing with daily problems in their
current process and never have time for SPI.
- Remember that these are just models. They are broad
generalizations of actual processes.
- Contractors and consultant firms tend more toward the
waterfall models or an iterative model with a few iterations for
projects that are safely within their area of expertise and
- Product development tends more toward rapid prototyping and
- Larger software and systems companies also use iterative
processes, and are gradually addressing more of the concerns of
the synch-and-stabilize and collaborative models. The also plan
whole product families.
- Like the synch-and-stabilize model: iterative and parallel.
- RUP is an actual process, not just a process model
- It contains specific advice on specific activities
- When to do each activity and how much.
- Integrated tool support for using this process
- Document templates for less formal artifacts
- A unique feature of RUP is that it can be purchased: books,
tools, training, templates, project websites, etc.
XP and Agile methods
- Close to the iterative models, but without as much up-front
planning. If things go badly, could seem like build-and-fix.
- Embrace change: rather than avoid change, try new activities
(like refactoring) that reduce the cost of changes.
- Test-first guideline replaces much of requirements specification
with executable unit tests.
- Open source itself is not a process. It just means that you can
see the source code.
- Anyone can do anything and call it open source. Most small OS
projects are complete failures, but not very costly ones. Some
large OS projects are mainly corporate developers following one of
the other processes and releasing the source code of the
- The successful open source projects with many diverse
contributors tend to be closer to the collaborative model. However,
they do not manage their resources at all closely.
- Requirements prioritization and validation in open source
depends on an overlap between the developers and user groups.
- Product families or product lines are multiple products that
share common core assets.
- The different products address different market segments or
product generations. Each segment or generation adds revenue
without increasing cost much.
- Much of the success of product families depends on designs that
increase reuse, but processes also matter.
- Developing product families makes schedules and priorities
even more complex.
- Covering multiple market segments means working with more
partners that specialize in those segments.
- Planning multiple product generations means managing more
branches of development.
- This is one practice that is prominent in many processes
currently used in industry.
- Work on multiple branches of development at the same time.
- Schedule changes in branches of development, and then schedule
merges of those branches to integrate changes.
- Manage risk of changes very closely on release branches while
allowing larger changes to be made on experimental/non-release