(Rational Company)
Summary
The Capacity Maturity Model (CMM) of Software Engineering Association (SEI) provides a famous software process maturity reference. CMM has become a popular tool in many fields for assessing the maturity of a software process for an organization. This white paper describes how Rational Unified Process supports organizations that are working hard to reach CMM level 2 (repeatable) and level 3 (defined) organization.
Introduction
The Ability Maturity Model (CMM) of Software Engineering Association (SEI) is a framework for describing effective software flow elements [REF1]. CMM describes a way from temporary, immature flows to mature, standardized processes.
CMM covers the planning, engineering and management experience of software development and maintenance. These key experiences have improved the ability of the organization to achieve cost, progress, functionality, and product quality.
CMM has five mature levels: from level 1 to level 5. As shown below. Each ripe level is composed of key process all, KPA, each KPA, determines a group of related activities. When these related activities are carried out, they complete a series of objectives that are considered to have important impact on the maturity level.
Level 2, "Repeatable Level" is defined as follows:
In the reable level, the policy of management software items should be established and the process steps of implementing these policies are implemented. The planning and management of new projects is based on similar projects. The goal of reaching the level 2 is to institutionalize the effective management process of the software project, so that organizations repeated successful experience in the past projects, even if the specific process of the project may differ. Features of the effective process can be summarized as skilled, documentated, strengthened, training, evaluation, and improved.
Level 2 organizes projects have already installed basic software management control. The real-in-law commitment is made based on the observations of previous projects and the demand for the current project. The software manager of the project tracks software cost, progress, and function and determines the problem that appears during the fulfillment of the commitment. Create a software requirement and a baseline of work products developed to meet these needs and control their integrity. After defining software project standards, organize to ensure that these criteria are unclosed. If there is a subcontractor, the software project can work with the subcontractor to establish a firm customer supplier relationship.
Software process capabilities of level 2 can be summarized in normalization, as the planning and tracking of software projects is stable, and previous successful experience can be reused. Process of the project is effectively controlled by the project management system, complying with the real-in-laws based on the performance of previous projects.
Level 2 KPA is:
Demand Management Software Project Planning Software Project Tracking and Investigation Software Bracket Management Software Quality Assurance Software Configuration Management
Level 3, "Defined Level" is defined as follows:
At the defined level, the standard process for organizing development and maintenance software has been recorded (including software engineering and management processes), and these processes are integrated into a coherent whole. The standard process always refers to the standard software flow of the organization throughout the CMM. The process established at level 3 is used for (it can be modified as necessary) Help software managers and technicians perform tasks more effectively. The organization uses effective software engineering experience and method using effective software engineering when establishing a standardized software process. There is a team responsible for organizing software process activities such as software engineering or SEPG. To ensure that employees and managers have knowledge and skills that have completed the assignment to their tasks, they need to implement training programs throughout the organization.
The project customizes the standard software process of the organization to develop their own software flows, so that the project has a unique feature. This customization process is a defined software process for the project in CMM. The defined software process contains a consistent, complete collection of defined software engineering and management processes. A clearly defined process can be summarized as a standard, input, implementation of the standard and procedure, and verify mechanisms (such as flat-level review), output, and complete standards. Since the software process is clearly defined, the management has a deep understanding of the technical progress of all projects. The software process capabilities of the level 3 organization can be summarized by standards because software engineering and management activities are not only stable but also repeatable. In the established product line, cost, progress and function are controlled, and the software quality is tracked. This process capacity is based on the activities, roles, and responsibilities of the already defined software process to form a joint understanding of the activities, roles, and responsibilities of the organization.
Level 3 kPa is:
Organization Process Key Organization Process Definition Training Program Integrated Software Management Software Products Engineering Group Collaboration Ping
The section of this article describes how Rational Unified Process features, methods, procedures, and workpieces implement KPA targets.
This article is written for organizational personnel who have mature level 2 and level 3 in the CMM framework.
Level 2, repeatable
Demand management
The purpose of demand management is to establish a consensus between customers and software items that handle customer needs. Unified recognition as customers is the basis for software project plans (such as software project planning KPA) and management (such as software project tracking and survey KPA). Control of customer relationships depends on performing a valid change control process (as described in software configuration management KPA).
One of the key features of Rational Unified Process is that it is driven by example. Use examples represent a systematic scheme for acquiring, organizing, and communicating user needs. They provide a way to record functionality, and functional demand is the basis for project development, testing and iterative planning. In Rational Unified Process, use cases are maintained in the use case model and unified references in the entire life cycle of the project, from analysis to test until maintenance.
The Rational Unified Process workpiece that gets the demand in the engineering environment is:
The use case model of use case model, the use case, the use case, the use case, the use case, the use case
Used in the management environment, the Rational Unified Process workpiece that describes how to develop and scenario (demand) includes:
Iterative Plan Integration Construction Plan Project Planning Software Development Plan
All of these workpieces have established baselines and are restricted by a certain change management.
Target 1: Control for system requirements assigned to the software to create a baseline of software engineering and management.
Rational Unified Process advocates continuous configuration control of all evolved artifacts, however, "official" baseline corresponds to the following milestones.
Lifecycle Target Milestones (First Phase), Lifecycle Milestones (Jinghua Stage), initial operational capacity milestones (construction phase), and product release milestones (productization phase).
Similarly, Rational Unified Process is consistent with CMM on demand, demand management, tracking, and creation baseline.
Target 2: Software Program, Products and Events consistent with system requirements assigned to software.
The CMM target focus is to ensure that the delivered system meets user needs. Rational Unified Process helps organizations achieve this goal by two ways:
Use an example scenario ensures that user needs are understood and taken. After obtaining demand, demand flows down to each "visual" Rational Unified Process model (use case, design, implementation, and test) to ensure consistency and coherence. The controlled iterative development plan is a risk reduction strategy, and the risk of this project can be understood and studied early, and then often re-examined. Every time you have an iteration, through the continuous integration of new features, early reveal risk. If traditional waterfall methods are used, these risks can be found until the later period of the development of life cycle. Early recognition risks have direct benefits on project management, redefine the scale of demand, or propose other tactical changes.
Rational Unified Process Management documentation includes:
Business reasons software development plan
Evaluation Plan Risk List Project Plan iterative Plan iterative evaluation and status assessment.
Effective change control and management is another feature of Rational Unified Process, which ensures that the software is developed based on assignment, subject to tracking specified requirements.
Rational Unified Process advocates that each project should set up a change control committee (CCB), making a break from the shortcomings of the proposed changes or defects discovered in the development process (budget, technical or time schedule). To assist CCB operations, Rational Unified Process recommends using a powerful configuration management and version control tools / environment.
Software project plan
The purpose of software project plan is to establish a reasonable plan, implement software engineering and management software projects. These plans are essential for software project management (such as software project tracking and survey KPA). There is no practical plan that is impossible to implement effective project management.
Target 1: Record software estimates for use in planning and tracking software projects.
One of the goals of Rational Unified Process is to ensure that all aspects of the expectations are synchronized and consistent. It ensures completed by regular assessments in the project life cycle, and records in the status assessment report. The report requires the resource (personnel equipping and finance), the primary top ten risks, technical progress tracking data, and measurements through indicators and main milestones.
Rational Unified Process utilizes the following categories:
Progress (number of codes, numbers, each iterative function point, rework) stability (rework type, demand or implementation change rate) adaptability (rework cost) module (rework impact range) Quality (defect discovery frequency, Density, inheritance depth, rework indicator mature (test time each fault) resource consumption profile (planned and actual)
Target 2: Plan and record software project activities and commitments.
Get project plans and commitments The Rational Unified Process documentation includes:
Business Reason Software Development Plan Evaluation Plan Risk List Project Plan iterative Plan iterative assessment, and status assessment.
Software project tracking and survey
The purpose of software project tracking and survey is to establish an appropriate visibility of actual progress so that management personnel take effective measures when the implementation of software projects are extremely deviated from software programs.
Target 1: Contrast software plans to track actual results and performance.
As described in the Software Project Plan, Rational Unified Process has several level project plans and a status assessment report. The status assessment report compares the programs and actual results, thereby evaluating. Generating a status assessment report for a specific milestone is the responsibility of the project manager.
The main Rational Unified Process milestones correspond to the end of a phase (first, refining, build or productization), which has clearly specified completion criteria. At the end of each iteration of a stage, there is an opportunity to review in the secondary milestone, which is also a decision-making point, and is the lesson of the future development direction. For example, the goal of the extension phase is to analyze the problem area, establish a solid framework foundation, formulate project plans, eliminate the highest risk in the project. The architecture decision must be made after the entire system has been understood. This suggests that some constraints will be considered when describing most of them: supplemental requirements. To verify the architecture, implement a system to prove that the selected architecture is correct and performs significant use cases.
At the end of the refining phase, check the detailed system objectives and scale, as well as the main risks of the selected architecture and determined. When actual results and performance are greatly deviated from software plans, take corrective actions and manage the end of the project.
The risk list is a Rational Unified Process workpiece that summarizes all known risks in the project and is used as inputs for planning and project evaluation. Each risk is described according to its influence and emergency plan, and the emergency plan is to reduce the risk. The risk list is developed with business cases, which forms a decision-making basis for "execution" or "do not implement" project. Risk list must be maintained throughout the life cycle of the project.
Target 2: The change of the software commitment has been affected by the affected team and the individual's consent.
As described by Rational Unified Process, the controlled iterative development process ensures that the project progresses often sees the progress of the project and to maintain any necessary changes to the project. The proposed change is reviewed by the Change Control Committee (CCB) to ensure that the change is in line with real-world, and can be accepted by the overall schedule of the project.
Software Bracket Management
The purpose of subcontract management is to select qualified software subcontractors and conduct valid management. It considers the basic management control of demand management, software project planning, software project tracking and survey, and the necessary coordination between software quality assurance and software configuration management, and controls the subcontractor at the appropriate time.
Target 1: Choose a qualified software subcontractor by the main contractor. Target 2: The main contractor and software subcontractors agreed to bear the obligations to be borne. Target 3: The main contractor and software subcontractors maintain a continuous communication.
Target 4: The main contractor is aimed at the actual results and implementation of its commitment to track software subcontractors.
These goals exceed the current range of Rational Unified Process and rely on the specific situation of the organization.
Although Rational Unified Process does not make a clear explanation of the project subcontract, its tools, techniques, and mechanisms are premised on the downward flow to the subcontractor, so the flow is still the same.
All subcontract decisions should be recorded in business reasons. Branch manufacturers who implement the same development plan with the main contractor also participate in activities such as technical exchange, main milestones and status assessments.
Software quality assurance
The purpose of software quality assurance is to provide managers to provide software projects used and visible to the product being constructed. Software quality assurance is a component of most software engineering and management processes.
Rational Unified Process believes that "Quality" is a common responsibility of all project employees, which is not reflected by the organization itself.
Target 1: Planning Software Quality Assurance Activity.
The planning of software quality assurance is a responsibility for organizations. However, Rational Unified Process has many properties to shape an effective project quality assurance plan.
Each Rational Unified Process milestone has specific completion criteria, which can be used as the basis of auditing. Each activity in Rational Unified Process has a separate review activity. Every review has a set of checkpoints, which represent "pass" "pass" before entering the next activity.
Rational Unified Process provides guidance about who should review the workpiece. For example, the result of the "Object Analysis" executed by the designer needs to be reviewed by an independent architect designer, designer, using case designer and design review. If there is a defined Rational Unified Process and workpiece review standards, product quality is closely related to the target entity should easily assess whether to comply with the process and whether it meets the development standards and guidelines. Target 2: Objectively verifying whether software products and activities comply with applicable standards, processes, and needs.
This goal can be achieved by selecting the quality assurance personnel of the organization. However, Rational Unified Process provides the necessary review lists and document templates that can be used as project standards.
Target 3: Will the software quality assurance activities and results notify the affected group and individual.
As described in the software project plan, one of the targets of Rational Unified Process is to ensure that the desired synchronization of the parties is consistent. In addition to the input provided by quality audit results, Rational Unified Process requires reports on resources (employee equipments and finances), primary top ten risks, measuring technologies and main milestones. The Rational Unified Process Indicators provides a guide to the following indicator collections:
Progress (code line, class, each iterative function point) stability (rework type, variability) adaptability (rework cost) Module (rework impact range) Quality (defect discovery frequency, density, inheritance depth) maturity Test time each fault) Resource consumption profile (planned and actual)
Target 4: Non-compatibility issues that cannot be resolved in the software project are handled by the advanced management.
This is beyond the scope of the Rational Unified Process, which belongs to the organization's responsibilities. However, the change control flow described in Rational Unified Process can drive a mechanism to record non-compatibility issues and can be recorded and submit it up to solve.
Software configuration management
The purpose of software configuration management is to establish and maintain integrity of software project products over the entire software life cycle of the project. Software configuration management is a component of most software engineering and management processes.
Target 1: Planning Software Configuration Management Activity.
If Rational Unified Process said, reliable configuration management is an essential element in a controlled iterative development method. Since software is a phased evolution, the previously developed software version can be used in subsequent development. How to develop guidance software is the core of the Rational Unified Process in each stage.
Rational Unified Process has two main means to specify how to maintain software development assets and how to integrate these assets:
Configure the management plan, and integrated build plan.
The configuration management plan started in the first phase describes the following:
The version of the management software; saves the specified Rational Unified Process model, divides them into multiple configuration items; use the change control method to manage change and release.
The integrated build plan provides details about the configuration items to be buffered and their integrated order in a particular iteration.
Target 2: OK, control the selected software work product and make it available.
Rational Unified Process Configuration Management Plan requires a description of the configuration control and management process to ensure that work products are identified and controlled, and it is available.
Target 3: Controls the change of the work product that has been determined.
Rational Unified Process claims that projects should have a change control committee (CCB) and a change management system to effectively manage, track, and implement change requests and calculate their change costs. Target 4: Wire the status of the software baseline and the content of the affected group and individual.
Rational Unified Process promotes the use of electronic maintenance requirements, design and implementing the baseline and the traceability between them. All changes of baseline are rulined by different levels of project control teams, respectively. For example, the Change Control Committee (CCB) is responsible for considering the impact of changes in demand levels. Smaller design and implementation changes, reviewed by the technical authority of the corresponding level. Approved, control levels, and their conveyed methods are described in the Configuration Management Plan and Software Development Plan, respectively.
Level 3, defined
Organization process
The purpose of organizational process is to establish organizational responsibilities of software process activities, which improve organizational overall software process capabilities. The main result of the key activities of the organization process is a set of software process assets that are described in the organization process definition. As described in integrated software management, software projects use these assets.
Target 1: Coordinate software process development and improvements within the organization.
Rational Unified Process is an iterative process that relies on re-establishing the "same" defined process in multiple iterations. The process of repeating properties, status indicators of the process, and the lessons learned at each stage and iteration provide the opportunity to adjust the process in continuous iterations.
Target 2: The advantages and disadvantages of software flow are identified according to the process standard.
Rational Unified Process represents an overall software development process, which can be customized to use it more effectively in a certain type of project. The environment workflow provides guidance on how to customize Rational Unified Processs. In addition to technology and management complexity, some process discriminant standards that can be used to determine the "shape" in the project are:
Business environment (speculative or internal contract) Software development workload size innovation application type
Target 3: Process development and improvement activities of planning organization levels.
This level 3 goals completely depend on the organization that adopts this level.
Organization process definition
The purpose of organizing process definition is to develop and maintain a set of applicable software process assets, improve project performance, and provide the organization's basis for the continuous accumulation of long-term benefits. These assets provide a stable basis for institutionalization through training and other mechanisms, which will be described in the training program.
Target 1: Develop and maintain a standard software process for organizations.
Rational Unified Process is a leading position in this regard and is used as an organization's baseline software development process that can be developed, customized and maintained.
Target 2: Collect, review information related to the standard software process of the organization using the software project, and make it available.
This goal needs to be supported by the organization of Rational Unified Process.
training program
The purpose of the training program is to develop personal skills and knowledge so they can perform their duties efficiently. Training is the responsibility of the organization, but the software project should first determine the skills required and provide the necessary training when the project needs are unique.
Target 1: Plan training activities.
This goal is only available to the organization of Rational Unified Process. However, Rational Unified Process is a "industry best program" knowledge base that provides guidelines, concepts and detailed steps on how to carry out various software development activities. Therefore, Rational Unified Process itself is an excellent training material source.
However, Rational Unified Process needs related support courses, including:
Rational Unified Process Overview, including demand, analysis, implementation, testing, architecture, process configuration, management, tool, etc., and introduction to the object-oriented object. By using an example to achieve demand management (RMUC) object-oriented project management (OOPM), object-oriented design analysis (OOAD) software quality automation configuration management software architecture and iterative process target 2: To develop software management and technical responsibilities Skills and knowledge provide training.
Target 3: Software Engineering Groups and other software-related groups accept the necessary training to fulfill their responsibilities.
The organization of the Rational Unified Process needs to achieve these training programs. However, Rational Unified Process provides a range of courses as described above.
Integrated software management
The purpose of integrated software management is to integrate software engineering and management activities into a consistent, determined software process, which is customized according to the standard software flow of the organization and related process assets, which is described in the organization process definition. As described in software product project, this customization is based on the technical needs of the business environment and projects. Integrated Software Management is obtained from software projects and survey evolutions from level 2 software project planning.
Target 1: The defined software process for the project is a custom version of the organization standard software process.
The Rational Unified Process environment workflow is consistent, and the standard delivery version of Rational Unified Process is configurable and can be used according to various types of items.
Target 2: Depending on the project's defined software process plan and manage items.
This goal is required by an organization using Rational Unified Process.
Software product engineering
The purpose of software product engineering is to unify a clearly defined software engineering process, integrating all software engineering activities in order to efficiently produce correct, consistent software products. Software product engineering description project technology activities, such as demand analysis, design, code, and testing.
Target 1: Definition, integration, and unify software engineering tasks for production software.
Rational Unified Process activities and what is needed for each role, ensuring determining, assigning, and completing tasks in the background of the project must-have-prime platform. The inner iterative development process in Rational Unified Process can quickly prove the effectiveness of the software development team and provide an assessment of the final product.
Target 2: Software products are consistent with each other.
The traceability between the engineering model (with an example model, the design model, the source code, and the executable member) is maintained through the environment.
Group collaboration
The purpose of the group collaboration is to provide a method for actively participating in the work of other engineering groups to better meet customer needs better in the project. Group collaboration is an interdisciplinary interdisciplinary integrated software management, which exceeds the scope of software engineering. Not only the software process should be integrated, but the interaction between the software engineering team and other groups must also coordinate and control.
Target 1: The customer's needs are agreed by the team involved in all projects.
Use the use case rather than other "formal" demand protocols as a significant benefit of the basis for the demand acquisition and description, the use case is easy to be understood by the public. Similarly, the Rational Unified Process demand acquisition method represents all the people who meet the tasks that need to be implemented. This is further implemented in the process and is reflected in the model and review of the software development basis.
Target 2: Commitment between Engineering Groups Gets recognition of the team involved.
This goal is required by an organization using Rational Unified Process. However, the Rational Unified Process model helps people understand what the product developed (from demand acquisition to deployment). Rational Unified Process Change and Configuration Management Process ensures that the proposed changes have been appropriately evaluated and the evaluation results are conveyed to all involved.
The engineering group determined, trackped and resolved the problem of blocking. The Rational Unified Process iterative development process helps to discover software issues earlier through continuous integration of all developments. To propose and solve problems between teams, problems generated when integrated with multiple teams can be used as a "public space". The Rational Unified Process Process supports this view that provides a formal mechanism for capturing, tracking and resolving project development issues.
Ping-level review
The purpose of the flat-level review is to effectively eliminate the defects of software work products. An important result is to deepen the understanding of software work products and preventable defects. Ping-level review is an important and effective engineering method proposed by software product projects.
Target-1: Plan a packet review activity.
As mentioned in the Quality Assurance Goals at Level 2, each activity in Rational Unified Process has an independent review activity.
Due to the overall cost, Rational Unified Process promotes all artifacts, especially key workpieces,,,, especially critical workpieces. Rational Unified Process provides an important list of important features to review within each model.
Target 2: Identify and exclude defects in software work products.
The Rational Unified Process workpiece reviewer needs to determine if the workpiece used in the next development phase is ready. If the workpiece does not reach the "qualified" standard, according to the Rational Unified Process Indicators, you need to get the following details:
Stability (rework type, variability) adaptability (rework cost) Module (rework impact range) Quality (defect discovery frequency, density, inheritance depth) maturity (test time of each fault) resource consumption profile (planned And actual)
Reference:
[REF1] Mark C. Paulk et al, "Key Practices of the Capability Maturity Model - Version 1.1", Software Engineering Institute - Carnegie Mellon University.
