INFO4MYSTREY

This blog is created for educational purposes. Info4mystery archive and support student, teacher, Educationalists, Scholars and other people for learning by facilitating reflection, questioning by self and others, collaboration and by providing contexts for engaging in higher-order thinking.

Post Page Advertisement [Top]

Capability Maturity Model for Software

Capability Maturity Model for Software

Abstract

The Capability Maturity Model for software is a development framework that describes the most important elements for an effective software process. Capability Maturity Model access to improve processing; sums up some of the strengths and weaknesses of the current model and its use; recognizes the status of training and return on investment for improving software processes. The Capability Maturity Model describes the five stages of development in which an organization manages its process. The attention behind the model is to develop software that should be able to absorb and carry software application. The model also offers specific steps and activities that move from one level to another.
Introduction
The Capability Maturity Model (CMM) is introduced by the Software Engineering Institute (SEI). The Capability Maturity Model for Software (CMM) is a framework that discussed the most important forms of successful software process. Capability Maturity Model for Software (CMM or SW-CMM) is a situational model for periodic evaluation of software processes and a standardized model to help software companies develop in an evolution path from the ad hoc, distorted processes until mature, disciplined software processes. The CMM describes a path of developmental recovery from an ad hoc, undeveloped process to fully developed, methodical procedure. CMM is related to the basic of software in which planning, engineering and management processes and maintenance included. When pursuing important practices, they improve the ability of organizations to achieve goals for costs, planning, functionality and product quality.
CMM sets a standard where it is possible to assess the development of the organization's software process in a repeatable manner and to compare it to the practice industry. In organizations the developer set up and improve software processes where they develop and maintain their software products, they go through maturity levels. Each level of maturity provides the basic layer for continuous elevation of the process. We can use CMM in any organization to prepare the software process in better way.
CMM defines five levels of maturity, from initial (level 1) to optimization (level 5), and permit analysis of the process possibilities of the organization. The CMM consists of an integrated set of key area processes (KPAs), ie targets and common attributes, at each level and all these KPAs must be implemented to advance to the next level of the season. CMM only offers representation in one phase.
Capability Maturity Model Levels
The Software Engineering Institute (SEI) is credited for the development of first maturity models, the Capability Maturity Model (CMM) in which the software is applied to implementation of processes. While organizations are building and improving the software processes in which they build and maintain their software products, they continue to the level of maturity. Each level of maturity provides a basic layer for permanent enhancement of the process. Each part of the key process consists of a set of goals that satisfied; stabilize an integral part of the software process. The achievement of each part of the Maturity model strengthens various parts of the software process, outcomes in overall increase in the possibilities of organizational processes. The organization has developed five levels of maturity, each with different abilities. There are main levels in CMM: initial, repeatable, defined, managed and optimized.
Maturity Levels
A level of maturity includes a set of precise generic and specific skills to achieve a set of defined process areas that are aimed at promoting the overall performance of the organization. Maturity levels must also be evaluated and this evaluation will be carried out using a number of specific and common objectives set out in the introductory sets of procedure.
There are five main levels in maturity models: initial, managed, defined, qualitatively managed and optimized. Each level of the CMMI model is elucidated in the following sections.

 Maturity Level 1 - Initial
Initial is symbolized by ad hoc or anarchic processes. Success is usually dependent on skills or heroism of employees in the configuration instead of using proven process. At this level products and services work, but it is often surpassed both budget and schedule. These organizations are often overworked, abandon the processes, or can’t repeat historical performance.
Maturity Level 2 - Managed
At managed level, projects are planned, implemented, measured and monitored. Requirements, progression sketch and methods may fluctuate, but the recognized process management development helps to protect that accessible process remain and that projects are carried out and governed in accordance with the documented plans. Developments, requirements, product work and Services are managed at unambiguous release points. Decisively, the processes are analyzed and updated if necessary, and analyzed and checked to meet requirements, criteria and goals. In general, processes are not continued outside the sector or business unit, and there is frequently slight or no decision making support.
Maturity Level 3 - Defined
An organization at this level uses processes that are identified, defined, implicit and catalog by methods, tools, modes and designs. Requirements, characterizations and activities continue of companywide processes and they are continuously kept throughout the organization while modifications are allowed in each set guidelines. Processes are characterize in more detail and stricter than the 2nd level of maturity. In addition, they are managed with recognition of mutual relationships between processes and measures, products work and services. The processes are as expected, but in general there are no dimensions to enforce it.
Maturity Level 4 - Quantitatively Managed
At this level, sub processes help with complete performance and are managed use of analytic and other amounts of strategies. Performance measures have been set for quality and performance, and are used as the standard for managing processes as a whole full lifecycle. Dimensions are based on customer needs, end users, partnerships, and the process of enforcement achievement to hold up future decision-making. The process differences are recognized and rectified, and the performance is both controlled and conventional.

Maturity Level 5 – Optimizing
At the peak level of maturity the processes are continuously enhanced the basis of significant measures of general causes of modification in processes. The focal point continues to improve execution through both accumulative and modern technological improvements. The amount of process improvement goals is determined, updated and used to manage improves the process. Improvements are accessed on the basis of organizational goals and one they are driven by qualified personnel. The organization responds quickly to changes and time and share the learning and knowledge separately. Continuous improvement is part of everything employee roles.
Key Process Areas
With the exception of level 1, each maturity level is dissected into many Key Process areas that designate what an organization needs to focus on to develop the software process. The most important parts of the process are the problems that need to be addressed to acquire a level of maturity.
Level 2
The key process areas of the level 2 are focused on problems with project software which relates to the setting up of basic project management control.
·         The goal of Requirements Management is to set up a common position recognizing between the customer and the software project Customer requirements that software projects can meet. This customer agreement forms the basis for planning and software project management.
·         The goal of Software Project Planning is to be moderate plans for the issuance of software engineering and for management software project. Plans are the essential basis for software project management.
·         The goal of Project Tracking and Monitoring is to determine sufficient insight into the actual progress, so that the management can take more time impressive action when the performance of project software is different great of software plans.
·         The goal of the Software Subcontract Management is to select the accomplished software subcontractors and manage them impressively.
·         The goal of Software Quality Assurance is to supply management with suitable perceptibility in the process used by the software projects and products developed.
·         The objective of Software Configuration Management is to determine and manage the integrity of software products the whole time the project software life cycle of the project.
Level 3
The most important process area in level 3 is related to both projects and organizations problems, as the organization creates a framework that systematize effective software engineering and management processes for entire projects.
·         The objective of the Organizational Process hub is to determine the organization's obligation for software development activities to improve the overall accommodation of the organization software process.
·         The objective of the Definition of Organizations Process is to establish and manage a useful set of software process resources that improves the process execution on projects and offer basis for reference significant data for quantitative process management. These resources give a solid basis that can be established through mechanisms such as training.
·         The objective of the training program is to enlarge abilities and knowledge of individuals to carry out their duties skillfully and accurately. Training is an organization's obligation, but software projects must recognize their required abilities and give essential training when the requirements of the project are exclusive.
·         The objective of Integrated Software Management is to accommodate the software engineering and management activities in clear, distinct process software which is modified from the organization's requirements software process and related resources processes. This agreement is depend on the business encompassment and the technical requirements of the project.
·         The objective of Software Product Engineering continues to be one clearly determine engineering process that accommodate with all software technical tasks to manufacture the accurate, uniform software products adequate and well-organized. Software Engineering Software elaborates technical project tasks, for example assessment of requirements, design, code and testing.
·         The objective of group engineering is to find a way for software engineering group to vigorously cooperate with another engineering group so that the project will be better able to satisfy customers need to be effective and efficient.
·         The objective of Peer Reviews is to eliminate errors initially and effectively from software work products. Its important consequence is the development of a better understanding of software work products and errors to be avoided. Peer review is significant and effective engineering techniques that can be executed through analysis, outlined walkthroughs or a number of other collegial assessment methods.

Level 4      
The most important area of the process at level 4 is to establish a significant accepting both process software and software work products created.
·         The objective of Quantitative Process Management is to control the process execution of software project quantitatively. Software representations in the process represent the actual results obtained from follow a software process. The focus is on determining special reasons variation within a sophisticated process and corrections, such as appropriate, the circumstances that cause temporary diversity to occur.
·         The objective of Software Quality Management is to achieve one quantitative accepting of project software quality products and achieve specific quality goals.
  
Level 5
The key areas of the process in level 5 are related to the problems of the same organization and projects should be focused on ongoing and measurable execution improving the software process.
·         The goal of Defect Prevention is to recognize the causes of errors and prevent them from iteration. Software reviews errors, recognizing its causes and changing the specified software process.
·         The objective of the Technology Change Management is to recognize the benefits of new technologies for example tools, procedures and processes, and move them in the organization in a proper way. The focus of Technology Change Management is about making great changes to a constant change world.
·         The goal of Managing the Change Process will continue to upgrade the software processes used in the organization that are intended improving software quality, increasing productivity and reducing cycle time for product development.
Uses of the CMM
CMM is a framework that implies a path of improvement recommended for software organizations "(Paulk et al., 1991: 23). CMM has taken the structure of the framework of maturity and expanded it to a model pattern. The four main uses of the CMM is:

Test teams:
It will use CMM to identify the enhancements required by the organization.
Review teams
Use CMM to identify the risks of choosing from different contractor for issuing contracts and as a means of contract checking.
 Managers
It will use CMM to gain insight into the activities needed to achieve one improving the program within their organization.
Process improvement groups
It will use CMM as a guide to help them identify and progress software processes in their organization.
CMM/CMMI Strengths
Applying the CMMI model strengthens firms to commit to some methods and assessments. Receiving CMMI accreditation is a great benefit to both the clients and employees of an organization. It recovers the quality of products and services and improves the productivity of companies by improving working methods. It also supports and strengthens the company's ability to predict project planning and to achieve a higher return on investment and to increase the ability to manage risks.

CMM/CMMI Weaknesses
The CMM / CMMI model requires a lot of time, money and effort to execute and often requires a great cultural shift and attitude towards organizations that make a decision to apply it. A study showed that the median time for an organization to go on five levels CMM / CMMI level. These levels take time between 21 and 37 months. More than three-quarters of the organizations report that the implementation of a specific practice (SP) takes longer than estimated. Moreover, the culture of an organization can be influenced by the impact by adding a strong CMMI bureaucracy and reducing the creativity or independence of developers.
Conclusion
CMM represents a "common sense engineering" approach to software improving the process. Maturity levels, key process areas and important tasks are widely discussed and assessed within the software community. CMM offers an imaginary structure for developing management and software products in a restricted and uniform manner. It does not guarantee that software products are successfully developed or all software engineering problems are solved adequately. CMM recognizes the features of an effective software process, but mature the organization manages all the things that are important for a successful project, including people and technology, as well as processes.
References:
[1]      B. . Widliam G. DickerhoffJr., B.S. William J. Sommers, “The Adaptation Of The Sei’s Capability Maturity Model To The Air Force Software Acquisition Management Process.”
[2]      R. H. Salman, “PDXScholar Exploring Capability Maturity Models and Relevant Practices as Solutions Addressing IT Service Offshoring Project Issues,” 2014.
[3]      M. Paulk, B. Curtis, M. Chrissis, and C. Weber, “The Capability Maturity Model for Software,” Softw. Eng. Proj. Manag., pp. 1–48, 2006.
[4]      C. V Weber, S. M. Garcia, C. V Weber, S. M. Garcia, and M. Bush, “Key Practices of the Capability Maturity Model SM , Version 1 . 1 Software Engineering Institute,” no. February, 1993.
[5]      R. S. Oshana and R. C. Linger, “Capability Maturity Model Software Development Using Cleanroom Software Engineering Principles - Results of an Industry Project,” Sci. York, vol. 0, no. c, pp. 1–10, 1999.
[6]      P. Miguel, C. Saraiva, and E. Committee, “OpenSSL acceleration using Graphics Processing Units Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering,” no. October, 2013.
[7]      M. Latifi and R. Andersson, “Designing a Process Measurement Program,” Measurement, no. 17, pp. 1–93, 2009.
[8]      J. Kaur, “Comparative Study of Capability Maturity Model,” Int. J. Adv. Res. Comput. Sci. Technol., vol. 2, no. 1, pp. 47–49, 2014.
[9]      J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M. Paulk, “Software quality and the Capability Maturity Model,” Commun. ACM, vol. 40, no. 6, pp. 30–40, 1997.
[10]      A. Heller and J. Varney, “Using Process Management Maturity Models.”



No comments:

Post a Comment

Popular Posts

Bottom Ad [Post Page]

| Designed by Colorlib