See in more detail: http://www.ibm.com/developerworks/cn/rational/r-rupbp/
This article refers to: http://baike.baidu.com/view/2235832.htm#sub2235832
The Unified software development process (Rational Unified Process,rup) is an object-oriented and web-based program development methodology. It is a use case driven, architecture-centric, iterative and incremental software process framework that provides an evolutionary feature.
Two-dimensional structure
The development process can be expressed in a two-dimensional structure or along two axes:
- The horizontal axis represents the time when the development process is being developed, reflecting the dynamic structure of the process. It is expressed as a term cycle (cycles), stages (phase), iterations (iteration), and milestones (milestone).
- The vertical axis shows the static structure of the process: how to describe it using the term activity (activity), the product (artifact), the role (worker), and the Workflow (workflow).
The software life cycle in RUP is decomposed into four sequential phases: the initial phase (Inception), the refinement phase (elaboration), the tectonic phase (construction), and the delivery phase (Transition). Each phase ends at a major milestone (Major milestones); Each phase is essentially a time span between two milestones. An assessment is performed at the end of each phase to determine whether the goals for this phase have been met. If the evaluation results are satisfactory, the project can be allowed to enter the next phase .
1. Initial stage
- The objective of the initial phase is to establish a business case for the system and to determine the boundaries of the project.
In order to achieve this, all external entities interacting with the system must be identified and the characteristics of the interaction defined at a higher level. It includes identifying all use cases and describing some of the important use cases. Business cases include acceptance specifications, risk assessments, estimated resource requirements, and phase plans that reflect the major milestone dates. This stage is of great importance, and at this stage, the focus is on the major risks of the business and requirements of the project in the project. For development projects based on legacy systems, the initial phase may be short.
The main objectives of this phase are as follows:
Define the scope and boundary conditions of the software system, including the outlook analysis from a functional perspective, product acceptance criteria and what to do and what not to do with relevant decisions
Identify key use Cases (use-case) and major functional scenarios for the system
Demonstrate or demonstrate at least one candidate software architecture that meets the requirements of the main scenario
Initial project cost and schedule estimates for the entire project (more detailed estimates will be made in the subsequent refinement phase)
Estimating potential risks (mainly the potential risks caused by various uncertainties)
Prepare the project Support environment
The initial phase outputs are:
Blueprint Document Core project requirements key features main constraints of the overall blueprint
Original use case model (complete 10%~20%)
Original Project Glossary (possibly partially expressed as a business model)
Original business case, including business context, acceptance specification (annual mapping, market approval, etc.), cost estimate
The original risk assessment
One or more prototypes
Milestones: The goal of the life cycle
- The initial stage of the review criteria:
Stakeholders agree on scope definition cost schedule estimates
Confirm the understanding of requirements with objective main use cases
Cost/schedule, priority, risk, and credibility of the development process
The depth and breadth of the architecture prototype being developed
Comparison of actual expenditure with planned expenditure
If these milestones cannot be passed, the project may be canceled or reconsidered carefully.
2. Refinement Phase
- The objective of the refinement phase is to analyze the problem areas, establish a sound architecture foundation, prepare the project plan, and eliminate the highest risk elements in the project.
In order to achieve this, the system must have "miles wide and inches deep" observation. Architecture decisions must be made on the basis of an understanding of the entire system: its scope, main functions, and non-functional requirements such as performance.
Easily contentious, the refinement phase is the most critical phase of the four phases. At the end of the phase, a hard "project" can be considered closed and the project undergoes a final Judgment day: whether the decision is submitted to the build and delivery phases. For most projects, this is also the equivalent of moving from a mobile, easy, agile, low-risk operation to a high-cost, high-risk operation with greater inertia. The process must be able to accommodate changes, and the refinement phase activities ensure that the structure, requirements and plans are sufficiently stable and the risks are sufficiently mitigated, so that the cost and schedule can be predetermined for the development results. Conceptually, its fidelity is consistent with the degree of necessity of a fixed construction phase of the cost of the institution. In the elaboration phase, the prototype of an executable structure is established in one or more iterations, depending on the scope, scale, risk, and sophistication of the project. The workload must address at least the critical use cases identified during the initial phase, and the key use cases typically reveal the risks of the project's main technology. Often our goal is an evolutionary prototype made up of product quality level components, but this does not preclude the development of one or more exploratory, disposable prototypes to reduce such specific risks as design/demand tradeoffs, component feasibility studies, or to investors, customers, and end-user demo versions.
The main objectives of this phase are as follows:
Ensure that the software structure, requirements, plans are stable enough, and that the project risk is reduced to the extent that the cost and schedule of the project can be estimated.
The major risks on the software structure of the project have been resolved or processed.
Establish a baseline of the software architecture by completing the main scenarios on the software architecture.
Build an evolutionary prototype of a product that contains high-quality components.
The description of the baseline software architecture ensures that the system requirements can be controlled within a reasonable cost and time frame.
Build a supportive environment for your product.
The initial phase outputs are:
Use case model (at least 80% complete)-all use cases are identified and most use case descriptions are developed
Complementary requirements for capturing non-functional requirements and non-related to specific use case requirements
Software Architecture Description _ executable software prototype
Revised risk list and business case
Overall project development plans, including coarser grained project plans, showing iterative processes and corresponding audit standards
Indicates the updated development case of the used process
Initial version of the user manual (optional)
Milestones: The structure of the life cycle
The refinement phase end is the second important milestone: the structural milestone of the life cycle. Now, examine the detailed system objectives
and scope, structure selection and major risk solutions. The main audit criteria include answering the following questions:
is the blueprint for the product stable?
Is the architecture stable?
Whether the executable demo version shows that the risk elements have been handled and resolved reliably
Is the plan for the build phase sufficiently detailed and accurate? Are you supported by a reliable audit foundation?
If the current plan is being implemented in an existing architecture environment to develop a complete system, are all stakeholders agreeing that the blueprint is achievable?
is the actual cost of expenditure and the planned expenditure acceptable?
If these milestones cannot be passed, the project may be canceled or reconsidered carefully.
3. Construction phase
- During the build phase, all remaining component and application functions are developed and integrated into the product, and all functions are thoroughly tested.
The construction phase, in a sense, is the production process that focuses on managing resources and controlling operations to optimize costs, schedules, and quality. In this regard, the concept of management has undergone a transition from the initial stage and the refinement phase of intellectual asset development to the build phase and delivery phase of the release product. Many projects are large enough to produce many parallel incremental build processes that can greatly accelerate the effectiveness of release releases, while also increasing the complexity of resource management and workflow synchronization. Robust architectures and easy-to-understand plans are highly correlated. In other words, the key quality of architecture is the ease with which it is built. This is also why the architecture and plan are stressed in the refinement phase.
The main objectives of this phase are as follows:
Minimize development costs by optimizing resources and avoiding unnecessary rework
Achieve the right quality goals according to actual needs
According to the actual need to form each version (Alpha,beta,and other test release)
Complete analysis, design, development and testing of all required functions
Develop a complete product that can be presented to end users in a circular, progressive way
Make sure the software site users are ready for the final deployment of the product
Achieve a certain level of parallel development mechanism
The output of the build phase is the product that can be delivered to the end user. It consists of the smallest:
Integrated products on a specific platform
User manual
Description of the current version
Milestones: Initial operational capabilities
- The end of the creation phase is the third important project milestone (initial feature milestone). At this point, decide whether the software, the environment, the user can operate without exposing the project to high risk. This version is also often referred to as the "beta" version.
The main audit criteria during the construction phase include answering the following questions:
is the product stable and mature enough to be released to the user?
Are all risk stakeholders ready to hand over to the user?
Is the comparison between actual and planned costs still acceptable?
If these milestones cannot be passed, the handover has to be delayed.
4. Delivery Phase
- The purpose of the delivery phase is to deliver software products to the user community.
As long as the product is released to the end user, the problem often arises: the requirement to develop a new version, correct the problem, or complete the deferred issue. When the baseline is mature enough to be published to the end user, it enters the delivery phase. The typical requirement is that some of the available subset of systems be developed to the acceptable quality level and that user documentation is available so that all parts delivered to the user can have a positive effect. This includes:
Verify the "beta test" of the new system against user expectations
Bounce with an existing system that has been replaced
Conversion of functional databases
Transfer products to market, deployment, and sales teams
The build phase focuses on the activity of submitting products to users. Typically, this phase includes several repeating processes, including the Beba version, the generic version, the bug fix, and the enhanced version. A considerable amount of work is consumed in developing user-facing documents and training users. Support users and process user feedback when the initial product is in use. At this point in the development lifecycle, user feedback is primarily limited to product performance tuning, configuration, installation, and usage issues.
The objective of this phase is to ensure that software products can be submitted to end users. This stage can be divided into several cycles according to actual needs.
- The specific objectives of this phase are as follows:
Beta testing to meet end-user needs
Perform a beta test and bounce the old system
Transform function Database
Training for end-users and product support personnel
Submit to market and product sales Department
and specific deployment-related engineering activities
Reconcile Bug fixes/improvements in performance and availability (usability)
Evaluation of final deployment based on complete Vision and product acceptance criteria
Meet the satisfaction of user requirements
Reach consensus on the product deployment baseline that the stakeholders have completed
Achieve consensus among risk stakeholders on product deployment in line with Vision standards
This phase can vary from very simple to extremely complex, depending on the type of product. For example, the new version of existing desktop products can be very simple, and the alternative to international airport traffic systems can be very complex.
Milestones: Product Launches
- At the end of the delivery phase is the fourth major project milestone, a product release milestone. At this point, decide whether the target has reached or started another cycle. In many cases, milestones overlap with the initial phase of the next cycle.
The audit standards for the release phase include the following two questions:
Is the user satisfied?
Is the comparison between actual and planned costs still acceptable?
There are 9 core workflows in the RUP, divided into 6 core process workflows (core processes workflows) and 3 core support workflows (core supporting workflows). Although 6 core process workflows may remind you of several stages in a traditional waterfall model, it should be noted that the stages in the iteration are completely different, and that the workflows are accessed over and over the life cycle. 9 Core workflows are used in turn in the project and are repeated in each iteration with different emphasis and intensity.
1. Commercial modelling (business Modeling)
The Business modeling workflow describes how to develop a vision for a new target organization and define the processes, roles, and responsibilities of the organization in the business use case model and business object model based on this concept.
2. Requirements (Requirements)
The goal of the requirements workflow is to describe what the system should do and to enable developers and users to agree on this description. In order to achieve this goal, it is necessary to extract, organize and document the functions and constraints required, and most importantly to understand the definition and scope of the problem solved by the system. Blueprints are created and requirements are extracted. Actors representing users and other systems that may interact with the development system are indicated. The use case is identified to indicate the behavior of the system. Because the use case is developed according to the actor's requirements, the system is more closely connected with the user. The system presents a use case model for regenerative systems.
3. Analyses and designs (analysis & Design)
The analysis and design workflow transforms the requirements into the design of the future system, develops a robust structure for the system and adjusts the design to match the implementation environment, optimizing its performance. The result of the analysis design is a design model and an optional analysis model. The design model is the abstraction of the source code, which consists of a design class and some descriptions. Design classes are organized into design packages (package) and design subsystems (Subsystem) with good interfaces, and the description shows how the objects of the class work together to implement the functionality of the use case. Design activities are centered on architectural design, and the architecture is represented by a number of structural views, which are abstractions and simplifications of the entire design, omitting some details and making important features clearer. Architecture is not only the bearer medium of good design model, but also can improve the quality of the model being created in the system development.
4. Implementation (Implementation)
The purpose of the workflow is to define the organizational structure of the code in a hierarchical subsystem, to implement classes and objects in the form of components (source files, binaries, executables), to test the developed components as units, and to integrate the results produced by a single developer (or group). Make it an executable system.
5. Testing (Test)
The test workflow verifies the interaction between objects, verifies the correct integration of all components in the software, validates that all requirements have been correctly implemented, identifies and verifies that the defect was presented and processed before the software was deployed. RUP proposes an iterative approach that means testing throughout the project to detect defects as early as possible, radically reducing the cost of modifying defects. Tests are similar to three-dimensional models, from reliability, functionality, and system performance, respectively.
6. Deployment (Deployment)
The purpose of the deployment workflow is to successfully build the version and distribute the software to the end user. Deployment workflows describe activities that are related to ensuring the availability of software products to end users, including software packaging, producing products other than the software itself, installing software, and providing assistance to users. In some cases, it may also include planning and conducting beta tests, porting existing software and data, and formal acceptance.
7. Configuration and change management (configuration & Changes Management)
The configuration and Change management workflow depicts how to control a large number of artifacts in a project consisting 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. Workflows describe how to manage parallel development, distributed development, and how to automate the creation of projects. At the same time, it also expounds the reasons for product modification, time and personnel to maintain audit records.
8. Item Management (Project Management)
software project management balances all possible conflicting goals, manages risks, overcomes constraints and successfully delivers products that are satisfied with the user. Its objectives include providing a framework for project management, providing practical guidelines for planning, staffing, implementation and monitoring projects, and providing a framework for managing risk.
9. Environment (Environment)
The purpose of the environment workflow is to provide software development organizations with a software development environment, including processes and tools. The environment workflow is focused on the activities required to configure the project, as well as supporting the activities for developing the project specification, providing a step-by instruction manual and how to implement the process in the organization.
RUP---Unified software development process
