Reasonable software processes are the basis of software quality-disadvantages of CMM/cmme

CMM/cmme is considered to be the most mature and effective method and standard for improving the software engineering level. It is used to evaluate and improve the process, it is a framework that describes the key factors to be improved in the software development process. It describes a way to improve in a progressive manner. It provides a foundation for software process improvement and changes software development from a relatively casual and immature process to a very mature, regular, and manageable process.

 

However, CMM/cmme also has some inherent shortcomings that cannot be ignored. For example, the evaluation of CMM/cmme is expensive, and a Level 2 Evaluation of CMMs may reach millions, which takes a long time and is complex, which often leads to unsatisfactory results. The authentication of many enterprises is in the form. After the evaluation is complete, only a lot of documents are left, while the real software development process remains the same. In addition, CMM/cmme only tells us how to do it, instead of how to do it. For example, how can we manage requirements that must be improved? No answers are provided for CMM/cmme.

 

The most important thing is that many software companies have fallen into a misunderstanding that only using CMM/cmme evaluation can solve the problem of low software quality, while ignoring the software process, which truly improves the software quality. In fact, it is entirely possible that the software developed by an enterprise with a maturity of level 1 or Level 2 CMM is truly useful, some enterprises cannot guarantee the software they deliver even if they have passed the CMM Level 5 certification. The worst case is that, if a poor software process is adopted, the higher the maturity level through CMM/cmme will only make the software enterprise more efficient in producing bad software, instead of enabling enterprises to develop better software.

 

Ivar jacbson believes that a good software process must first be based on components. On this basis, it must also meet the three best practices: iterative development, case-driven development, and architecture-centered.

Reasonable software process is the foundation of software quality

Why is that? Ivar Jacob gave a very vivid example. This is the story of a farmer and his cows. On the way for cows to drink water (called Ox Road), there is a piece of land where cows will eat a lot of crops. After seeing this situation, the farmer realized that he had to improve the process of drinking water from the cows, so he put asphalt on the road. As a result, the farmer got a good "Ox Road" and the Ox went faster, but it did not really solve the problem of cattle eating crops. It should have a better way, that is, to find a brand new way for the ox to drink water.

 

 

Software enterprises use the CMM framework to control software quality, just like the farmer paving asphalt for niulu. For software enterprises, if you start from a wrong software process, even if you make improvements on it, what you get will always be "niu Lu ". Here, we should consider a better way, that is, from the very beginning, we should adopt the process of developing good software. Then, based on the software process, measure the software and improve the software process, that is, to improve the CMM/cmme requirements.

 

Dr. Ivar jacbson believes that improving from a poor software process will actually make software development worse, because you have solidified the software development process, it makes it more difficult to modify it later. The correct method is to first have a good software process, which is not easy, but worth doing. "It is very easy to make a good software process measurable, but it is difficult to turn a measurable software process into a good software process," said Ivar Jacob ". That is to say, it is helpful to make the process of developing a good software measurable. However, it is almost impossible to turn a measurable process that has been improved by CMMI into a process that can truly develop good software.

 

So what is a good software process? Ivar jacbson recommends that you identify from the following aspects: first, the bad process focuses on the document, while the good process focuses on the executable program or system. Second, the bad process delays the time to expose risks, and the good process exposes itself to risks at the beginning and solves them in a timely manner. Third, the bad process can verify the quality of the project at the end of the project, and the quality of the good process can be verified every moment. Fourth, A bad process has a very complex trace relationship matrix, which requires a very complex matrix from requirement to code, while a good process is a seamless link. Fifth, in the face of changes, bad software is very fragile, and good software will be very robust.

 

Ivar jacbson reminds software developers to be smart farmers to get a correct software process first, and then consider measuring and defining it. Because the essence of software project management is not to describe and measure the software process and process, but to focus on the software and whether you can develop qualified software. The key is to get the result. The result is obtained through the software process, that is, the delivered software product.

Agile development attempts to end the software crisis(But it is also difficult. Agile development is suitable for small teams and not for large projects, military projects, and ,...)