Capability Maturity Model and Support For Systems Analysis

Mike Good

MSIS 488

            There are various methodologies that organizations have embraced for systems analysis.  These methodologies are a process and ideology that the software analysis and development effort has embraced.  These methodologies give a framework to be followed that gives a path to be followed by Information Technology.  These methodologies range from the Boehm spiral model to joint application development.  Microsoft even developed their corporate standard called the Microsoft Solutions Framework (Rada, 69).  You are seeing industries such as construction adopting the methodology (pS577).  The methodology that has been adopted greatly is the capability maturity model.

            Capability Maturity Model (CMM) was developed at the Carnegie Mellon Software Engineering Institute, which is an Institute founded by the United States Department of Defense (Phan, 56).  There are capability maturity models for various areas ranging from people to integrated product development.  All these CMMs want to address various broad goals, which are:

The CMM provides a way for various processes to have a standard that will be adhered to.  This standard provides a baseline and then the organization works towards levels of maturity.  Each level has certain key process areas that are identified and are of focus to obtain that next level of maturity.  The CMM that relates to systems analysis is the CMM for software (SW-CMM).

            CMM has various components to its model.  The first component is the maturity levels.  These are well-defined points, which are a guide toward a mature software process.  The five distinct levels, which are initial, repeatable, defined, managed, and optimized, provide the high level design of CMM.  Next, there is the process capability, which describes the range of expected results that can be achieved by following a process.  This gives the organization a good idea of the results that will come from a project if the process is at a certain level.  Third, the component called key process areas or KPAs are a group of actions that when perform collectively achieve a set of goals considered important for establishing process capability at that level.  These process areas are defined at each distinct maturity level.  Next, the goals component summarizes the important practices of a key process area and can be used as a baseline to determine if an organization has effectively implemented a KPA (Parzinger, 359).  The goals define the scope and the intent of each KPA.  Another component is the common features which these are the common features to key practices and include: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.  The common features are properties that show whether the implementation of a key process area is effective, repeatable, and lasting.  The final component, key practices are practices, that when implemented, help to satisfy the goals of that key process area.  The practices are the infrastructure and activities that contribute most to the effective implementation of a KPA.

Now, the discussion of each maturity level should be defined and an idea of each level’s composition.  The vast majority of the companies are CMM level 1 (Marco, 27).  This level is composed of ad hoc work and the IT staff is not sure what the plans are.  This causes a very chaotic situation with a few heroes who come in and save the day (Gray, 93).  This method of development has very adverse effects on the people of the department, the quality of software produced and the speed and efficiency that the software can be produced.  CMM level 2 is called repeatability and has these key processes areas:

 

These affect systems analysis in various ways.  First, requirements management is very crucial.  Requirements management involves getting this common understanding between the clients and the project that the expectations of the client are met by the system (Paulk, L2-1).  This is one of the core roles of systems analysis; that is finding if the system should be done, i.e. is it helping the entity that it should, the clients.  In managing this relationship and understanding, this ensures that the systems analysis is even more successful since the analysis is being based on correct and current requirements that the client is aware of and has approved as being what they want.  If the requirements are not what the clients are wanting, then the systems analysis process can be successful for what it is analyzing, but since the analysis is being done on incorrect information then the ultimate outcome will be wrong.  Also, since there is some tractability with the changes in documentation being versioned, it assists the analyst by the analyst being able to see the differences in the documentation as contrasted with what they were using prior to the changes.  There is also some built in support to the system analysis procedure by CMM in the requirements management by doing a feasibility analysis to determine if the requirements can be met with the software or if they should even be included in the software.

            Another key area in level 2 is software project planning.  The purpose of this area is to establish appropriate plans for the engineering and management of the software project.  This plan includes the work to be performed and any bounds and goals that aid the scope of the project.  The planning process includes steps to estimate the size of the work, resources needed, produce a schedule, identify and evaluate software risks, and negotiate commit points.  There are three goals for the software project planning.  The first is that software estimates are documented for use in planning and tracking the project (Paulk, L2-12).  This tracking is crucial so that the status of the project is easier to manage and track the performance.  This also a function of the analysis that can uncover situations and uncover opportunities for greater efficiencies such as items in the process that can be completed in parallel.  The second goal is for software project activities and commitments to be planned and documented (Paulk, L2-12).  This provides a way of measuring the accuracy of the estimates and determining any inefficient areas in the project and problems along the timeline.  The final goal is to have the groups and individuals related to the project agree to their commitments to the project (Paulk, L2-12).  This ensures that all parties have a mutual understanding in what their role is and any additional information associated with that role and has agreed that they can commit to those activities.  The software project planning area in level 2 is important for having a clear road of the activities for the project.

            Software project tracking and oversight is another KPA for CMM level 2, which provides visibility into the actual progress of the project so that management can take corrective actions when the project deviates from the plan.  This step is taking a look at the accomplishments and reviewing them against the documented estimates and plans and then adjustment of the plans based on the actual accomplishments.  Management reviews software activities and progress is evaluated by the actual software size, cost, and schedule to the plan when certain efforts are completed and at pre-determined milestones.  When there is a determination that the plan is not being met, then action is taken including revision of the plan, reallocation of resources, or actions to improve the performance.  There are three goals to software project tracking and oversight.  The first goal is that actual results and performances are tracked against the project plan (Paulk, L2-32).  This uncovers problems and also provides an instant snapshot of where the project is at on the timeline.  The next goal is that corrective actions are taken and managed to closure when actual results and performance deviate substantially from the plan (Paulk, L2-32).  If the deviation is noted and nothing is done to correct the deviation, then noticing the deviation wasn’t of any value to the project.  The final goal is that the interested parties and people agree to changes to commitments (Paulk, L2-32).  This allows the communication to be open across the effort so that all parties have a contribution in changes and everyone has an equilateral position in the software project.

            Another key process area at level 2 is the software subcontract management.  This area is to select qualified software subcontractors and manage them effectively.  The first goal is that the prime contractor selects qualified subcontractors (Paulk, L2-46).  There has to be subcontractors that are knowledgeable and proficient in the areas of expertise that the prime contractor is wanting to hire them on for.  Since the rates are higher for a resource on contract than they are for a permanent resource then their must be evaluations to be sure the resource has those skills and it doesn’t just look good on the resume.  This can be done by looking at previous code or by arranging a one-week trial period that if the resource is not up to the expectations that he or she may be dropped from the project without any further commitments by the prime contractor.  Another goal is that the prime contractor and subcontractor agree to their commitments to each other (Paulk, L2-46).  This forms a consensus between both parties of what is expected, when it is expected, and any other details so that each party knows their role and what to bring to the table as far a deliverables for the project.  The prime contractor and the subcontractor maintain ongoing communications is another goal (Paulk, L2-46).  This helps the prime contractor know how the resource is doing and if there are any items the prime contractor needs to provide for the subcontractor for support in obtaining his commitments and this also lets the subcontractor know that the prime contractor is there for them.  The final goal for this process area is that the prime contractor tracks the software subcontractor’s actual performance and results against the commitments (Paulk, L2-46).   This tracking is a good reference mechanism for justifying the selection of the subcontractor or for reasons to break commitments to the resource based on the results from the subcontractor.

            The next area is the software quality assurance.  This area is to provide management with visibility into the process being used by the software project and of the products being built.  The key practices uncover the functions that need to be performed by this group in the software process.  The first goal is that software quality assurance activities are planned (Paulk, L2-64).  Like all processes, they must be planned so that expectations are outlined from the onset and there are scheduled activities.  The second goal is that adherence of software products and activities to the applicable standards, procedures, and requirements are verified objectively (Paulk, L2-46).  This activity shows that the policies and frameworks that have been established have been adhered to so that the consistency is evident.  The next goal is that affected groups and individuals are informed of software quality assurance activities and results (Paulk, L2-46).  This is in staying consistent with having open communication across all parties.  For example, if quality assurance uncovers a problem that affects the quality of a software effort such as a bug, then this should be notified to parties such as development, clients, and management so that everyone knows the level of quality for the product as well as potential problems and so that development can fix the code if this truly is a bug.  The final goal is that senior management will address noncompliance issues that cannot be resolved within the project. (Paulk, L2-46).  This provides a path of escalation so that the people skilled in resolution of issues are the ones handling those issues.  The quality assurance component is a complement to the analysis and the design since they will most likely be the last one seeing the product and are ultimately responsible for what the clients see.

            The final key process for CMM level 2 is software configuration management, which is responsible for maintaining the integrity of the products of the project throughout the lifecycle.  There are four goals for this key process area and they are important to maintaining the integrity of the product.  The first goal is that the software configuration management activities are planned (Paulk, L2-76).  This is consistent with all activities of the software process needing to be planned to create a meaningful timeline and analyze the plan for task dependencies.  The next goal is that selected software work products are identified, controlled, and available (Paulk, L2-76).  This ensures that licensing activities never become an issue and that products are selected before the project begins to ensure that their will not be lost time in having to research products in the middle of the project for this work not being done in the beginning of project.  The third goal is that changes to identified software work products are controlled (Paulk, L2-76).  This keeps resources from changing software at the drop of a hat, which could cause compatibility issues, and other complexities that could further delay the project.  The final goal is that affected groups and individuals are informed of the status and content of software baselines (Paulk, L2-76).  This is additional support for the open communications of where the project is and how well is it going. (Paulk, L2-46).  The software configuration management is a crucial component needed to maintain the integrity of the software being developed as well as the products needed to create the software.      

            The final level that is applicable to industry use and not theoretical is CMM level 3.  The key process areas for CMM level 3 are as follows:

§       Organization Process Focus

§       Organization Process Definition

§       Training program

§       Integrated software management

§       Software product engineering

§       Intergroup coordination

§       Peer reviews

The first key process area, organization process focus, has a purpose of establishing the

organizational responsibility for software process activities that improve the capability of the overall software process.  One goal for this KPA is that software process development and improvement activities are coordinated across the organization (Paulk, L3-1).  This means that the processes are managed at more of an enterprise level instead of at the departmental or district level.  The next goal is that the strengths and weaknesses of the processes used are identified relative to a process standard (Paulk, L3-2).  There is some baseline or benchmark that is used to determine the level to which the process is operating at to determine if changes need to be brought about.  The final goal for the organization process focus is that the organization-level process development and improvement activities are planned (Paulk, L3-2).  These are the goals of the first KPA for CMM level 3.

      The next KPA for CMM level 3 is organization process definition, whose purpose is

to develop and maintain a usable set of process assets, which improve the performance across projects and provide a long-term benefit to the organization.  The goals for this process area are that a standard software process for the organization is developed and maintained and that information related to the use of the organizations standard software process by the project is collected, reviewed, and made available (Paulk, L3-12).  These processes being developed at an organizational level provides a standardization which benefits the organization by having a more flexible organization in which people can move about easily since the process is the same across all areas.  The information being made available is key so that workers are more efficient by being able to get the information themselves and not having to rely on peers for the information.

      The next KPA is that of a training program that allows the workers to perform their role

efficiently and accurately.  One goal of this KPA is that training activities are planned (Paulk, L3-25).  This makes expectations and training plans known from the onset of a resource taking a role in the organization.  The next goal is that training for developing the skills and the knowledge needed to perform software management and technical roles is provided (Paulk, L3-26).  The final goal is that individuals in the software engineering group and software related groups receive the training necessary to perform their roles (Paulk L3-26).

      The fourth KPA for CMM level 3 is integrated software management, which is

responsible for integrating the software unit into one coherent process.  The first goal is that the project’s defined software process is a tailored version of the organization’s standard software process (Paulk, 3-38).  This means taking the process and customizing it to support the needs of the organization.  The next goal is that the project is planned and managed according to the project’s defined software process (Paulk, L3-38).  This looks at actually performing the activities that have been done and documented.

      The next KPA, software product engineering, has the purpose of consistently performing

a well-defined engineering process to produce consistent, correct software products.  The goals of this process are that software engineering tasks are defined, integrated, and consistently performed to produce the software and that software work products are kept consistent with each other (Paulk L3-60.  The consistency reduces the variability and leads to less errors and consistency in the process.

      Another key area, intercrop communication, is to ensure groups participate actively with

each other.  The first goal is that there is agreement by all affected parties of the customer’s requirements. (Paulk, L3-86).  This is a good way to ensure a consensus that the project has been given a seal of approval and avoids surprises and conflicts.  The next goal is for the affected groups agree to the commitments between the engineering groups.  The final goal is that the engineering groups identify, track, and resolve intergroup issues (Paulk, L3-86).  This aids in forming a knowledge base for recurring issues and also allows recurring issues to be analyzed to determine if there is an underlying problem that needs to be addressed.

      The final key area is peer reviews, which serve to remove defects from the software work

as early and efficiently as possible.  The goals are that peer revisions are planned and defects in the software work products are identified and removed (Paulk, L3-97).  Peer reviews provide more people analyzing a product so that different perspectives can contribute ideas as well as detect defects.

There have been many applications for the CMM methodology in industry.  This example

is directed towards the Defense Contract Management Agency (DCMA).  Using CMM, the agency can have an evaluation of the maturity of a contractor’s software development process without incurring the cost of doing a complete evaluation (Lang, 32).  In addition, it would also reduce costs by not having a contractor reviewed by every government agency that considers them for a contract.  They will use the CMM insight goals to provide consistent data about the maturity of contractor’s software processes.  This is going to be a phased approach with phase 1 being validation of the approach at the home locations of the SEI (Lang, 33).  Phase 2 will be the evaluation of the effectiveness of the approach in the typical field environment (Lang, 33).  Phase 3 will be the validation of the capture and transmission of the data before it is implemented agency wide (Lang, 33).  The benefits realized by the consolidation of the contractor’s CMM level is helpful from a redundancy aspect as well as a monitoring process to ensure the CMM level stays consistent with the DOD’s expectations. 

The CMM methodology is one, which has been around for almost two decades, and industry is now beginning to embrace the concept including countries such as India (Chendakera, 23).  Why has the buy in to the concept taken so long and why have some still not considered a process management methodology?  First, Information technology is a fairly new department in some corporations and just getting a start to the department was difficult enough without starting a defined process.  These departments feel that as long as they are creating software that it doesn’t need to be repeatable and the benefit to the client ad client interaction is not needed.  However, in looking at systems analysis, its role and CMMs support of that role, it is evident that these processes being defined and standardized provide a huge benefit to the process of systems analysis as well as the software development process as a complete entity.

Additional Links

http://www.jeffgainer.com/cmm_applied.html

http://www4.gartner.com/4_decision_tools/measurement/tq/pdf/CMM.pdf

http://www.stellarstudios.com/index.aspx?pageid=83

http://www.itmweb.com/f051098.htm

http://interactive.sei.cmu.edu/Features/1998/September/Introduction/introduction_sept98.pdf

http://www.npd-solutions.com/cmm.html

Bibliography

 

Chendakera, Nair, “Software hub set up in India”, Electronic Engineering Times, March 27, 2000, Issue 1106, pp.22-24

 

Gray, Paul, “IS Productivity”, Information Systems Management, 10580530, Spring96, Vol. 13, Issue 2, pp.92-95.

 

Hutchinson[sup1], A, “Standardized process improvement for construction enterprises”, Finnemore[sup2], M.., Total Quality Management, July1999, Vol. 10 Issue 4/5, pS576-584.

 

Lang, Bob,” Risk Data Based on Capability Maturity Models”, Program Manager, May/Jun2002, Vol. 31 Issue 3, pp.32-37.

 

Marco, David, “Included Meta Data & Knowledge Management: Capability Maturity Model: Applying CMM Levels to Data Warehousing”, DM Review, pp.27-28.

 

Parzinger[sup1], Monica J.; Nath[sup2], Ravinder, “A study of the relationships between total quality management implementation factors and software quality.”, Total Quality Management, May2000, Vol. 11 Issue 3, pp.353-372.

 

Paulk, Mark C., "Key Practices of the Capability Maturity Model - Version 1.1", Software Engineering Institute - Carnegie Mellon University.  

 

Paulk, N.C.,  “Extreme programming from a CMM perspective”, IEEE Software, Volume: 18 Issue 6 , Nov.-Dec. 2001, pp.19 –26.

 

Phan, Dien D, “Software Quality and Management”, Information Systems Management, 10580530, Winter2001, Vol. 18, Issue 1, pp.56-68.

 

Rada, Roy; Craparo, John S., “Standardizing Management of Software Engineering Projects.”, Knowledge, Technology & Policy, Summer2001, Vol. 14 Issue 2, pp.67 –78.

 

Woods, W. Addison., “Still No Silver Bullet: Managing and Improving the Software Development Process.” Armed Forces Comptroller, Winter99, Vol. 44 Issue 1, pp.33-37.