Rational Unified Process. Part 1. Characteristics, components, structure, workflows

Today, we will devote our attention to the methodology of the Rational Unified Process, considering its characteristics, components, structure and workflows.
Rational Unified Process (RUP) is one of the spiral software development methodologies. The methodology is supported by Rational Software company, the product is updated about twice a year. The language of modeling in the common knowledge base is the Unified Modeling Language (UML).
Iterative software development in RUP involves dividing the project into several small projects that are executed sequentially, and each iteration of development is clearly defined by a set of goals that must be achieved at the end of the iteration. The final iteration assumes that the set of iteration objectives must exactly match the set of goals specified by the customer of the product, that is, all requirements must be met.
RUP is well formalized, and the most attention is paid to the initial stages of project development – analysis and modeling. Thus, this methodology is aimed at reducing risk mitigating by detecting errors in the early stages of development. Technical risks (assesses) are evaluated and “allocated” according to priorities in the early stages of the development cycle, and then revised over time and with the development of the project during subsequent iterations. New goals appear depending on the priorities of these risks. Release versions are distributed in such a way that the most priority risks are eliminated first.
The process involves the evolution of models; iteration of the development cycle uniquely corresponds to a certain version of the software model. Each of the iterations (workflow) contains the elements of software life cycle management: analysis and design (modeling), implementation, integration, testing, implementation. In this sense, RUP is an implementation of the spiral model, although it is often depicted as a graph-table. Below we give the main components of the process.
For a successful development process, three components are needed: a process, a notation, and a set of utilities. The process describes what we do, in what order and how; notation is a means of communication; a set of utilities helps automate the process and manage it.
RUP Components
All three components are represented in RUP. First, let’s look at the notation functions that do the following:
- “glues” the process together into a single whole;
- is a language decision-making tool that is not obvious from the source code;
- provides semantics for displaying important strategic and tactical solutions;
- offers a form that is sufficient to reflect, and then make decisions and means of automating the process in order to manipulate formalized data.
In fact, notation covers the development of software, from analysis to implementation of the product. Notation in the case of RUP-UML is a formal language means of describing the process. Next, consider the structure of the process, and also give a set of utilities used in the process of managing the development of the project according to RUP.
Structure of RUP
RUP provides a structured approach to iterative software development, dividing the process into four milestones: Inception, Elaboration, Construction, and Transition. In the above figure, a widespread image of the RUP phases is represented. The objectives of each of these phases are:
- Inception – understanding what we create. The phase of gathering information and analyzing requirements, determining the image of the project as a whole;
- Elaboration – understanding how we create it. The phase of requirements analysis and system design, planning of necessary actions and resources, specification of functions and design features;
- Construction – creating a beta version of the product. The main phase of development and coding, building a product as an ascending sequence of iterations (code versions);
- Transition – create the final version of the product. The phase of the introduction of the product, the delivery of the product to a specific user.
These are the phases of managing the evolution of a product – the iterations of the life cycle. RUP assumes an approach to the final goal, but, unlike the classic ISO standard (the waterfall methodology), where transition is the final phase, each phase can be repeated several times, reflecting the changing requirements of the customer’s product.
Workflows of RUP
The methodology of RUP is based on nine main threads (workflow), which are elements of the iteration of the software life cycle:
- Business modeling – involves the analysis of requirements at this iteration of the life cycle, determining the desired system parameters and user needs;
- Requirements – formalizing the image of the system. Assumes collection of requirements and requirements management, translation of requirements into functional specifications. Here begins the analysis of use cases and the construction of use cases (user stories) – a formal mapping of user requirements in UML. The result is management-level documents;
- Analysis and design – involves the translation of collected requirements into a formalized software model. The result is a description of the system in the implementation phase (technical design) – these are the documents of the system developers level. The language of formalization is Unified Modeling Language (UML), which will be discussed below. In the process of iterative development, the product of this flow, the project model, will evolve. All changes are attached to the RUP directly to the models, and automation tools and a fairly flexible modeling language allow you to manage this process more or less painless in terms of time and resources. Here we mean the fact that the result of the development is not the model, but the executable code, so the customer usually does not like to pay for modeling, because the models are not the product that he needs);
- Implementation (implementation, coding) – involves actually writing the code. The code elements in RUP are already created in the analysis and design phase, since the UML implementation tool – Rational Rose – allows you to create code elements in several programming languages. Methodology – object-oriented programming;
- Test – involves testing the product at a given iteration. It should be specially noted that regression testing (return testing, testing “non-deterioration” of the product) in this case should contain all current tests from the previous iteration and acceptance tests from the previous transition phase;
- Deployment – involves the installation of the product at the customer’s site, training of personnel, the launch of the system plus acceptance testing, the preparation of standards for packaging and distribution of the product, the transfer of materials to the sales department (the actions are optional depending on the specifics of the product).
The above elements are not new in terms of the software development life cycle, as they occur in almost any methodology – perhaps with the exception of XP (where they are nevertheless presented in a very original form). The peculiarity of the implementation of RUP are temporary accents, namely – which iterations will be dominated by those or other flows, as well as the availability of a universal language and a set of utilities that allows you to describe the development process. As we can see in the initial stages of product evolution, the focus is on project formalization (analysis, modeling), which is aimed at reducing commercial risks and reducing the cost of design errors. When the picture is more or less clear, the actual development, testing and, finally, the introduction of the product begin.
Preliminary interna are actually documents issued by a technical council for managers of an enterprise. The main goal of the initial stages is the conclusion of a contract or an agreement of intent. Further iterations are actually the beginning of the work of a team of developers who have the time and resources to build formal models. UML in this case has tools that allow the model to be mapped to code elements. For example, the tree of objects is displayed directly, the variations depend on the implementation capacity of the programming language chosen by the developers, as well as on the coincidence of the views of G.Buch and the developers of this language on the object model. The same applies to methods.
In the next part of the article, we will continue to study the RUP methodology. Stay with us!