ICS 121: The Unified Process

It is a comprehensive, practical software process defined and promoted by Rational Software Corporation (now part of IBM).
Based on traditional software engineering methods. Based on experience with large software projects, but made simpler and more broadly applicable.
Emphasis is on UML and design

Develop software iteratively
- The team is forced to work through many types of problems early
- User feedback on early releases can inform later work
- Releases provide fairly trustworthy measures of progress
Mangage requirements
- Other decisions are traceable back to specific requirements
- Individual requirements can be prioritized for each release
Use component-based architectures
- Thinking in terms of components facilitates reuse and separation of concerns
- Emphasize architectural decisions because they affect how well the system can satisfy its requirements
Visually model software
- UML makes design decisions clear and exposes design problems
- Design quality strongly product quality
Continuously verify software quality
- Allows QA team to work all the time, not just a rush at the end
- Test results are objective measures of progress
- It is cheaper to fix problems sooner
Control changes to software
- Written change requests facilitate clear communications
- Developers can safely work in parallel in their own working copy
- Change control board (CCB) can manage the risk of changes made in given release
- Metrics on changes indicate progress, effort, and certain risks

Worker: A role that a person plays. E.g., designer, programmer, tester.
Activity: A unit of work that a worker does. An activity usually takes hours or days of effort. E.g., writing a use case, coding a function, reviewing a design, or testing a component. Each activity is done at some cost to the organization.
Artifact: A document, source file, or other piece of information that is produced or used by a worker during an activity. Each artifact is an asset to the organization.
Workflow: a sequence/flowchart of activities that result in the production of desired artifacts. E.g., requirements, design, implementation, testing.
Iteration: All the work that goes into producing an internal release. This includes all the workflows needed to produce that release. Each iteration emphasizes a subset of workflows based on the phase.
Phase: A set of one or more iterations that together, at least, satisfy a milestone criteria. Phases are analogous to waterfall phases, except that all activities are done to different degrees in each phase.
Development cycle: All the effort that goes into producing one release of a product to the market. This is the largest unit of scheduling.

Each phase is disctinct in it's goal. Different workers can work on any workflow in any iteration, e.g., your programmer can implement a prototype in the inception phase, but it is not itself the goal for that phase.
Inception
- What does the customer really want?
- What is our plan for this entire release? Is it feasible?
- How long will it take? how much will it cost?
- E.g., 6 weeks for v1.0.0, and 2 weeks for minor versions
Elaboration
- More formal requirements
- Design how the system will work
- Prove to ourselves that the design is good enough. E.g., by building initial prototypes.
- E.g., 10 weeks for v1.0.0, and 2 weeks for minor versions
Constrution
- Build and test the system.
- Fix problems as they are found.
- Create all documentation, data, etc.
- E.g., 20 weeks for v1.0.0, and 9 weeks for minor versions
Transition
- Finish up the system and package it.
- Prepare the customer accept it, and our company's departments to support it. E.g., training, prepare tech support engineers.
- Actually ship it (or install it on ASP servers) and support it.
- E.g., 5 weeks for v1.0.0, and 1 week for minor versions

RUP has good old-fashioned software engineering principles. Managers like RUP.
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 the more formal artifacts (e.g., Rational Rose for UML)
- Document templates for less formal artifacts
Adoption:
- In any process, one big challenge is getting everyone to have the same understanding of the process.
- In any process, another big challenge is having too many people trying to define, refine, or change the process. Process definition is often tied into office politics. More vocal or eloquent people can have undue influence.
- A unique feature of RUP is that it can be purchased: books, tools, training, templates, project websites, etc.
- As a result, adopting RUP can deflate some arguments over process and make the whole team focus on actually carrying out the process.
RUP has enough adoption to make it a marketable job skill.

Similar to the synch-and-stablize model:
- iterative development
- parallel work by different workers with different skills
- process guidance emphasizes both risk management and time-to-market
Details of the process are built into the tools and document templates.
There is no maintenance phase. Further changes are always made as part of a new development cycle.