Use RUP to reach level 2 and level 3

Source: Internet
Author: User
Tags knowledge base

(Rational)


Summary

The Software Engineering Association (SEI) Capability Maturity Model (CMM) provides a well-known software process maturity benchmark. CMM has become a popular tool in many fields to evaluate the maturity of an organization's software processes. This White Paper explains how rational uniied process supports organizations that are working to reach CMM Level 2 (repeatable) and level 3 (defined.


Introduction

The Software Engineering Association (SEI) Capability Maturity Model (CMM) is a framework [ref1] That describes elements of an effective software process. CMM describes a way to evolve from a temporary and immature process to a mature and standardized process.

CMM covers software development and maintenance planning, engineering, and management experience. These key experiences improve the Organization's ability to achieve goals such as cost, progress, functionality, and product quality.

CMM has five maturity levels: from Level 1 to level 5. As shown in. Each maturity level consists of key process areas (kPa), and each kPa determines a set of related activities. When these activities are carried out together, they fulfill a series of goals that are considered to have an important impact on building process capabilities at this level of maturity.

 

 


Level 2 and "Repeatable Level" are defined as follows:

At the repeatable level, policies for managing software projects should be established and steps for implementing these policies should be taken. Planning and management of new projects are based on the experience of similar projects. The goal of achieving Level 2 is to systematize the effective management process of software projects, so that organizations can repeat the successful experience gained from past projects, even if the specific process of project implementation may be different. The features of an effective process can be summarized into skilled, documented, enhanced, trained, evaluated, and improved.

Project of level 2 Organization has installed basic software management control. Realistic project commitments are made based on the observed results of previous projects and the requirements of current projects. The software manager of the Project tracks software costs, schedules, and functions, and identifies issues that arise during the performance of the commitment. Create software requirements and baseline for work products that meet these requirements, and control their integrity. After defining software project standards, the organization ensures that these standards are fully implemented. If a subcontractor exists, the software project can work with the subcontractor to establish a strong customer supplier relationship.

The software process capabilities of level 2 organizations can be summarized by standardization, because the planning and tracking of software projects are stable and previous successful experiences can be reused. Project processes are effectively controlled by the Project Management System and comply with realistic plans based on the performance of previous projects.


Level 2 kPa is:

  • Demand management
  • Software Project Planning
  • Software project tracking and survey
  • Software Subcontract Management
  • Software Quality Assurance
  • Software Configuration Management

     


Level 3: "defined level" is defined as follows:

At a defined level, the standard processes for organizing the development and maintenance of software have been documented (including software engineering and management processes) and these processes are integrated into a coherent whole. The standard process always refers to the standard software process of the Organization throughout the CMM. Processes established at level 3 are used (can be modified if necessary) to help software managers and technicians perform tasks more effectively. When establishing standardized software processes, the organization uses effective software engineering experience and methods. A group is responsible for organizing software process activities, such as software engineering or SEPG. To ensure that employees and managers have the knowledge and skills required to complete the tasks assigned to them, they need to implement training programs throughout the organization.

The project customizes the Organization's standard software processes and develops their own software processes, so that the project has unique characteristics. In CMM, this custom process refers to the defined software process of the project. A defined software process contains a consistent and complete set of clearly defined software engineering and management processes. Clearly defined processes can be categorized into standards and processes that contain readiness criteria, input and execution criteria, verification mechanisms (such as peer review), output and completion criteria. With the software process clearly defined, the management has a deep understanding of the technical progress of all projects.

Level 3 the software process capabilities of an organization can be summarized by standards consistency, because software engineering and management activities are not only stable but can be repeated. Within the established product line, costs, progress, and functions are controlled and software quality is tracked. This process capability is built on a common understanding of the activities, roles, and responsibilities of the defined software processes of the entire organization.


Level 3 kPa is:

  • Organization Process focus
  • Organizational Process Definition
  • Training Plan
  • Integrated Software management
  • Software product engineering
  • Inter-group collaboration
  • Classified Review

The sections in this article describe how the attributes, methods, programs, and artifacts of the Rational Unified Process achieve the KPA goal.

This article is intended for organizations who are concerned with achieving level 2 and level 3 of Organizational Maturity within the CMM framework.

 


Level 2, repeatable

 

Demand management

Demand management aims to build consensus between customers and software projects that process customer requirements. A unified understanding with the customer is the basis for Software Project Planning (as described in the KPA for Software Project Planning) and management (as described in the KPA for software project tracking and Survey. The control of customer relationships relies on the execution of effective change control procedures (as described in the Software Configuration Management kPa ).

One of the key features of Rational Unified Process isCase-driven. Use cases represent a systematic solution for obtaining, organizing, and communicating user needs. They provide a way to record functional requirements, and functional requirements are the basis for project development, testing, and iterative planning. In Rational Unified Process, use cases are maintained in the case model and referenced throughout the entire project lifecycle, from analysis to testing to maintenance.

The Rational Unified Process artifacts for obtaining requirements in the engineering environment are:

  • Use Case model composed of Use Cases and Use Case packages
  • Non-functional "supplemental Statute"
  • Case model survey
  • Case Report
  • Vocabulary

The Rational Unified Process artifacts Used in the management environment to describe the development cases and scenarios (requirements) include:

  • Iteration plan
  • Integrated build plan
  • Project Plan
  • Software Development Plan

All these artifacts have been baseline established and are subject to a change management provision.


Goal 1: Controls System Requirements assigned to software to create software engineering and management baselines.

Rational Unified Process requires continuous configuration control for all evolved artifacts. However, the "formal" baseline corresponds to the following milestones.

  • Target milestones of the lifecycle (initial stage ),

  • Milestones in the lifecycle architecture (refined stage ),

  • Initial operational capability milestones (build phase) and

  • Product Release milestones (productization phase ).

Similarly, the Rational Unified Process is consistent with the CMM in terms of requirements, requirement management, tracking, and creation.


Objective 2: Ensure that the software plans, products and activities are consistent with the system requirements assigned to the software.

The CMM aims to ensure that the delivered system meets user needs. Rational uniied process helps organizations achieve this goal in two ways:

  • Case SchemeMake sure that your requirements are understood and obtained. Once the requirement is obtained, the demand flows down to each "visible" Rational Unified Process Model (use cases, design, implementation, and testing) to ensure consistency and consistency.
  • Controlled iterative developmentThe solution is a risk reduction strategy, so that project risks can be understood and researched as early as possible, and then often re-checked. Every progressive iteration, through continuous integration of new features, early risk exposure. If the traditional waterfall method is used, these risks will not be discovered until the development lifecycle is later. Early identification of risks directly benefits project management. You can redefine the demand scale or propose other tactical changes.

The Rational Unified Process Management documentation includes:

  • Business reasons
  • Software Development Plan
    • Evaluation Plan
    • Risk list
    • Project Plan
  • Iteration plan
  • Iterative evaluation and status evaluation.

Effective change control and management is another feature of Rational Unified Process. It ensures that the software is developed based on assigned, tracked, and specified requirements.

Rational Unified Process advocates that a change control board (CCB) should be set up for each project ), make a public suspension of the scale and impact (Budget, technology or Schedule) of the defects found during the proposed change or development process. To assist CCB in its operation, we recommend that you use powerful configuration management and version control tools/environments.

 


Software Project Planning

The purpose of software project planning is to establish reasonable plans, implement software engineering and manage software projects. These plans are essential for software project management (as described in the software project tracking and survey kPa. Effective project management cannot be implemented without realistic plans.


Goal 1: record software estimates for planning and tracking software projects.

One of the goals of Rational Unified Process is to ensure that all expectations are synchronized and consistent. It ensures completion through regular assessment within the project lifecycle and is recorded inStatus Evaluation Report. The report needs to measure data on resources (staffing and finance), top 10 risks, and technological advances through indicators and major milestones.

Rational Unified Process utilizes the following types of metrics:

  • Progress (number of code lines, classes, function points for each iteration, and rework)
  • Stability (rework type, demand, or implementation Change Rate)
  • Adaptability (rework cost)
  • Module level (impact scope of rework)
  • Quality (defect discovery frequency, density, inheritance depth, rework indicator)
  • Maturity (test time of each fault)
  • Resource Consumption configuration file (planned and actual)


Objective 2: plan and record software project activities and commitments.

The Rational Unified Process documentation for obtaining project plans and commitments includes:

  • Business reasons
  • Software Development Plan
  • Evaluation Plan
  • Risk list
  • Project Plan
  • Iteration plan
  • Iterative evaluation, and
  • Status Evaluation.

 


Software project tracking and survey

The purpose of software project tracking and surveys is to establish appropriate visibility of actual progress so that managers can take effective measures when the implementation of software projects significantly deviates from the software plan.


Objective 1: Compare the actual results and performance of software plans.

For exampleSoftware Project PlanningAs described in section 1, Rational Unified Process has several levels of project plans and oneStatus Evaluation Report. The status evaluation report compares the plan with the actual results for evaluation. Generating status evaluation reports for specific milestones is the responsibility of the Project Manager.

The major rational uniied process milestones correspond to the end of a phase (initial, refined, built, or productized), with clearly specified completion standards. At the end of each iteration of a stage, there is a review opportunity at a secondary milestone. This is also a decision point and a lesson for future development.

For example, the goal of the finalization stage is to analyze the problem field, establish a solid framework Foundation, develop a project plan, and eliminate the most risky elements in the project. You must have an understanding of the entire system before you can make architectural decisions. This implies that some constraints will be taken into account when describing most of the cases: supplementary requirements. To verify the architecture, implement a system to prove that the selected architecture is correct and execute significant use cases.

Check detailed system objectives and scale at the end of the Refinement phase,And the selected architecture and identified main risks. When the actual results and performance greatly deviate from the software plan, take corrective actions and manage them until the project ends.

Risk listIs a Rational Unified Process, which summarizes all known risks in the project and serves as an input for planning and project evaluation. Each risk is described based on its impact and contingency plan, which is designed to reduce risks. The risk list is developed together with the business case, which forms the decision-making basis for "executed" or "not executed" projects. The risk list must be maintained throughout the project lifecycle.


Objective 2: Changes to the software commitment are approved by the affected group and individual.

As described in rational uniied process, the controlled iterative development process ensures that stakeholders often see the progress of the project and any necessary changes made to keep the project from off track. The proposed changes should be reviewed by the Change Control Board (CCB) to ensure that the changes are realistic and can be accepted by the project's overall schedule.

 


Software Subcontract Management

The purpose of subcontract management is to select qualified software subcontractors and manage them effectively. It comprehensively considers the basic management control of demand management, software project planning, software project tracking and survey, as well as the necessary coordination between software quality assurance and Software Configuration Management, control Sub-contractors as appropriate.


Objective 1: The primary contractor selects qualified software subcontractors.

Objective 2: The primary contractor and the software subcontractor agree to each other's obligations.

Objective 3: maintain continuous communication between the primary contractor and the software subcontractor.

Objective 4: The main contractor follows up on the actual results and implementation of the software subcontractor for its commitment.

These goals are beyond the current scope of the Rational Unified Process and depend on the specific circumstances of the Organization.

Although rational uniied process does not explicitly describe project subcontracting, its tools, technologies, and mechanisms are all on the premise of moving downward to the subcontractor, so the process is still similar.

All subcontracting decisions should be recorded on commercial grounds. Subcontractors that execute the same development plan with the primary contractor are also involved in activities such as technical exchanges, major milestones and status evaluations.

 


Software Quality Assurance

The purpose of software quality assurance is to provide managers with visibility of the processes used for software projects and the products being built. Software Quality Assurance is an integral part of most software engineering and management processes.

Rational Unified Process considers "quality" as the shared responsibility of all project employees, which is not reflected by the Organization itself.


Goal 1: Plan software quality assurance activities.

The planning of software quality assurance is a responsibility of the Organization. However, Rational Unified Process has many attributes used to shape an effective project quality assurance plan.

Each Rational Unified Process milestone has specific completion standards that can serve as the basis for auditing. Each activity in Rational Unified Process has a separate review activity. Each review is associated with a set of checkpoints, which indicate the checkpoints that must be passed before entering the next activity".

Rational uniied process provides guidance on who should review the given artifacts. For example, the results of the object analysis performed by the designer need to be reviewed by an independent architect, designer, Case designer, and design reviewer. If there are defined Rational Unified Process and artifacts review standards, target entities closely related to product quality should be able to easily assess compliance with processes and compliance with development standards and guidelines.


Objective 2: objectively verify that software products and activities comply with applicable standards, processes and needs.

This goal can be achieved by selecting the organization's quality assurance personnel .. However, rational uniied process provides the necessary review lists and document templates that can be used as project standards.


Objective 3: To notify affected groups and individuals of software quality assurance activities and results.

For exampleSoftware Project PlanningAs described, one of the goals of Rational Unified Process is to ensure that the expectations of all parties are synchronized and consistent. In addition to inputs provided based on quality audit results, Rational Unified Process also requires resources (staffing and finance) top 10 risks, technical progress measured by indicators, and major milestone results. The Rational Unified Process metric plan provides guidance on the following metric sets:

  • Progress (Function Points of code lines, classes, and each iteration)
  • Stability (rework type, variability)
  • Adaptability (rework cost)
  • Module level (impact scope of rework)
  • Quality (defect discovery frequency, density, and inheritance depth)
  • Maturity (test time of each fault)
  • Resource Consumption configuration file (planned and actual)


Objective 4: The senior management is responsible for the non-compatibility issues that cannot be solved within the software project.

This is beyond the scope of Rational Unified Process and falls into the responsibility scope of the Organization. However, the change control process described in rational uniied process can drive a mechanism to record non-compatibility issues, record them, and submit them up for resolution.

 

Software Configuration Management

The purpose of Software Configuration Management is to establish and maintain the integrity of software project products throughout the entire software life cycle of the project. Software Configuration Management is an integral part of most software engineering and management processes.


Goal 1: Plan Software Configuration Management activities.

As described in Rational Unified Process, reliable configuration management is an essential element in a controlled iterative development method. Since the software is evolved in stages, it is very important that the previous software version can be used for subsequent development. Planning how to develop guiding software at each stage is at the core of the Rational Unified Process.

Rational Unified Process has two main measures to define how to maintain the software development assets of a project and how to integrate these assets:

  • Configuration Management Plan and
  • Integrate the build plan.

The Configuration Management Plan started at the startup stage describes the following:

  • Manage Software versioning and processing;
  • Save the specified Rational Unified Process Model and divide it into multiple configuration items;
  • Use the change control method to manage changes and releases.

The integration build plan provides detailed information about the configuration items to be built and their integration sequence in a specific iteration.


Objective 2: determine and control the selected software work product and make it available.

The Rational Unified Process configuration management plan requires a description of the configuration control and management process to ensure that work products are indeed identified and controlled and available.


Objective 3: To control the changes to the identified software work products.

Rational Unified Process claims that the project should have a change control board (CCB) and a change management system to effectively manage, track and implement change requests and calculate their change costs.


Goal 4: notify affected groups and individuals of the software baseline status and content.

Rational Unified Process advocates the use of electronic means to maintain requirements, design and implementation baselines, and traceability between them. All changes to the baseline are determined by different project control teams. For example, the CCB is responsible for considering the impact of changes at the demand level. For small-scale design and implementation changes, the corresponding level of technical authority should review the changes. The approval, control level, and how they are delivered areConfiguration Management PlanAndSoftware Development Plan.

 


Level 3, defined

 

Organization Process focus

The focus of the organizational process is to establish the responsibilities of software process activities, which improve the overall software process capability of the Organization. The main result of the Organization's key activities is a set of software process assets, which are described in the organization's process definition. As described in integrated software management, software projects use these assets.


Objective 1: coordinate software process development and improvement activities within the Organization.

Rational uniied process is an iterative process that relies on repeated Iteration"Same"The process that has been defined. The repetitive nature of the process, evaluation of status indicators, and lessons learned from each stage and iteration provide the opportunity to adjust the process in successive iterations.


Objective 2: Identify the advantages and disadvantages of a software process based on the relative process standards.

Rational Unified Process represents an overall software development process that can be customized to make it more effective for a type of project.Environment WorkflowProvides a guide on how to customize the Rational Unified Process. In addition to technical and management complexity, the project can be used to determine the process"Shape"Some process identification criteria include:

  • Business Environment (speculative or internal contracts)
  • Workload of Software Development
  • Degree of Innovation
  • Application Type


Objective 3: To plan process development and improvement activities at the organizational level.

The Level 3 goal is completely dependent on the organization that uses this level.

 


Organizational Process Definition

The purpose of an organizational process definition is to develop and maintain a set of applicable software process assets, improve the performance of the project process, and provide the Organization with a basis for accumulating long-term benefits. These assets provide an institutionalized and stable foundation through training and other mechanisms, as described in the training plan.


Objective 1: Develop and maintain a standard software process for the Organization.

Rational Unified Process is a leader in this respect and can be used as a baseline software development process for an organization to develop, customize, and maintain it.


Objective 2: Collect and review information related to the Organization's standard software processes for use of software projects and make them available.

This goal needs to be supported by organizations that use the Rational Unified Process.


 

Training Plan

The purpose of the training program is to develop personal skills and knowledge so that they can efficiently perform their duties. Training is the responsibility of the organization, but software projects should first determine the required skills and provide the necessary training when the project needs are unique.


Objective 1: To plan training activities.

This goal can be achieved only by organizations that use the Rational Unified Process. However, rational uniied process is an "industry best solution" knowledge base that provides instructions, concepts, and detailed step-by-step instructions on how to conduct various software development activities. Therefore, Rational Unified Process itself is an excellent source of training materials.

However, rational uniied process also requires related support courses, including:

  • The overview of Rational Unified Process includes requirements, analysis and design, implementation, testing, architecture, Process configuration, management, tools, and other modules.
  • Use Cases to implement requirement Management (rmuc)
  • Object-oriented project management (oopm)
  • Object-Oriented Design Analysis (OOAD)
  • Software Quality Automation
  • Configuration Management
  • Software Architecture and iterative process


Objective 2:Provide training to develop the skills and knowledge required to fulfill software management and technical responsibilities.


Objective 3: individuals in the software engineering group and other software-related groups receive the necessary training to perform their duties.

Organizations that use Rational Unified Process need to achieve these training program goals. However, rational uniied process provides a series of courses, as described in the previous section.

 


Integrated Software management

The purpose of integrated software management is to integrate software engineering and management activities into a consistent and definite software process that is customized according to the Organization's standard software process and related process assets, this is described in the organizational process definition. As stated in the software product project, the customization is based on the business environment and technical needs of the project. Integrated Software management is achieved from Level 2 Software Project Planning and software project tracking and survey evolution.


Objective 1: the project's defined software process is a customized version of the Organization's standard software process.

And Rational Unified ProcessEnvironment WorkflowConsistent, the standard delivery version of Rational Unified Process is configurable and can be adjusted based on various types of projects.


Goal 2: plan and manage the project according to the defined software process of the project.

This goal needs to be explained by the organization using Rational Unified Process.

 


Software product engineering

The purpose of software product engineering is to uniformly implement a clearly defined software engineering process and integrate all software engineering activities to efficiently produce correct and consistent software products. A software product project describes the technical activities of a project, such as requirement analysis, design, code, and testing.


Goal 1: Define, integrate, and uniformly execute software engineering tasks to produce software.

The Rational Unified Process activities and definitions of what each role needs ensure that tasks are identified, assigned, and completed in the context of the project's essential planning artifacts. The iterative development process inherent in the Rational Unified Process can quickly prove the effectiveness of the software development team and provide assessment of the final product.


Objective 2: software products are consistent.

Traceability between engineering models (case model, design model, source code and executable components) is maintained through the environment.

 


Inter-group collaboration

The purpose of inter-group collaboration is to provide a way for the software engineering team to actively participate in the work of other engineering teams, so that the project can better and efficiently meet customer needs. Inter-group collaboration is an interdisciplinary aspect of integrated software management and beyond the scope of software engineering. Not only should software processes be integrated, but interactions between software engineering teams and other groups must also be coordinated and controlled.


Goal 1: the customer's requirements are approved by the teams involved in all projects.

Use Cases Instead of other"Formal"A major benefit of the requirement specification method as a basis for requirement acquisition and description is that use cases are easily understood by the stakeholders. Similarly, the rational uniied process case requirement acquisition method allows all stakeholders to reach an agreement on the tasks to be executed. This is further implemented in the process and reflected in the model and review as the basis for software development.


Goal 2: the commitment between engineering teams is recognized by the teams involved in the project.

This goal should be explained by the organization using the Rational Unified Process. However, the Rational Unified Process visual model helps people understand the requirements of each stage of product development (from requirement acquisition to deployment. The Rational Unified Process Change and configuration management process ensures that the proposed changes are properly evaluated and the evaluation results are communicated to all stakeholders.

The Project Group determines, tracks, and solves inter-group problems. The Rational Unified Process iterative development process helps you discover software problems early by continuously integrating all developed software. To propose and solve problems between teams, problems arising from software integration developed by multiple teams can be used as a "public space ". The Rational Unified Process Detection and change request process supports this view, which provides a formal mechanism for capturing, tracking, and solving project development problems.

 


Classified Review

The purpose of the peer review is to eliminate the defects of software work products as soon as possible. An important result is to deepen the understanding of software work products and defects that can be prevented. Peer review is an important and effective engineering method proposed by software product engineering.


Objective-1: To plan level-1 review activities.

As described in Level 2 Quality Assurance goals, each activity within the Rational Unified Process has an independent review activity.

Because early problem detection can reduce the overall cost, rational uniied process advocates "early and frequent" Review of All artifacts, especially key artifacts. Rational Unified Process provides a list of important features for review in each phase and model.


Objective 2: identify and eliminate defects in software work products.

The rational uniied process job reviewer needs to determine whether the artifacts for the next development phase are ready. If the workpiece fails to meet the review "qualified" standard, according to the Rational Unified Process metric plan, you need to obtain the following details:

  • Stability (rework type, variability)
  • Adaptability (rework cost)
  • Module level (impact scope of rework)
  • Quality (defect discovery frequency, density, and inheritance depth)
  • Maturity (test time of each fault)
  • Resource Consumption configuration file (planned and actual)

 


References:

[Ref1] Mark C. paulk et al, "key practices of the Capability Maturity Model-Version 1.1", Software Engineering Institute-Carnegie Mellon University.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.