Maturity model software

The necessary process discipline is in place to repeat earlier successes on projects with similar applications. The software process for both management and engineering activities is documented, standardized, and integrated into all processes for the organization.

Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. A big difference however is that CMMI offers two representations of the maturity of the processes.

CMMI offers a staged representation with five maturity levels just like the Software CMM and a continuous model where each process area has its own maturity level. An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating 1 to 5 or a capability level achievement profile. I think that this measurement also includes how well a piece of software has adapted to keep up with its market, as its market is changing.

Over time tools tend to become more and more effective. So if we measure ASP. NET WebForms clearly has an advantage when it comes to time on market, but how does it stack up when we start looking at defect numbers?

Well, the release early and often approach that the ASP. NET WebForms. NET MVC has had 6 preview releases, a beta, a release candidate, and a release candidate refresh, all the while the source code was completely available to the public.

People have been running production sites on this code for almost a year now. NET has really only had two major releases with some service packs in between. As I said earlier ASP. NET MVC has already had 9 public releases with significant changes during each release that were in direct response to customer feedback!

It is not a software process model. It is a framework that is used to analyze the approach and techniques followed by any organization to develop software products. It also provides guidelines to further enhance the maturity of the process used to develop those software products. It is based on profound feedback and development practices adopted by the most successful organizations worldwide. This model describes a strategy for software process improvement that should be followed by moving through 5 different levels.

Each level of maturity shows a process capability level. It only helps if it is put into place early in the software development process. It has no formal theoretical basis and in fact is based on the experience of very knowledgeable people. For this to work well, this needs to a collaborative open conversation.

This shouldn't be done in isolation. Personal bias should be removed as much as possible. I would also recommend when you have arrived at a specific level for a specific section you document why. This makes for a really useful reference when you review again in the future.

If you have multiple software development teams in your organisation, you might want to collaborate between to produce a consistent benchmarking. Also a great way of sharing good practice between teams. From the assessment, you may then build up an action plan to improve one or more sections. If you do, I would recommend being very focused. Look at one section and build a plan to move that to the next level. Be realistic in your planning. If you are a Level -1 for all sections, you cannot expect to get them all to Level 3 with weeks.

In most cases you will be looking at months or even years dependant on your software size and complexity.