Rational Unified Process (RUP)
Line 93: | Line 93: | ||
* Training of end users and maintainers. | * Training of end users and maintainers. | ||
* Marketing and distribution of the product. | * Marketing and distribution of the product. | ||
+ | |||
+ | At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''. | ||
+ | The transition phase has two evaluation criteria: | ||
+ | |||
+ | * Are the end - users satisfied with the product? | ||
+ | * Is the actual vs planned resource expenditure in acceptable levels? | ||
+ | |||
+ | |||
== Workflow == | == Workflow == |
Revision as of 20:00, 20 September 2015
The Rational Unified Process (RUP) is an iterative, software development methodology, firstly introduced by the Rational Software Corporation which was acquired by IBM in 2003. RUP is a disciplined approach to assign tasks within a development organization and software project teams. It was developed to ensure the production of high quality software by providing the development team with a set of guidelines, templates and tool mentors, for all the critical life-cycle activities within a project. This cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule. RUP is the most popular and extensively documented refinement of the Unified Process, an iterative and incremental software development process framework. Other worth mentioning forms are the OpenUP and Agile Unified Process.
Maybe Mention UML !!!
Contents |
Process Overview
The best possible way to describe this rather complex methodology is through a 2 - dimensional graph.
- The first dimension (horizontal axis) represents the dynamic aspect of the process. It expresses time in terms of cycles, phases, iterations and finally milestones.
- The second dimension (vertical axis) represents the static aspect of the process. It expresses workflows in terms of 6 core and 3 supporting disciplines (more on that on "Disciplines" section).
The Phases
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.
- Inception phase
- Elaboration phase
- Construction phase
- Transition phase
Depending on the project, each of these phases can consist of one to a number of iterations. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.
Inception Phase
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects. The expected outcome of the inception phase includes :
- A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
- An initial use-case model (10%-20% complete)
- An initial project glossary
- An initial business case, including the business context, success criteria and a financial forecast.
- An initial risk assessment
- A project plan (phases and iterations)
- A business model (if necessary)
- Prototypes
At the end of the inception phase lies the first major project milestone; the Lifecycle Objective Milestone. The inception phase has five evaluation criteria:
- Stakeholder concurrence on scope definition and cost/schedule estimates.
- Depth and breadth of any prototype that was developed.
- Actual expenditures versus planned ones.
- Requirements understanding.
- Credibility of the cost/schedule estimates, risks and priorities.
If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.
Elaboration Phase
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:
- A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
- Supplementary requirements (if any).
- A clear description of the software architecture.
- An architectural prototype.
- A more detailed risk assessment and business case.
- A development plan for the overall project.
- A preliminary user manual (optional).
At the end of the elaboration phase lies the second major project milestone; the Lifecycle Architecture Milestone. The elaboration phase has six evaluation criteria:
- Is the vision stable enough?
- Is the system architecture stable enough?
- Have all the major risks been successfully identified and resolved?
- Is the plan for the construction phase accurate enough?
- Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
- Is the actual vs planned resource expenditure in acceptable levels?
If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.
Construction Phase
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:
- First external release of the software.
- User manuals.
- A detailed description of the current release.
At the end of the construction phase lies the third major project milestone; the Initial Operation Capability Milestone. The construction phase has three evaluation criteria:
- Is the software release stable enough to be given to the user community?
- Are all the stakeholders ready for the transition to the user community?
- Is the actual vs planned resource expenditure in acceptable levels?
If the project fails to pass this milestone, transition may have to be postponed by one release.
Transition Phase
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:
- Beta-testing to fix any major software bugs and add any missing features.
- Conversion of operational databases
- Training of end users and maintainers.
- Marketing and distribution of the product.
At the end of the transition phase lies the fourth and final major project milestone; the Product Release. The transition phase has two evaluation criteria:
- Are the end - users satisfied with the product?
- Is the actual vs planned resource expenditure in acceptable levels?