Analysis of technical problems in the implementation of CMM "six-step-curved"--cmm

For most of the domestic software enterprises, the implementation of CMM is still in the initial stage, ready to implement the CMM2 level of the majority of enterprises, therefore, the analysis of CMM2 level implementation of the problem, will help these enterprises find suitable for the implementation of the enterprise as soon as possible.

What are the reasons why some companies that are implementing the CMM2 level have found a lot of repetitive work to do? Lack of good demand development is the main reason for this problem!

1 demand management and demand engineering

Demand development and demand management are two parts of demand engineering, if the need development is not good, then the duplication of work will appear from the point of view of demand management. The main reasons leading to poor demand development are the following:

Lack of good requirement specification writing template

Analyze some enterprise's CMM implementation process, on the face of it, they do follow the basic selection principle of the first recommendation, but because of the lack of experience, the actual selected program often lacks objectivity, while in the enterprise's engineering and management mechanism and lack of practical feedback methods and processes to continuously improve the original plan. Generally speaking, we work together for a long time, will form a "tacit understanding", and this is likely to the future of engineering and management work buried a lot of hidden dangers, once there is disagreement, this tacit understanding will no longer exist. If you do what the CMM requires, a lot of similar repetitive work will happen. One of the ways to improve is to maintain consistency in documentation and products throughout the engineering and management process, to reverse track the extent of requirements specification changes, and to continually improve requirements specification writing templates.

More serious neglect of non-functional requirements

At present, the domestic software customers rarely actively put forward non-functional requirements, but with the gradual maturity of customers, software customers on the non-functional requirements of software will become more and more high, this software developers put forward higher requirements. The preparation of specifications that do not do non-functional requirements will also be surrounded by a lot of repetitive work.

Lack of specifications for non-functional requirements will cause some basic problems to be discovered in the middle of the software life, which can lead to a large number of documents and products that need to be changed, leading to serious engineering and management challenges. One of the ways to improve is to invoke senior personnel with considerable software debugging and maintenance backgrounds to participate in the preparation of requirements specification, and their rich experience can often better compensate for the deficiencies of design developers in this area.

Lack of configuration management for requirements documents

It's a good idea to write a template with two requirements specifications: one for the software customer, one for the software development team, whose goal is to make it easier for customers to understand and more specialized. In this case, the two requirements specification should be included in the configuration management context to maintain its consistency from a management perspective. This is not enough, from the engineering point of view, enterprises should also form a set of transformation from the former to the latter rule. Although the form of these two templates may be natural language, a rule as rigorous as possible will greatly reduce the space for human freedom in the process of transformation. It should be noted that the establishment of this set of rules should start from a project, starting from the foundation, gradually improve. For example, first determine the basic nouns and verb sets for the project, and specify the rules for writing statements.

Requirements Specification lack of testability

Why do you simply pick out the testability in the few features that need to be explained? In the writing stage of the requirement specification, subjectivity has a greater influence on other characteristics, while an independent and experienced test group's mastery of Testability is based on a test document independent of the requirements specification. From the test point of view, many requirements are not measurable, which requires rewriting these requirements, until the testability is guaranteed. The test group often requires a concise and accurate description, which is one of the few aspects that developers do well enough; On the other hand, the current domestic market or enterprises, the testers are not enough attention, software companies rarely recruit testers. In fact, excellent software testers are very important to ensure the quality of the software, in general, the test department managers should be with software development experience, have done software development management and have considerable testing experience of senior staff. To deal with the relationship between the design and testers is a problem that many domestic software enterprises should pay more attention to.

Lack of a better specification for requirements Specification conversion

The purpose of the requirements Specification transformation is to translate the requirement statement written in natural language into a more accurate intermediate form, which is also called "Software Modeling". In general, modeling enables some aspects of the requirements specification to be more formalized and enables the design to maintain requirements inheritance more clearly. Usually, do not do requirements specification conversion or lack of better requirements Specification conversion specification, will result in varying degrees of demand description lost, thereby increasing the difficulty of follow-up management work.

The fundamental purpose of demand management is to establish a baseline for subsequent engineering and management and to maintain consistency between related and derivative documents and products and requirements, so the quality of requirements engineering is greatly affected by the workload of the implementation of requirements management.