Rational Unified Process (UP)
The Rational Unified Process (RUP) is an adaptable methodology for software development. RUP advocates an iterative, use-case led approach to software development which ensures quality and customer satisfaction. Alderstone uses the RUP framework to provide a common structure and control to software development projects. RUP is an industry-standard development methodology which Alderstone Consulting advocates for the following key benefits;
- Effective and easy to understand
- Flexible to the needs of the customer and the project
- Iterative approach ensures, high quality and customer satisfaction
- Costs and schedule are controlled
- Results in successful development projects – it really works
What is RUP used For?
Alderstone use RUP for the following types of projects;
- Software development projects
- Implementation projects
- Integration projects
RUP Phases
The following phases define an RUP project;
- Inception – understand what to build
- Elaboration – understand how to build it
- Construction – build the product
- Transition – validate solution
There may be multiple iterations of each phase. For example, there are typically several iterations of a construction phase to allow the customer’s stakeholders opportunities to review the work in progress and provide feedback.
At the end of each phase an iteration review is performed to ensure that the objectives of that iteration are met and to allow for any necessary replanning.
Please find below an example illustration of the effort in each of the RUP Disciples which is typically invested during each phase. For example the effort expended on Requirements is very high during the Inception Phase but some level of activity takes place throughout the project as Requirements are analysed and reviewed.

Inception
The objectives of the Inception Phase are;
- Knowing What to Build
- Identify key functionality
- Determine at least one possible solution
- Understand Cost, Schedules and Risks
- Decide Project Processes and Tools
Inception Deliverables
- Vision Document
- Benefits
- High Level Functionality
- Identify Users
- Identify essential Non Functional Requirements
- High Level Use Cases
- Business Case
- Exploratory & Behavioural Prototype
- For requirements elicitation and technology selection
- ‘Throw away’
- Iteration Plan
- Software Development Plan
- QA Plan, Resource Plan, Product Acceptance, Risk Management Plan
- Test Strategy
- Domain Model
Inception Milestones
Agreement on the following key items;
- Requirements
- High Level Solution
- Costs
- Risks & Mediation
- Processes for Project
Elaboration Phase
Objectives;
- Get a more detailed understanding of the requirements
- Design, Implement and Validate Baseline Architecture
- Mitigate Essential Risks and produce accurate schedule
- Refine the Development Case
Elaboration Deliverables
- Evolutionary Prototypes
- 20% working functionality
- Key architecturally significant use cases
- Key business use cases
- Software Architecture Document
- Design for key components
- Automated build and test processes
- Updated Risks and Plan
- Construction Plan
- Enhanced Domain model
Elaboration Milestones
- Are the Requirements and Vision stable?
- Is the Architecture stable?
- Are the Major Risks addressed?
- Is the plan for Construction suitably detailed?
Construction
- Objective 1 – Minimise Development Costs
- Build around Architecture
- SCM
- Set clear goals
- Continuous integration
- Demonstrate and test often
- Objective 2 – Iteratively develop a complete product
- Describe remaining use cases
- Fill in design gaps
- Early deployment ad feedback
- Prepare for deployment
Construction Deliverables
- Working Software ( The system )
- Remaining 80% of use cases
- Test results
- Updated design documents for remaining components
- Install package and instructions
- Support Material
- Deployment Plan
Initial Operational Capability Milestone
- Is the Product Mature and Stable?
- Are the Stakeholders ready to receive?
- Are Resources to complete still acceptable?
Transition Phase
- Objective 1 – Beta Test/UAT
- Defect Trending
- Acceptance criteria
- Objective 2 – Make users/support staff self sufficient
- Training
- Handover
- Objective 3 – Improve Future Performance
- Project Reviews
- Lessons Learned
Transition Deliverables
- The Product
- Support Material
- Project Review Template
Product Release Milestone
- Are Users satisfied?
- Evaluate Resource Usage Planned against Actual
