Small software enterprises implement cmme process improvement Cases

Document directory

•  

This article is intended for a small software organization A1 with 12 employees, 10 of whom are engaged in software development and 2 are engaged in management, marketing, sales and other affairs. A1 is divided into two departments: Production Department and R & D department. This organization belongs to a typical CMM Level 1 organization. It does not have obvious process support, but relies on elites without quality control and measurement data. A simple and feasible implementation process and model are proposed according to the cmme model, and simple and feasible operation steps are provided, which greatly reduces the process improvement pressure of enterprises and makes full use of part-time and full-time resources, it also provides "small software enterprise Process Improvement Support Environment (SSE-PISE)" Process Improvement Support software to support its process improvement.

I. tailoring process and principles

The purpose of the cmme tailoring process is not to re-compile the cmme, but to rebuild its documents, practices, reviews, resources, training and management based on the characteristics of small software enterprises, while maintaining the essence and structure of CMMs. Because the specific Improvement Directions of each software enterprise are different, the improvement strategies adopted are different, and the models used are different (continuous or segmented). This article does not explain how to crop KPA one by one, this is not easy to grasp the subject, and it is easy to fall into details. We discuss common practices and principles for document tailoring, management, review, resources, training, and so on.

1. document tailoring

The cmme process model contains a large number of documents, including policies, plans, procedures, standards, and reports. If you strictly follow the cmme practices, the limited resources of small software enterprises will be overwhelmed by the documents, and lost the mastery of the essence of improvement. Our strategy is to merge or expand documents, reduce the burden of generating documents, and leverage the "small software enterprise Process Improvement Support Environment (SSE-PISE) to quickly generate, distribute, merge, and manage documents. The main tailoring policies include:

Document Merging. Document merging is in line with the purpose of cmme, and cmme also defines non-formal plans as part of the formal plan. Project-level documents can be expanded as part of other project-level documents, and organization-level documents can be part of other organization-level documents, provided that documents are identifiable.

The access control mechanism of the information system can be fully utilized to achieve a greater degree of integration of documents. For example, each project has only one project-level document, such as a project plan. For different roles, you can only view the corresponding information segment and enter, modify, read, and forward the information within the permitted range.

For documents with strong relevance, especially simplified versions of other documents, the previous document is completely canceled or automatically generated by the information system.

Document Elimination. For documents not involved, they are completely deleted and do not need to be provided, but the measures should be explained in the project-level documents. Documents with redundant information are completely deleted. for documents with few valuable information, this document is deleted and the valuable information is merged into the most relevant documents.

Data item Extraction. For public information in different documents, the information system is used to extract from the public data source to ensure data correctness and consistency, while reducing the workload of re-input.

In the cases discussed in this article, we make full use of the multimedia documentation mechanism of Lotus R5, with only one organization-level document retained and only one project-level document retained for each project. For kPa such as Configuration Management (SCM), a configuration plan document is also restricted for each project. Of course, this system provides relevant mechanisms to ensure that multiple sub-accounts can be derived from the same document, printed and output, and are swollen? /P>

2. Manage tailoring

In CMMS, the task division is very fine and many roles are involved. However, for small software enterprises, there are not so many human resources to divide and undertake so many management tasks. For example, a senior manager in CMMS may be the company's general manager or CEO in a small software company, but it is impossible for him to perform many detailed tasks on his own. In addition, many roles in small organizations and small projects are actually repeated. For example, in small projects, task leaders, software managers, Project software managers, the roles of the Project Manager are repeated and do not need to be set separately. In view of the large gap between the management structure of CMMs and small software enterprises, it is necessary to tailor management activities and management roles. The main tailoring principles are as follows:

Analyze the KPA and management tasks, and combine the relevant Kpa that does not need to ensure independence, so as to allocate relevant management responsibilities to a single manager for management.

Unless you absolutely need the commitment of a senior manager, you generally do not set a senior manager as a management position.

To merge management tasks, you do not need to repeat the Manager positions. You can assign relevant responsibilities to the relevant technical or management personnel for implementation.

In the cases discussed in this article, we classify KPA to ensure the independence of the "process and product quality management" process domain. When other KPA is implemented, one person assumes multiple responsibilities, merge and delegate Rights and Responsibilities. Only one project manager and one SQA manager are set up for each project. The project manager is responsible for project planning, implementation, deployment and maintenance. The KPA manager is responsible for monitoring project implementation, arranging review, obtaining measurement and analysis data, and proposing improvement suggestions.

3. Review and tailoring

Many types of reviews are involved in cmme practices: management reviews, peer reviews, SQA audits/verifications/reviews, formal reviews, and technical reviews, almost all project-related key decisions and key documents and activities need to be reviewed to establish a public baseline. For small projects and enterprises, if all the review activities are implemented according to the cmme model, the time spent in the review will seriously affect the development time. Therefore, it is necessary to tailor the review activities. The main tailoring principles are as follows:

When appropriate, the merge comment guide 0 collects the merge MMI model. The senior management needs to participate in too many reviews. However, managers and specific implementers often work in one office, making communication very convenient, many review activities can be simplified, merged, or even canceled.

Practice has proved that the review frequency is closely related to whether the project is critical and the project duration. For example, in non-critical and short-term projects, the review frequency should not affect the project life cycle, and the corresponding management review, software risk review, and SQA Activity Review frequency should be reduced.

Informal review practices. Make full use of other meetings or meeting opportunities to address the review requirements.

SQA does not need to evaluate, audit, and review all products in a timely manner. Only spot checks should be conducted. The SQA Review has been proven to significantly increase the workload for small projects. The SQA spot check activities and work products should be clarified in the SQA plan. Examples of activities or work products that can be spot-checked for review:

(1) SQA review and audit of activities and work products in KPA;

(2) SCM audit on software baselines;

(3) evaluation of the SQA Plan and Activities of the subcontractor;

(4) Evaluation of the implementation of sub-contractors.

One major difference between a large project and a small project is that the working relationship between managers and employees is different in the status report aspect. In small projects, managers usually focus on the technical level. Therefore, it is unnecessary and inappropriate to implement a large-scale State report mechanism in small projects. To solve this problem, we need to streamline and merge many cmme review practices, especially the project follow-up reviews jointly with the Senior Project Management and SQA. In the cases discussed in this article, we only officially review key work products and milestones, and merge the remaining reviews, or conduct spot check reviews, or informal reviews to reduce the review workload, make full use of the advantages of convenient communication and close cooperation among small projects.

4. Resource pruning

The cmme model requires many roles to execute management and engineering tasks. However, in small organizations and small projects, there are not so many people who can fully execute the roles required by cmme. In reality, engineers and managers may execute multiple roles at the same time, or even across multiple projects. For example, a project manager may manage multiple projects and may simultaneously engage in management and technical work. SQA personnel may be from other projects, or from other organizations and companies. SQA and SCM personnel may be responsible for multiple projects at the same time, and individuals may be involved in multiple engineering subjects. At the same time, for small projects, it is unrealistic to implement full-time personnel such as SQA, SCM, training and SEPG. Generally, such a team usually includes multiple part-time employees and one full-time employee.

In small projects, personnel are not the only restricted resource. The tool resources mentioned in the "execution capability" section in each KPA usually refer to automated tools. In small projects or small organizations, many automated tools are expensive and not suitable. For immature software processes, large CASE automation tools are usually not effectively used. In order to solve the limited resources problem in small software organizations and small projects, we need to tailoring the CMMs. The main tailoring policies are as follows:

An individual can execute multiple roles in a project or organization, acknowledge part-time roles and responsibilities, and use resources outside the Organization.

Extends the concept of a group to include part-time employees.

Select appropriate automation tools based on project and process maturity. Basic automation tools and manpower should be integrated in small projects.

In the cases discussed in this article, we need to classify resources not only by human resources, automated tools, but also by further refining, for example, human resources are classified based on the professional direction, leadership, and communication skills, and a simple classification and evaluation method is proposed. The resource and group concepts of CMMs are extended, it is no longer limited to the concept of a department, so that it can accommodate a variety of full-time and part-time staff, and there is no size or position restrictions. Propose different recommendation tools for different KPA based on projects or organizations of different maturity, especially "small software enterprise Process Improvement Support Environment (SSE-PISE)" that can provide interfaces to these tools, improve the efficiency of automated tools.

5. Training tailoring

The common features of the cmme model KPA "execution capability" include many different types of training needs, including management and technical aspects. Because training is very resource-consuming and costly, small organizations usually employ people who have been trained or have relevant knowledge. The training process KPA of cmme allows the training to be abandoned, but most enterprises still insist that training for all employees is essential if they do not recognize this problem. The cmme must be tailored to clarify this misunderstanding. The main tailoring principles are as follows:

Employees with corresponding practical experience or similar field training history can be exempted from training.

Training can be used as an extension of previous training and can be combined with training for related activities.

Training practices can be expanded to eliminate unnecessary internal training and receive training from external resources or methods.

In the cases we discussed, we attached great importance to the relevant training records and human resources training skills and training history, and decided on whether to use the training exemption mechanism. If this mechanism is used, the signature of the client must be ensured. We tailored multiple training practices to combine or expand training needs. For example, the training of peer reviewers can be combined with the training of peer reviewers. Some high-level maturity KPA activities are extended for low-level maturity activities. Therefore, training that supports High-Level maturity activities is extended for training that supports low-level maturity activities, for example, project management training for integrated software management KPA.

6. Practices unrelated to Cropping

Cmme is intended for large software enterprises. Many of the practices are irrelevant to small enterprises. In particular, many process practices are not suitable for small projects, implementation of these processes in small projects will cost more than the project itself, and due to the short timeliness of some projects, re-planning or adjustment activities become meaningless.

In KPA, such as organization process focus, organization process definition, integrated software management, and quantitative process management, many process practices involve creating and maintaining the defined process of a project. However, in an organization with only one project, the project process is exactly the same as the organizational process. If a project has similar characteristics (such as domain knowledge, scale, and development cycle), a process may be used for all small projects. This process is a standard process for small projects. In any case, practices that tailor the Organization's standard software process as a project-defined process and integrate changes to the organization's defined process are not appropriate. At the same time, for those projects with short development time, there is no time to implement project re-planning, risk planning, process adjustment and other activities, these practices are useless for such projects.

Ii. Summary

80% of software enterprises in China are small-sized enterprises with a staff size of less than 15 [10], while cmme is a process improvement model for large software enterprises, how can small enterprises and projects make full use of the process improvement advantages of the cmme model and obtain the relevant cmme certification? The author participates in a software process improvement project for a small enterprise with only 12 employees. This article is based on the summary of this project.

This article first analyzes the process improvement requirements of small software enterprises from three aspects: organizational structure, software process improvement model, and market requirements of small organizations. Then, we analyze why the content of CMMs is not suitable for small enterprises and projects, and give a general introduction to how to make adjustments and improvements in documents, management, review, resources, and training, it is suitable for small businesses and projects.

Reference http://www.uml.org.cn/cmm/200809023.asp