CMMI Level

[shilpa_teach]

Hi all
I m new to this forum.Let mr post my 1st thread..

What s CMMI?Is there any diff b/n CMM and CMMI?

[kiran2710]

Hi,


Welcome 2 SKNet...


============================================



Capability Maturity Model (CMM) broadly refers to a process improvement approach that is based on a process model. CMM also refers specifically to the first such model, developed by the Software Engineering Institute (SEI) in the mid-1980s, as well as the family of process models that followed. A process model is a structured collection of practices that describe the characteristics of effective processes; the practices included are those proven by experience to be effective. ^[1]
The Capability Maturity Model can be used to assess an organization against a scale of five process maturity levels. Each level ranks the organization according to its standardization of processes in the subject area being assessed. The subject areas can be as diverse as software engineering, systems engineering, project management, risk management, system acquisition, information technology (IT) services and personnel management.
CMM was developed by the SEI at Carnegie Mellon University in Pittsburgh. It has been used extensively for avionics software and government projects, in North America, Europe, Asia, Australia, South America, and Africa. Currently, some government departments require software development contract organization to achieve and operate at a level 3 standard.



Maturity model

The Capability Maturity Model (CMM) is a way to develop and refine an organization's processes. The first CMM was for the purpose of developing and refining software development processes. A maturity model is a structured collection of elements that describe characteristics of effective processes. A maturity model provides:

• a place to start
• the benefit of a community’s prior experiences
• a common language and a shared vision
• a framework for prioritizing actions
• a way to define what improvement means for your organization

A maturity model can be used as a benchmark for assessing different organizations for equivalent comparison. It describes the maturity of the company based upon the project the company is dealing with and the clients.

Structure of CMM

Maturity Levels. A layered framework providing a progression to the discipline needed to engage in continuous improvement (It is important to state here that an organization develops the ability to assess the impact of a new practice, technology, or tool on their activity. Hence it is not a matter of adopting these, rather it is a matter of determining how innovative efforts influence existing practices. This really empowers projects, teams, and organizations by giving them the foundation to support reasoned choice.)
Key Process Areas Key process area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
Goals The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
Common Features Common features include practices that implement and institutionalize a key process area. These five types of common features include: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
Key Practices The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the key process areas.

Levels of the CMM

There are five levels of the CMM. According to the SEI,

"Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."

Level 1 - Initial

At maturity level 1, processes are usually ad hoc and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects.
Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes again.
Level 1 software project success depends on having high quality people.

Level 2 - Repeatable

At maturity level 2, software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.
Process discipline helps ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.
Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).
Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimates.

Level 3 - Defined

The organization’s set of standard processes, which is the basis for level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by the organization’s set of standard processes according to tailoring guidelines.
The organization’s management establishes process objectives based on the organization’s set of standard processes and ensures that these objectives are appropriately addressed.
A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit.

Level 4 - Managed

Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Organizations at this level set quantitative quality goals for both software process and software maintenance.
Subprocesses are selected that significantly contribute to overall process performance. These selected subprocesses are controlled using statistical and other quantitative techniques.
A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.

Level 5 - Optimizing

Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization’s set of standard processes are targets of measurable improvement activities.
Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified, evaluated, and deployed.
Optimizing processes that are nimble, adaptable and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organization’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning.
A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives. At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process-improvement objectives.



Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes. ^[1] The latest version of CMMI ver 1.2 was released in August 2006. There are 3 constellations of CMMI in the new version, namely:- CMMI Development, CMMI Services and CMMI Acquisition.
CMMI for Development Ver 1.2 consists of 22 process areas with Capability or Maturity levels. CMMI is created by the Software Engineering Institute (SEI) and is available for download from the SEI.
CMMI should be adapted to each individual company, therefore companies are not "certified." A company is appraised (e.g. with an appraisal method like SCAMPI) at a certain level of CMMI. The results of such an appraisal can be published if released by the appraised organization.

Process Areas

The CMMI contains 25 process areas:

CMMI Causal Analysis and Resolution CMMI Configuration Management CMMI Decision Analysis and Resolution CMMI Integrated Project Management CMMI Integrated Supplier Management CMMI Integrated Teaming CMMI Measurement and Analysis CMMI Organizational Environment for Integration CMMI Organizational Innovation and Deployment CMMI Organizational Process Definition CMMI Organizational Process Focus CMMI Organizational Process Performance CMMI Organizational Training

CMMI Product Integration CMMI Project Monitoring and Control CMMI Project Planning CMMI Process and Product Quality Assurance CMMI Quantitative Project Management CMMI Requirements Development CMMI Requirements Management CMMI Risk Management CMMI Supplier Agreement Management CMMI Technical Solution CMMI Validation CMMI Verification

[kiran2710]

CMMI concept definition list

Concept Definition (source)

CAPABILITY LEVEL : CAPABILITY LEVELS, which belong to the continuous representation, apply to an organization’s process-improvement achievement for each process area. There are six capability levels, numbered 0 through 5. Each capability level corresponds to a generic goal and a set of generic and specific practices

CMMI MODEL : Since the CMMI Framework can generate different models based on the needs of the organization using it, there are multiple CMMI models. Consequently, the phrase “CMMI MODEL” could be any one of many collections of information. The phrase “CMMI models” refers to one, some, or the entire collection of possible models that can be generated from the CMMI Framework

CONTINUOUS REPRESENTATION : The CONTINUOUS REPRESENTATION uses capability levels to measure process improvement.

DISCIPLINE AMPLIFICATION : Model components that provide guidance for interpreting model information for specific disciplines (e.g., systems engineering, or software engineering) are called “DISCIPLINE AMPLIFICATIONS.” Discipline amplifications are added to other model components where necessary. These are easy to locate because they appear on the right side of the page and have a title indicating the discipline that they address (for example, “For Software Engineering”).

GENERIC GOAL : GENERIC GOALS are called “generic” because the same goal statement appears in multiple process areas. In the staged representation, each process area has only one generic goal. Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area, thus indicating whether these processes are likely to be effective, repeatable, and lasting. Generic goals are required model components and are used in appraisals to determine whether a process area is satisfied.

GENERIC PRACTICE : GENERIC PRACTICES provide institutionalization to ensure that the processes associated with the process area will be effective, repeatable, and lasting. Generic practices are categorized by generic goals and common features and are expected components in CMMI models. (Only the generic practice title, statement, and elaborations appear in the process areas.)

GENERIC PRACTICE ELABORATIONS : After the specific practices, the generic practice titles and statements appear that apply to the process area. After each generic practice statement, an elaboration may appear in plain text with the heading “Elaboration.” The GENERIC PRACTICE ELABORATION provides information about how the generic practice should be interpreted for the process area. If there is no elaboration present, the application of the generic practice is obvious without an elaboration.

GOAL : A “GOAL” is a required CMMI component that can be either a generic goal or a specific goal. When you see the word “goal” in a CMMI model, it always refers to model components (for example, generic goal, specific goal).

MATURITY LEVEL : A MATURITY LEVEL is a defined evolutionary plateau of process improvement. Each maturity level stabilizes an important part of the organization’s processes. Maturity levels, which belong to the staged representation, apply to an organization’s overall maturity. There are five maturity levels, numbered 1 through 5. Each maturity level comprises a predefined set of process areas

PROCESS AREA : A PROCESS AREA is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. All CMMI process areas are common to both continuous and staged representations. In the staged representation, process areas are organized by maturity levels.

REFERENCE : REFERENCES are informative model components that direct the user to additional or more detailed information in related process areas. Typical phrases expressing these pointers are “Refer to the Organizational Training process area for more information about identifying training needs and providing the necessary training” or “Refer to the Decision Analysis and Resolution process area for more information about evaluating and selecting among alternatives.” All references are clearly marked in italics

SPECIFIC GOAL : SPECIFIC GOALS apply to a process area and address the unique characteristics that describe what must be implemented to satisfy the process area. Specific goals are required model components and are used in appraisals to help determine whether a process area is satisfied.

SPECIFIC PRACTICES : A SPECIFIC PRACTICE is an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities expected to result in achievement of the specific goals of a process area. Specific practices are expected model components.

STAGED REPRESENTATION : The STAGED REPRESENTATION uses maturity levels to measure process improvement.

STATEMENT : A STATEMENT is designed to be used for process-improvement and appraisal purposes.

SUBPRACTICE : SUBPRACTICES are detailed descriptions that provide guidance for interpreting specific or generic practices. Subpractices may be worded as if prescriptive, but are actually an informative component in CMMI models meant only to provide ideas that may be useful for process improvement.

WORK PRODUCT : he term WORK PRODUCT is used throughout the CMMI Product Suite to mean any artifact produced by a process. These artifacts can include files, documents, parts of the product, services, processes, specifications, and invoices. Examples of processes to be considered as work products include a manufacturing process, a training process, and a disposal process for the product. A key distinction between a WORK PRODUCT and a product component is that a work product need not be engineered or part of the end product.

[shilpa_teach]

thank u very much 4the info. provided.But still I am having little doubts in my mind.Are the companies following CMM or CMMI now?Is CMMI an improved version to CMM?If in an interview asked like this what is the diff b/n CMM
and CMMI what to say detailly?
thanking u once again

[kiran2710]

If you’re wondering what the difference between CMM and CMMI is :--

The CMMI is the successor of CMM. CMM was developed from 1987 until 1997. In 2002 version 1.1 of the CMMI was released: v1.2 followed in August 2006. The goal of the CMMI project is to improve usability of maturity models for software engineering and other disciplines, by integrating many different models into one framework.

Level 0 - Incomplete (more a CMMI thing, I think). There seems to be no consensus regarding whether this level should exist at all or not. I’d much rather ignore this level, but maybe it’s better to think of a Level 0 business as a collection of incompetent imbeciles doomed to fail? Perhaps I am wrong, but I think all responsible software companies start out at level 1 as soon as they begin to exist. Well, once IKEA has delivered the office furniture, and a crappy computer supplier brought several units of trash round.
Level 1 - Initial. It says that at this level you need high-quality staff to pull you up by the bootstraps. But do you think a person will come work for you from a level 2/3/4/5 company if they know you’re level 1? Umm, somehow I doubt it. And if they do, they’ll most certainly demands $10000 a month for it. Level 1 seems to be chaos, and might be such particularly as people position themselves for the gain of growth (”5 years from now I’ll have 20 programmers working under me”). Important: at level 1, people are on their own. Nobody invests in their training, nobody provides any coherent organization, things just happen ad-hoc, and it appears as though any management is being done by the developers themselves (nonexistent). I think even the fundamental role definitions are not clear at level 1 - everyone is just a company employee, and leave it at that.
Level 2 - Repeatable. Oh-kay, you’ve done nothing to reach level 1 apart from maybe getting your act together and writing a few employment contracts for the people you hired. You did a project or two, but everyone is unsure about the future, since success doesn’t offen arrive as early or as often as you want. Now, you want to up the stakes and reach the repeatable level, where you can repeat a past success because you already have the know-how, some modus operandi for getting something done. It’s probably some small project that requires fairly mundane things. My guess is, at level 1, you were not ready to be creative, but now you think you are (wrong. creativity comes at later stages).
Okay mister, but your resolve alone is not enough to get to level 2 - you need to start implementing stuff. Oops! Level 2, finally, calls for a management position. At last you need someone who will take the reins of power, so to speak, and steer you towards level 2 goals. Level 2 needs basic project management, i.e., managerial actions that are just about enough to keep the company afloat and track its progress. Level 2 is the place where you can start providing realistic estimates of your work, because, until now, you haven’t been tracking them. Oh, by the way, serious QA (Quality assurance) appears at this level.
Level 3 - Defined. Let’s recap. At level 2, you’ve got your engineers (they do requirements management, in addition to development), project management, and a support unit. Yep, that’s right - somebody has to fix bugs and the like. I hope you’ve hired people for that, because now we get another key player at level 3. Who is he?, you might ask. Meet the process manager. To me, it seems that process management is the layer on top of other layers, somebody who manages the interaction of project managers and support staff. Of course, the CMM spec is a lot more cryptic, but that’s my interpretation. Oh, by the way, training happens only at level 3, and is the responsibility of those men in pin-striped suits - the process managers. (How does this happen? I think it goes something like this: a process manager says “This developer’s English sucks!” and sends poor Alfonce to some crazy English school. He learns nothing, company spends $3000, everyone is happy.) Another thing is that at level 3, somebody in the organization basically sits down and writes a set of standards for how things need to be done. Project managers are then doomed to adhere to those standards (however realistic), or quit their job.
Apparently, validation and verification happen at level 3. This level is probably the most significant milestone, since 4 and 5 seem to be adjustments that improve on the bureaucratic process, not productivity. Well, who knows?
Level 4 - Managed. Want to inflate the management apparatus? Then move to level 4, where project and process managers will be breeding like rats and demanding obscene pay rises even though the organization’s people growth (should be approaching 100 by now) is not in any way related to their performance. Level 4 seems to be the mathematician’s paradise, since it’s all about measurement and analysis of how existing practices are implemented, where they fail, and how they can be refactored (oops, refactoring is a development term, I hope no-one fires me for this). At level 4, performance becomes predictable. We now know how many LOC a project should be, and who is to blame for the difference. The CMM says that although the result has become predictable, it might not be enough to achieve specific performance. Which, in layman’s terms, means that although the inflated project/process management apparatus did their jobs right and got their math correct, they didn’t cause enough positive change in order to bring more gold for the coffers (or get more work done, which is the same things, since time is money).
Level 5 - Optimizing. Remember I said that innovation doesn’t happen until a late stage? Well, guess what - you cannot innovate until level 5. The most likely reason is that you don’t have enough resources, manpower, and trust in your own personnel in order to allow people to try wild and crazy ideas on the off chance that they might work. At this level, the company finally starts to think about knowledge exchange between its staff. I have no idea how this happens though, but somehow we’ve delayed the knowledge transfer process until we got 150 people (that’s a magic number, of sorts) and 10 years behind us. Well woo-hoo! Let’s all go and discuss programming languages and exchange skills, and the quantitative analysis-obsessed managers can calculate how many man-hours we wasted and deduct those off our wages. Oh, and of course level 5 inflates both bureaucracy and the managerial apparatus once more, since someone has to do even more math regarding how processes work or do not work in particular situations. Great.

CMMI :

[shilpa_teach]

got it !!!!!thanku

[shilpa_teach]

what r the essntial elements and effective processes in CMMI?