ICS 121: Process Models

Overview

Why review process models?
Some standard standard models
How to evaluate processes
What processes do people really use?
- RUP
- XP/Agile
- Open source
- Product families
- Concurrent releases

Why review process models?

Process models help us define the volcabulary that we need to understand and evaluate particular software development methods.
We will start with simple, theoretical models of software development.
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

Build-and-fix: 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 managed.
Waterfall: 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./dd>
Iterative: 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 requirements.
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 operational system.; 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 product.
Spiral: 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.
Synch-and-Stablize: 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 Secrets.; 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 vendors.; CONs: Not better than sprial 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 boundries. 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 wihtout face-to-face meetings.

How to Evaluate Processes

Evaluate them by the internal qualities that they affect.
- Does the process include key practices that affect those qualities?
- The CMM (Capability Maturity Model) defines 5 levels of process maturity where each level adds new key practices.
Which qualities are most important/apprpriate for your project?
- E.g., safety-critical systems requre 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 distibuted teams or long projects must put everything in writing.
- In contract, government, or regulated markets the customer may impose process contraints. 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 interpertations 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 itereratons for projects that are safely within their area of expertise and abilities.
- Product development tends more toward rapid prototyping and iterative development.
- Larger software and systems companies also use iterative processes, and are gradually addressing more of the concerns of the synch-and-stablize and collaborative models. The also plan whole product families.

RUP

Like the synch-and-stablize 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

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

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.

Concurrent releases

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