An ideal reference model in which the main ones are presented. Reference model of the competencies of a pedagogical worker. See what the "Reference Model" is in other dictionaries

The reference model architecture artificially includes two dimensions:

process measurement, which characterizes the results of the process, which are significant measurable goals of the process;

process capability measurement, which characterizes a set of process attributes that are applicable to any process and are measurable characteristics that are necessary to control the process and improve its ability to perform.

The reference model groups processes, when measuring a process, into three process groups. life cycle, which contain five categories of process, according to the type of activity to which it is addressed.

Initial life cycle processes consist of categories of processes supplier - customer and engineering.

Process category supplier - customer consists of processes that are directly affected by the customer, the development of support and software transition to the customer, and provide for the correct functioning and use software product and/or services.

Engineering process category consists of the processes that directly define, implement, or support the software product, its relation to the system, and its consumer (customer) documentation.

Supporting life cycle processes consist of support process categories.

Organizational life cycle processes consist of categories of management and organization processes.

Control process category consists of processes that contain general methods that can be used by anyone who manages any type of project or process within the software life cycle.

Organization process category consists of the processes that set the organization's business goals and develop (develop) the process, product and active resources that, when used by projects in the organization, will help the organization achieve its business goals.

Process Categories and Processes provide a grouping of activity types. Each process in the reference model is described in terms of a goal statement. These claims include the unique functional goals of the process that are validated in a specific environment. The goal statement includes additional material that defines the outcomes of successful implementation of the process. Meeting the purpose of a process represents the first step in building process capability.

The reference model does not specify how, or in what order, the elements of the process goal statements are to be achieved. The process objectives will be achieved in the organization through various lower level activities, tasks and practices performed to produce a work product. These tasks, activities, and practices performed, as well as the characteristics of the work products produced, are indicators that demonstrate whether the goal of a particular process has been achieved.

Process capability development is characterized in terms of process attributes grouped into capability levels. Process attributes are attributes of a process that can be assessed on an achievement scale, providing a measure of the capability of a process. Attributes apply to all processes. Each process attribute describes an aspect of the overall ability to manage and improve the effectiveness of the process in achieving its goals and contributing to the business goals of the organization.

A feature level is characterized by a set of attributes that work together. Each level provides a major extension of the ability to execute a process. Levels constitute a rational way of development through the improvement of the possibility of any process.

There are six capability levels in the reference model.

Level 0: Unfinished. General failure to achieve the goal of the process. There are not easily identified work products or process outputs.

Level 1: Executable. The goal of the process, in general, is achieved. Achievement cannot be strictly planned and tracked. The organization's personnel recognize that the process must be performed and there is general agreement that the process is performed as required and when required. There are certain work products of the process, and they testify in favor of achieving the goal.

Level 2: Managed. The process produces work products according to certain procedures, is planned and monitored. Work products meet specific standards and requirements. The main difference from Executable level in that the execution of the process now produces work products that fully meet the quality requirements within a certain period of time and an allocated resource.

Level 3: Installed. The process is executed and controlled using a defined process based on good software engineering principles. Individual process implementations use documenting processes, approved, customized versions of the standard, in achieving specific process outcomes. The resources needed to establish a process definition are also in place. The main difference from managed level that the process Set level uses a specific process that is able to achieve its outputs.

Level 4: Predictable. A certain process, in practice, is consistently performed within certain limits and achieves certain goals. Detailed process steps are collected and analyzed. This leads to a quantitative understanding of process capability and an improved ability to predict performance. The execution of the process is objectively controlled. The quality of work products is quantitatively known. The main difference from Set level in that a certain process is now executed sequentially within certain limits in order to achieve its certain outputs.

Level 5: Optimizing. Process execution is optimized to meet current and future business needs. The process achieves repeatability when certain business goals are achieved. Quantified process performance and performance targets for performance are established based on the organization's business objectives. A continuous process monitoring these goals allows for quantitative feedback and improvement is achieved by reviewing the results. The main difference from predictable level in that defined and standard processes are now dynamically changing and adapting to effectively achieve current (actual) and future business goals.

Naturally, the reference model cannot be used as a basis for making reliable and consistent process capability assessments, as the level of detail is not sufficient. Descriptions of the process goal and capability attributes in the reference model need to be supported by a comprehensive set of process performance and capability indicators. In this way, a consistent process capability rating will be possible.

Process measurement

This subsection provides a classification of the processes adopted by organizations involved in the development, operation, acquisition, delivery and maintenance of software. The classification recognizes five categories of processes that contain all processes. The categories and their processes are comparable to those defined in draft ISO/IEC 12207, Information technology - Software process life cycle, discussed in Section 2.

As noted above, in the reference model, processes are grouped into three groups and five categories of processes:

initial life cycle processes include categories of engineering process and supplier - customer;

supporting life cycle processes include support process categories;

organizational life cycle processes include the categories of process management and organization.

Individual processes are described in terms of six components.

Process ID. Identifies a category and a sequence number within that category. The numbering scheme differs between top-level processes and second-level processes. The identifier consists of two parts: a category abbreviation (for example, ENG for the engineering process category) and a number (for example, CUS. 1 indicates the Acquisition Process and CUS. 1.2 indicates the second level process, the Supplier Selection Process, which is a component process of the Acquisition Process ).

Process name. A descriptive phrase that highlights a fundamental property of a process (for example, Supplier Selection).

Process type. There are 3 types of top-level processes (basic, extended, new) and 2 second-level processes (component, extended), which are related to ISO/IEC 12207 processes as follows. The new processes are in addition to those defined in ISO/IEC 12207. processes are identical in purpose to ISO/IEC 12207 processes. Extended processes are augmented on an existing ISO/IEC 12207 process. Component processes group one or more ISO/IEC 12207 activities from the same process. Extended component processes group one or more ISO/IEC 12207 activities from the same process and include additional material.

Purpose of the process. Material that specifies the purpose of the process, setting the overall goals for the execution of the process at the top level. Optional additional material may be included to further define the goal statement.

Process results. List of process result descriptions.

Process notes. An optional list of informative notes about the process and its relationship to other processes.

For example, here are a few processes from each process category.

CUS.1 Acquisition Process

Basic process

Target Acquisition Process is to obtain a product and / or service that satisfies the need expressed by the customer (client). The process begins with the definition of the customer's need and desired results, with acceptance of the product and/or service required by the customer. As a result of the successful implementation of the process:

A contract will be developed that clearly expresses the expectations, duties and obligations of both the customer and the supplier;

A product and / or service will be produced that will satisfy the identified need of the customer;

The acquisition will be verified so that certain constraints such as cost, plan and quality are met.

CUS.1.1 Acquisition Preparation Process

Component Process CUS.1 - Acquisition Process

Target Acquisition Preparation Process is to establish the needs and objectives of the acquisition. As a result of the successful implementation of the process:

The need to acquire, develop, or expand a system, software product, or software development process will be identified;

System requirements will be formulated;

An acquisition strategy will be developed;

Acceptance criteria will be defined.

ENG.1 Development Process

Basic process

Target development process is to transform an agreed set of requirements into a functional software product or software system that satisfies the stated needs of the customer. As a result of the successful implementation of the process:

A software product or software system will be developed;

Intermediate work products will be developed, which shows that the final product is based on agreed requirements;

Consistency between software requirements and software designs will be established;

The test data will show that the final product meets the agreed requirements;

The final product will be installed in the target environment and accepted by the customers.

NOTE: Agreed requirements may be provided by an Acquisition Process (CUS. 1) or Requirements Establishment Process (CUS. 3) operation.

ENG.1.1 System Requirements Development and Analysis Process

Component Process ENG.1 - Development Process

The purpose of the System Requirements Design and Analysis Process is to establish the system requirements (functional and non-functional) and architecture, identifying which system requirements should be allocated to which elements of the system and in which version. As a result of the successful implementation of the process:

System requirements will be developed, which corresponds to the established needs of the customer;

A solution will be proposed identifying the main elements of the system;

The agreed requirements will be allocated to each of the main elements of the system;

A release strategy will be developed to prioritize meeting system requirements;

System requirements will be approved and modified as required;

The requirements, the proposed solution and their links will be communicated to all interested parties.

SUP.1 Documentation Process

Advanced Process

Target Document Development Process is to develop and maintain documents that record the information generated by a process or activity. As a result of the successful implementation of the process:

A strategy will be developed identifying the documents that will be produced during the life cycle of the software product;

The standards to be consulted for the development of documents will be defined;

All documents to be produced by the process or project will be identified;

All documents will be developed and published in accordance with certain standards;

All documents will be maintained in accordance with certain criteria.

NOTE - The process supports the execution of process attribute 2.2 in the examples where it is introduced.

MAN.1.1 Project Management Process

Component Process MAN.1 - Management Process

Target Project Management Process is to identify, establish, coordinate, and control the activities, tasks, and resources necessary for a project to create a product and/or service to meet agreed requirements. As a result of the successful implementation of the process:

The scope of the project will be defined;

The feasibility of achieving project objectives with available resources and constraints will be assessed;

The tasks and resources required to complete the work will be measured and evaluated;

Interfaces between project elements and other projects and organizational units will be identified and tested;

Project implementation plans will be developed and implemented;

The progress of the project will be checked and reported;

Actions to correct deviations from the plan and prevent recurrence of problems identified in the project will be taken when the project objectives are not achieved.

NOTE This process supports the execution of process attribute 2.1 in the examples where it is introduced.

ORG.2 Improvement Process

Basic Process

The Improvement Process is a process for establishing, evaluating, measuring, managing and improving the software life cycle process. As a result of the successful implementation of this process:

A set of organizational process assets will be developed and made available;

The organization's process capability will be periodically assessed to determine the extent to which the implementation of the process is effective in achieving the organization's objectives;

Measuring Opportunity

The reference model capability dimension defines the measurement scale for evaluating the process capability of any process. The capability of a process is defined on a six-point ordinal scale that allows one to rate capability from the bottom of the scale, the unfinished level, to the top end of the scale, the optimizing level. The scale defines the improvement in the capability of an ongoing process from efficiency that is incapable of delivering specific results up to efficiency that is capable of meeting the business goal and supporting continuous process improvement. Therefore, the scale defines a clear path for improvement for each individual process.

Within the capability model, the capability measure is based on a set of nine process attributes (PAs) (see Table 4.1). Process attributes are used to determine whether a process has reached a given capability. Each attribute measures a specific aspect of process capability. The attributes are themselves measured on a percentage scale and therefore provide a more detailed understanding of the specific aspects of the process capability required to support process improvement and capability determination.

For example, let's take one of the attributes of the third level of capability.

AP 3.1 Attribute Definition and Process Transformation

To what extent a process is executed as a converted instance of a standard process definition. Standard Process meets the defined business objectives of the organization. The transformation is performed to suit the specific purposes of the process instance. As a result of fully reaching this attribute:

Process documentation, together with appropriate guidance on customizing standard process documentation, will be determined that is capable of providing the normal process scope and functional and non-functional requirements for the work product;

The execution of the process will be carried out in accordance with the selected and/or adapted standard process documentation;

Historical process execution data will be collected, firstly, to establish and improve understanding of process behavior, secondly, to assess process execution resource needs;

Experiences from the use of process documentation will be used to improve the standard process.

Table 4.1.

Number	Name
Level 1	Running process
AP 1.1	Process execution attribute
Level 2	Managed Process
AP 2.1	Execution control attribute
AP 2.2	Work Product Management Attribute
Level 3	Established process
AP 3.1	Process definition and transformation attribute
AP 3.2	Process resource attribute
Level 4	predictable process
AP 4.1	Process dimension attribute
AP 4.2	Process control attribute
Level 5	Optimizing Process
AP 5.1	Process change (verification) attribute
AP 5.2	Improvement Opportunity Attribute

A process attribute represents a measurable characteristic of any process, as defined above.

N Not reached:

0% - 15% - There is little or no confirmation of achievement of a particular attribute.

P Partially reached:

16% - 50% - there is evidence of a reliable systematic method to achieve a certain attribute. Some aspects of achievement can be unpredictable.

L Largely achieved:

51% - 85% - there is evidence of a reliable systematic method to a significant achievement of a certain attribute. Process execution may vary in some areas.

F Fully reached:

86% - 100% - there is confirmation of a complete and systematic method to the complete achievement of a certain attribute. No significant deficiencies exist within a particular part of the organization.

Each process attribute assessed in any part of the organization, including the highest capability level defined in the scope of assessment, must be consistent with a rating using the attribute scale defined above. The set of attribute ratings for a process forms a profile for that process. The evaluation output includes a set of profiles for all evaluated processes.

The identifier used must provide objective evidence of use in order to determine the rating to be retrieved. Ratings may be presented in any format, such as matrices or as part of a database, provided that the presentation allows the identification of individual ratings according to this reference scheme.

The capability level achieved by a process shall be derived from the attribute rating for that process, according to the process capability level model defined in Table 4.2. The purpose of this requirement is to ensure that values are consistent when a process capability level is referenced for a process.

The tables below provide summary lists of the processes that are included in the reference model (table 4.3) and the correspondence between the processes of the reference model and the processes defined in draft ISO/IEC 12207 (table 4.4).

Table 4.2

Scale	Process attributes	Grade
Level 1	Process execution	Mainly or completely
Level 2	Process execution Execution control Work Product Management	Fully Mainly or completely Mainly or completely
Level 3	Process execution Execution control Work Product Management Process resource	Fully Fully Fully Mainly or completely Mainly or completely
Level 4	Process execution Execution control Work Product Management Process definition and transformation Process resource Process measurement Process control	Fully Fully Fully Fully Fully Mainly or completely Mainly or completely
Level 5	Process execution Execution control Work Product Management Process definition and transformation Process resource Process measurement Process control Process change Possibility of further improvement	Fully Fully Fully Fully Fully Fully Fully Mainly or completely Mainly or completely

Table 4.3.

			Process
Number	Name	Number			Name


				Acquisition (basic)
				Acquisition preparation (component)
				Vendor selection (component)
				Vendor Check (Component)
				Customer approval (component)
				Support (Basic)
				Requirements setting (new)
				Operation (advanced)
				Functional Usage (Advanced Component)
				User Support (Advanced Component)

				Development (basic)
				Analysis and development of system requirements (component)
				Software requirements analysis (component)
				Software development (component)
				Software design (component)
				Software integration (component)
				Software testing (component)
				System testing and integration (component)
				Operation of the system and software (basic)
Supporting life cycle processes

				Documentation (advanced)
				Configuration management (basic)
				Quality assurance (basic)
				Verification (basic)
				Validation (Basic)
				Joint review (baseline)
				Check (basic)
				Problem solving (basic)
				Measurement (new)
				Reusable (new)


				Management (basic)
				Project management (component)
				Quality management (new)
				Risk management (new)

				Organizational alignment (new)
				Improvement process (basic)
				Create a process (component)
				Process assessment (component)
				Process improvement (component)
				Human Resource Management (advanced)
				Infrastructure (basic)

Table 4.4.

Activities and processes 12207

Processes 15504

Initial life cycle processes

Acquisition process

basic

Initialization

Acquisition preparation process

Component

Preparing a Bid-for-Proposal [-bid]

Supplier selection process

Component

Contract preparation and adjustment

Supplier selection process

Component

Vendor verification

Vendor Verification Process

component

Acceptance and completion

Customer approval process

component

Delivery process

basic

Initialization

Delivery process

basic

Preparing a response

Delivery process

basic

Contract

Delivery process

basic

Planning

Delivery process

basic

Execution and management

Delivery process

basic

Review and evaluation

Delivery process

basic

Delivery and completion

Delivery process

basic

Requirements setting process

Development process

basic

Process Implementation

Development process

basic

Analysis of system requirements

component

System architecture development

System requirements development and analysis process

component

Analysis of software requirements

Software requirements analysis process

component

Software architecture development

Software development process

component

Working draft software

Software development process

component

Software coding and testing

Software Design Process

component

Software integration

Software integration process

component

Software qualification testing

Software testing process

component

System integration

component

System Qualification Testing

System testing and integration process

component

Software installation

Delivery process

basic

Software support

Delivery process

basic

Functioning process

basic

Process Implementation

Functional use process

extended component

Functional testing

Functional use process

extended component

System operation

Functional use process

extended component

User support

User support process

extended component

Operating process

basic

Process Implementation

Software and system operation process

basic

Analysis of problems and modifications

Software and system operation process

basic

Implementation of the modification

Software and system operation process

basic

Commissioning

Software and system operation process

basic

Migration

Software and system operation process

basic

Software recycling

Software and system operation process

basic

Supporting lifecycle processes

Documentation process

extended

Process Implementation

Documentation process

extended

Design and development

Documentation process

extended

Products

Documentation process

extended

Exploitation

Documentation process

extended