RUP (Rational Unified Process, unified software development process)

Rational Unified Process (RUP) is an object-oriented and network-based Program Development methodology. According to Rational Rose and the developer of the unified modeling language, it seems like an online mentor who can provide guidelines, templates, and Case Support for all aspects and layers of program development. RUP and similar products-such as object-oriented software processes (oosp), and open processes are understandable software engineering tools-process-oriented aspects of development (such as the defined stage, technologies and practices) and other developed components (such as documents, models, manuals and Code And so on.

I. Six major experiences

1. iterative development. In the early stages of software development, it is almost impossible to fully and accurately capture users' needs. In fact, the problem we often encounter is that the demand often changes throughout the software development project. Iterative development allows the demand to change during each iteration, and the problem can be further understood through continuous refinement. Iterative development not only reduces the risk of the project, but also ends the version execution in each iteration process, encouraging developers.

2. management requirements. Determining system requirements is a continuous process. Before developing a system, developers cannot fully describe the real needs of a system. RUP describes how to extract, organize, and document the functions and constraints of the system. The use of Use Cases and scripts proves to be an effective way to capture functional requirements.

3. Component-based architecture. Components make reuse possible. The system can be composed of components. The architecture based on independent, replaceable, and modular components helps to manage complexity and improve reuse rate. RUP describes how to design an elastic, responsive, easy-to-understand, reusable software architecture.

4. Visual modeling. Generally, RUP is associated with UML to build visual models for software systems to help people manage software complexity. RUP tells us how to visually model the software system and obtain the structure and behavior information about the architecture and components.

5. Verify the software quality. In RUP, software quality assessment is no longer a separation activity conducted after the event or by a separate group, but all activities built in the process, so that defects in the software can be discovered as early as possible.

6. control software changes. Without strict control and coordination in iterative development, the entire software development process will soon be in chaos. RUP describes how to control, track, monitor, and modify to ensure successful iterative development. Through the products in the software development process, RUP isolates changes from other workspaces to create a secure workspace for each developer.

Ii. Two-dimensional development model of the unified software development process

The life cycle of software development is a two-dimensional software development model. The horizontal axis is organized by time. It is the life cycle feature of process expansion and reflects the dynamic structure of the development process. Its terms mainly include cycle and phase) iteration and milestone (milestone); the vertical axis organizes content as a natural logical activity, reflecting the static structure of the development process. It is used to describe its term mainly including activity) artifact, worker, and workflow ). 1:

Iii. Unified Software Development Process core concept of RUP

Some core concepts, such:

Role: describes the behaviors and responsibilities of an individual or a group. Many roles are pre-defined in RUP.
Activity: it is an independent unit of work with a clear purpose.
Workpiece: A piece of information generated, created, or modified by an activity.

Iv. Unified Software Development Process

RUP is a general process template that contains many development guides, products, and roles involved in the development process. Because it is very large, it is very large for specific development institutions and projects, we also need to make la s when using RUP, that is, we need to configure it. A process is like a metaprocess. Many different development processes can be obtained by tailoring the process to the process. These software development processes can be seen as specific instances of the process. The following steps can be taken to set up the RUP:

1) determine the workflows required for this project. The nine core workflows of RUP are not always needed. You can choose between them.

2) determine the products required by each workflow.

3) Determine how the four phases evolve. To determine the evolution between stages, the risk control should be taken as the principle to determine the workflows required for each stage, the extent to which each workflow is executed, the products available, and the extent to which each product is completed.

4) determine the iteration plan for each stage. Plan the content of each iterative development in four phases of the RUP.

5) Plan the internal structure of the workflow. A workflow involves roles, activities, and products. The complexity of a workflow depends on the project size, that is, the number of roles. Finally, we plan the internal structure of the workflow, which is usually presented in the form of an activity diagram.

5. Various Stages and milestones in the development process

The software lifecycle in RUP is divided into four sequential stages in time: Inception, elaboration, and construction) and the delivery phase (Transition ). Each stage ends with a major milestone (major milestones); each stage is essentially a time span between two milestones. An evaluation is executed at the end of each stage to determine whether the objectives of this stage have been met. If the evaluation results are satisfactory, you can allow the project to enter the next stage.

1. Initial Stage

In the initial stage, the goal is to establish business cases for the system and determine the project boundaries. To achieve this goal, all external entities that interact with the system must be identified and the Interaction Features must be defined at a higher level. This phase is of great significance. In this phase, we focus on the main risks of business and demand in the project. For development projects built on the original system, the initial stage may be very short. The end of the initial phase is the first important milestone: the lifecycle objective milestone. The life cycle goal milestone evaluates the basic viability of the project.

2. refinement stage

The goal of the refinement stage is to analyze the problem field, establish a sound architecture Foundation, prepare a project plan, and eliminate the highest risk elements in the project. To achieve this goal, you must make decisions on the architecture based on understanding the entire system, including its scope, main functions, and non-functional requirements such as performance. Create a support environment for the project, including creating development cases, creating templates, rules, and preparing tools. The second important milestone at the end of the Refinement phase: the lifecycle architecture milestone. The lifecycle structure milestone establishes a management benchmark for the system structure and enables the project team to measure during the build phase. At this moment, we will examine the detailed system objectives and scopes, the selection of structures, and solutions to major risks.

3. Construction phase

During the build phase, all remaining components and application functions are developed and integrated into products, and all functions are tested in detail. In a sense, the construction phase is a manufacturing process, which focuses on resource management and operation control to optimize costs, progress, and quality. The end of the build phase is the third important milestone: the initial operational milestone. The initial function milestone determines whether the product can be deployed in the test environment. At this moment, determine whether the software, environment, and users can start the system operation. The product version is also called "Beta.

4. delivery phase

The focus of the delivery phase is to ensure that the software is available to end users. The delivery phase can span several iterations, including product testing for release and a small amount of adjustments based on user feedback. In terms of the lifecycle, user feedback should focus on product adjustment, setup, installation, and availability issues, all major structural problems should have been solved in the early stages of the project lifecycle. The end of the delivery phase is the fourth milestone: the product release milestone. In this case, determine whether the target is implemented and whether another development cycle should be started. In some cases, this milestone may overlap with the end of the initial phase of the next cycle.

6. Unified core workflows)

There are nine core workflows in RUP, which are divided into six core process workflows and three core support workflows (core supporting workflows ). Although the six core process workflows may remind people of several stages in the traditional waterfall model, it should be noted that the stages in the iteration process are completely different, these workflows are accessed again and again throughout the lifecycle. Nine core workflows are used in turn in the project, and repeated with different emphasis and intensity in each iteration.

1. Business Modeling)

Business modeling workflows describe how to develop an idea for a new target organization, and define the process, roles, and responsibilities of the Organization in the business case model and Business Object Model Based on this idea.

2. Requirements)

The goal of a requirement workflow is to describe what the system should do and reach a consensus between developers and users on this description. To achieve this goal, extract, organize, and document the required functions and constraints. The most important thing is to understand the definition and scope of the problems solved by the system.

3. Analysis & Design)

Analysis and Design workflows transform requirements into future system designs, develop a robust structure for the system, adjust the design so that it matches with the implementation environment, and optimize its performance. The analysis design result is a design model and an optional analysis model. The design model isSource codeIs composed of a design class and some descriptions. The design class is organized into a package with good interfaces and a subsystem. The description shows how the class objects work together to implement the use case function. The design activity is centered on the architecture design. The architecture is expressed by several structural views, which are the abstraction and simplification of the entire design. Some details are omitted in this view, make important features clearer. The architecture is not only a medium for good model design, but also improves the quality of the created model during system development.

4. Implementation)

The purpose of implementing a workflow is to define the code organization structure in the form of a hierarchical subsystem; To implement classes and objects in the form of components (source files, binary files, and executable files; testing the developed components as units and integrating the results produced by a single developer (or group) into an executable system.

5. Test)

The test workflow should verify the interaction between objects, verify the correct integration of all components in the software, and verify that all requirements have been correctly implemented, identify and identify defects that are proposed and handled prior to software deployment. The iterative approach proposed by RUP means testing throughout the project, so as to discover defects as early as possible, fundamentally reducing the cost of modifying defects. The test is similar to a three-dimensional model, which can be carried out from the reliability, functionality, and system.

6. Deployment)

The purpose of deploying a workflow is to successfully generate a version and distribute the software to the end user. The deployment workflow describes activities related to ensuring that software products are available to end users, including software packaging, generating products other than the software itself, installing software, and helping users. In some cases, it may also include planning and beta testing, porting existing software and data, and formal acceptance.

7. Configuration and change management)

The configuration and change management workflow depicts how to control a large number of products in a project composed of multiple members. The configuration and change management workflow provides guidelines for managing multiple variants in an evolutionary system and tracking versions during Software creation. A workflow describes how to manage parallel development, distributed development, and automate Project Creation. At the same time, it also describes the reasons for product modification, the time, and personnel maintenance audit records.

8. Project Management)

Software project management balances various conflicting goals, manages risks, overcomes various constraints, and successfully delivers products that satisfy users. Its goals include: to provide a framework for project management, practical guidelines for planning, staffing, implementation and monitoring of projects, and to provide a framework for management risks.

9. Environment (Environment)

The purpose of an environment workflow is to provide the software development environment, including processes and tools, to the software development organization. Environment workflows focus on the activities required during project configuration. They also support development project standard activities, provide a step-by-step instruction manual, and introduce how to implement the process in an organization.

VII. iterative development mode of RUP

Each stage in the RUP can be further divided into iterations. An iteration is a complete development cycle that generates an executable product version and is a subset of the final product. It develops incrementally, from one iteration process to another iteration process to the final system. Traditionally, projects are organized sequentially through each workflow. Each workflow is only once, that is, the waterfall lifecycle we are familiar with (see figure 2 ). The result of this operation is that at the end of the product implementation stage, the product is complete and the test is started. There will be a large number of hidden problems in the analysis, design, and implementation stages, the project may have to be stopped and start a long period of error correction.

A more flexible and less risky method is to use different development workflows multiple times to better understand the requirements and build a robust architecture, and finally deliver a series of gradually completed versions. This is called an iteration lifecycle. The passing of each order in a workflow is called an iteration. The software life cycle is continuous iteration. Through it, the software is incremental development. An Iteration includes a development activity that generates an executable version and other auxiliary components necessary to use this version, such as version description and user documentation. Therefore, a development iteration is a complete process in all workflows. These workflows include at least requirement workflows, analysis and design workflows, implementation workflows, and test workflows. It is like a small waterfall project (see figure 3 ).

Figure 3 iterative model of RUP

Compared with the traditional waterfall model, the iterative process has the following advantages:

Reduces the risk of spending on an increment. If developers repeat an iteration, the loss is only the cost of an incorrect iteration.

This reduces the risk that products cannot enter the market according to the established schedule. By identifying risks in the early stages of development, we can solve them as early as possible rather than rush in the later stages of development.

This accelerates the entire development process. Because developers are clear about the focus of the problem, their work will be more efficient.

Since user requirements cannot be fully defined at the beginning, they are usually refined in subsequent stages. Therefore, the pattern of iteration process makes it easier to adapt to changes in requirements.

VIII. Top 10 elements of the unified software development process

1. Development Prospects
2. Make a plan
3. Identify and reduce risks
4. Assign and track tasks ..
5. Check business reasons
6. Design component architecture
7. build and test products incrementally
8. verification and evaluation results
9. manage and control changes
10. provide user support

Let's examine these elements one by one to see where they are suitable for RUP and find out why they can become the top ten elements.

1. Develop a prospect
A clear prospect is the key to developing a product that meets the real needs of the stakeholders. The prospect captures the main points of the RUP requirement process: analyzing problems, understanding stakeholder needs, defining systems, and managing requirements when requirements change. The prospect provides a high-level, sometimes contractual basis for more detailed technical needs. As this term implies, it is a clear, usually high-level view of a software project and can be borrowed by any decision maker or implementer in the process. It captures high-level requirements and design constraints so that prospective readers can understand the system to be developed. It also provides input to the project approval process, so it is closely related to the business reasons. Finally, the prospects constitute "What is a project ?" And "Why is this project ?", Therefore, we can use prospects as one of the ways to verify future decisions. The outlook statement should be able to answer the following questions. If necessary, these questions can be further divided into smaller and more detailed questions :? What are the key terms? (Vocabulary )? What are the problems we are trying to solve? (Problem Statement )? Who are the stakeholders? Who is the user? What are their respective needs? ? What are the features of the product? ? What are functional requirements? (Use Cases )? What are non-functional requirements? ? What are design constraints?

2. Make a plan
"The product quality is only as good as the product plan ." (2) In RUP, the software development plan (SDP) integrates the various information required to manage the project, and may include some separate content for development in the startup phase. SDP must be maintained and updated throughout the project. SDP defines the project schedule (including the project plan and iteration plan) and resource requirements (resources and tools), and can track the project progress based on the project schedule. It also guides the planning of other process content (Original: Process components: project Organization, requirement Management Plan, configuration management plan, problem solving plan, QA plan, test plan, evaluation plan and product acceptance plan.

In a relatively simple project, there may be only one or two statements about these plans. For example, the configuration management plan can be simply stated as follows: at the end of each day, the content of the project directory will be compressed into a zip package, copied to a zip disk, and added with the date and version labels, put it in the central archive cabinet. The format of the software development plan is far from the plan activity itself and the idea that drives these activities is important. As Dwight D. Eisenhower said: "planning is nothing, and planning is everything ." Plan fulfillment-together with article 3rd, article 4, article 5, and article 8 in the list-captures the key points of the project management process in RUP. The project management process includes the following activities: Conception of projects, evaluation of project scale and risks, monitoring and control of projects, planning and evaluation of each iteration and phase.

3. Identify and reduce risks
One of the main points of RUP is to identify and handle the greatest risks early in the project. Each risk identified by the project team should have a corresponding mitigation or solution plan. The risk list should be used both as a planning tool for project activities and as the basis for determining iterations.

4. Allocate and track tasks
One thing that is important in any project is that continuous analysis comes from objective data of ongoing activities and evolving products. In RUP, regular project status evaluations provide mechanisms for describing, communicating, and solving management issues, technical issues, and project risks. Once the team discovers these obstacles (fences), they designate a person in charge for all these problems and specify the resolution date. The progress should be tracked regularly. Updates should be released if necessary. (Original article: Updates shoshould be issued as necessary .) The "snapshots" of these projects highlight issues that need to be noticed by management. As time changes/although the period may change (Original: while the period may be vary .), Regular evaluations enable managers to capture the history of the project and eliminate any obstacles or bottlenecks that limit the progress.

5. Check business reasons
Business reasons provide necessary information from a business perspective to determine whether a project is worth investing. Business reasons can also help develop an economic plan needed to achieve project prospects. It provides reasons for project implementation and establishes economic constraints. When the project continues, analysts use business reasons to correctly estimate the ROI (Return on Investment ). Business reasons should create a brief but compelling reason for the project, rather than in-depth research into the details of the problem, so that all project members can easily understand and remember it. In the key milestones, the manager should review the business reasons, calculate the actual cost and expected return, and determine whether the project will continue.

6. Design component architecture
In RUP, the framework of a component system refers to the organization or structure of key components of a system. components interact with each other through interfaces, while components are composed of smaller components and interfaces. That is, what is the main part? How are they combined? RUP provides a systematic approach to design, develop, and verify the architecture. The analysis and design process involves the following steps: defining candidate architectures, refined architectures, analyzing behavior (Case Analysis), and designing components. To describe and discuss the software architecture, you must first create a schema representation to describe important aspects of the architecture. In RUP, the architecture representation is captured by the software architecture document, which provides multiple views for the architecture. Each view describes a certain aspect of the ongoing system that a group of stakeholders are concerned. Stakeholders include end users, designers, managers, System Engineers, and system administrators. This document enables System Architects and other project team members to communicate effectively with major architecture-related decisions.

7. build and test products incrementally
The main point of the implementation and testing process in the RUP is to incrementally code, build, and test system components throughout the project lifecycle, and generate executable versions after each iteration ends. In the later stage of refinement, a framework prototype can be used for evaluation. If necessary, it can include a user interface prototype. Then, in each iteration of the build phase, components are constantly integrated into executable and tested versions, constantly evolving to the final product. Dynamic and timely configuration management and review activities are also the key to this basic process element.

8. verification and evaluation results
As the name suggests, the iterative evaluation of RUP captures the iterative results. The evaluation determines the degree to which the iteration meets the evaluation criteria, and also includes lessons learned and improvement of the implementation process. Based on the project scale, risks, and iteration characteristics, the evaluation can be a simple record of the demonstration and its results, or a complete and formal Test Review Record. The key here is to focus on both process issues and product issues. The sooner you discover the problem, the more trouble you have. (Original article: The sooner you fall behind, the more time you will have to catch up .)

9. manage and control changes
The main point of the configuration and change management process of RUP is to manage and control the scale of the project when a change occurs and run through the entire lifecycle. The goal is to consider all stakeholder needs, meet as much as possible, and deliver qualified products in a timely manner. After a user obtains the first prototype of a product (a change is often required before that), the user requests a change. It is important that the proposal and management process of changes are consistent. In RUP, change requests are generally used to record and track requirements for defects and enhancements, or any other types of change requests made to the product. A change request provides appropriate means to assess the potential impact of a change and record the decisions made for the change. They also help ensure that all project team members understand the potential impact of changes.

10. provide user support
In RUP, the key aspect of the deployment process is to package and deliver products while delivering any necessary material that helps end users learn, use, and maintain the product. The project team should provide users with at least one User Guide (maybe through online help), and there may be an installation guide and release notes. Based on the complexity of the product, users may need training materials. Finally, a bill of materials (BOM) is used to clearly record the materials to be delivered with the product. After reading my element list, someone may disagree with my selection. For example, he would ask, where is the demand? Are they not important? I will tell him why I didn't include them. Sometimes, I ask a project team (especially internal projects): "What are your requirements ?", The answer is: "We do not have any requirements ." I was surprised at the beginning (I have a background in the military's aerospace development ). Why are they not on demand? When I asked them further, I found that for them, the requirement meant a set of mandatory external statements asking them what they must do. Otherwise, the Project Acceptance would fail. But they did not get such a statement. Especially when the project team is engaged in research and development, product requirements are evolving from beginning to end. Therefore, I asked them another question: "Okay, what is the prospect of your product ?". Then their eyes lit up. Then, we communicated smoothly on the issues listed in the first element ("A Development Prospect"), and the demand flow naturally (original: and the requirements just flow naturally .). It may be useful to add "meet the requirement" to the element list only for projects that work under a contract with clear requirements. Remember, my list only represents a starting point for further discussion.

IX. Summary

RUP has many advantages: it improves team productivity, in terms of iterative development process, demand management, component-based architecture, visual software modeling, software quality verification, and software change control, provides necessary guidelines, templates, and Tool guidance for all key development activities, and ensures that all Members share the same knowledge base. It establishes a concise and clear process structure and provides greater versatility for the development process. However, it also has some shortcomings: RUP is only a development process and does not cover all the content of the software process, for example, it lacks content about software operation and support. In addition, it does not support the development structure for multiple projects, which reduces the possibility of reuse within the development organization to a certain extent. It can be said that RUP is a very good start, but it is not perfect, in practical application, you can improve it as needed, and supplement and improve it with the relevant content of other software processes such as open and oosp.