The Unified Process, also known as the Rational Unified Process (RUP), was developed with the assistance of the Rational Corporation, which also created CASE tools to support the model's implementation.
It serves as a unification of early object-oriented analysis and design models from the 80s and 90s, aiming to combine their best features, resulting in the creation of the Unified Modeling Language (UML). UML has since become the standard diagrammatic language for modelling object-oriented software.
While UML provides a modelling framework, it lacks a process model. Consequently, the Unified Process was introduced as a process model for developing object-oriented software, utilizing UML as its modelling language.
It's a hybrid model, providing a dynamic, static, and practice perspective.
Key Characteristics of the Unified Process
Incremental and Architecture-Driven: The Unified Process is an incremental software process with a focus on architecture. Early iterations concentrate on defining the overall software architecture.
Risk-Focused: The process places a strong emphasis on mitigating risk. Early iterations specifically address the high-risk portions of the software, ensuring a proactive risk management approach.
Use Case Driven: The development process is driven by the use cases, with a focus on capturing requirements and driving development through iterative use case elaboration.
Phases of the Unified Process
1. Inception Phase:
Focuses on project feasibility and high-risk areas.
Uses use cases for communication to discover broad software requirements.
Typically short, often with only one iteration.
Establishes a business case for the system.
Identifies external entities and assesses system contribution to the business.
2. Elaboration Phase:
Programming begins with iterations developing requirements from the inception phase.
Requirements are fleshed out, and new ones are selected for development in subsequent iterations.
Phase completes when all requirements are elaborated.
Develops understanding of the problem domain.
Establishes an architectural framework, and project plan, and identifies key risks.
Results in a requirements model, architectural description, and development plan.
3. Construction Phase:
Main construction activity occurs in this phase.
All use cases have been fleshed out in previous phases, allowing focused development.
Involves system design, programming, and testing.
Parts of the system are developed in parallel and integrated.
Results in a working software system ready for delivery.
4. Transition Phase:
Initiates deployment activities, including beta testing.
Software is given to customers for evaluation, and their feedback leads to modifications.
Includes communication and construction activities.
Concerned with moving the system to the user community and making it operational.
Often overlooked in other models.
Results in a documented software system working correctly in its environment.
Three Perspectives:
1. Dynamic Perspective:
Shows phases over time.
Recognizes the evolving nature of the development process.
2. Static Perspective:
Illustrates process activities enacted.
Described through workflows, which are activities during the development process.
3. Practice Perspective:
Suggests best practices for system development.
Provides guidance for effective software engineering.
The advantage in presenting dynamic and static views is that phases of the development process are not associated with specific workflows. In principle at least, all of the RUP workflows may be active at all stages of the process.
In the early phases of the process, most effort will probably be spent on workflows such as business modelling and requirements and, in the later phases, in testing and deployment.
The practice perspective on the RUP describes good software engineering practices that are recommended for use in systems development.
Six fundamental best practices are recommended:-
Develop software iteratively:- Plan increments of the system based on customer priorities and develop the highest-priority system features early in the development process.
Manage requirements:- Explicitly document the customer’s requirements and keep track of changes to these requirements. Analyze the impact of changes on the system before accepting them.
Use component-based architectures:- Structure the system architecture into components, as discussed earlier in this chapter.
Visually model software:- Use graphical UML models to present static and dynamic views of the software.
Verify software quality:- Ensure that the software meets the organizational quality standards.
Control changes to software:- Manage changes to the software using a change management system and configuration management procedures and tools.
This is all about the rational unified process.