The Rational Unified Process (RUP) draws on many generations of software processes especially Barry Boehm's Spiral Model.
The Rational Unified Process
Here's my list of the top salient points of RUP. You should buy the above book to get a detailed description.
- Software Best Practices
- Develop iteratively
- Manage requirements closely
- Use component-based architectures
- Model your code visually
- Verify software quality
- Control changes to software
- RUP has four primary modeling elements
- Workers - some examples:
- System Analyst - gets requirements, defines Use Cases and sets the boundaries of the system.
- Architect - defines the high level view of the system
- Designer - defines the interactions of classes
- Implementer - writes the code and associated tests
- Test Designer - defines the test environment
- Toolsmith - creates utility tools for the project
- Activities - things done by Workers, like code review, or designing
- Artifacts - these are any created object like test plans or code
- Workflows - sequences of activities performed by various
workers which produce meaningful output RUP has 6 engineering
- Business modeling
- Analysis and design
and 3 supporting workflows:
- Project management
- Configuration and change management
In addition four other process elements are helpful: Guidelines, Templates, Tool mentors and concepts
- Workers - some examples:
- Four phases of a software project
- - write the business case and define scope. This phase concludes with the Life-Cycle Objective (LCO) milestone.
- - plan the activities, detail the features and design architecture. This phase concludes with the Life-Cycle Architecture (LCA) milestone.
- - implements the code and meets the Initial Operational Capability (IOC) milestone.
- - releases the code to the users. This phase concludes with the product release milestone.
- RUP is Architecture Centric
An architecture is a set of multidimensional views of the high level elements in a system. The RUP defines 4+1 Views of an architecture:
- the functionality as seen by the end user
- the system as seen by the programmers
- view seen by system integrators
- view seen by system engineering to be used for installation and delivery
- the high level use-cases that drive the architecture
- Requirements are typically divided into functional and non-functional. The functional requirements detail what the system should do. The non-functional requirements specify attributes like usability, reliability, performance, and supportability.
- Analysis and Design
Analysis is a pure theoretical structure to solve the problem. The design adds more mundane factors like supportability and performance.