Tailoring Cmmi Key Process for Smaller Organizations

Introduction

Small organizations are frequently understaffed and in many cases, they have to operate on a tight budget. Large organizations on the other hand have ample resources and funds to take up CMMI projects. However, small organizations must find ways and means to ensure that they manage to get the certification, even with limited resources. While CMMI has defined a number of key processes and key process areas, smaller organizations can decide on the processes and areas in which CMMI can be implemented. CMMI certification is available for the whole organization and even at the process or project level [1]. Once the processes and areas are prioritized, tailoring can be done by matching the CMMI recommendation and actual organization practices and processes. There is also the facility that individuals can function as groups on a part-time basis, as long as they take responsibility to complete the activities that their role demands. The same logic can be employed for requirements analysis and smaller organizations can take up activities that best represent the activities they want to map and improve. The next sections provide information on tailoring that is applicable for smaller as well as larger organizations.

High-Level Road Map for Process Tailoring – Requirements Management

Requirements Management is used to initiate a common base of understanding between the software project and the customer. The software project would essentially be the means through which the customer’s needs are met. Usually, a ‘system requirements’ agreement is used to create the understanding between the customer and the organization that would provide the software project [2]. In a broad sense, customers refer to the external customer or even the internal customers that may be an internal department, marketing group, or even the systems engineering group. Included in the agreement are deliverables such as the technical requirements and the delivery schedules. The agreement is the base document on which all software life cycle tasks such as estimation, performance, planning, activity tracking, and other aspects are done. Within an organization, the software engineering group may take it upon itself to define software and hardware components, and the software engineering group may not be given direct control. The software engineering group may take the required actions so that the systems requirements are followed and the necessary phases are documented, followed, and controlled. To achieve control, the software engineering groups review both initial and revised steps before the requirements are programmed into the software project. In case there are changes in the system requirements, then the software plans that are affected, software products are reviewed and all related activities are updated so that the plan reflects the new requirements [3]

Tailoring CMMI key process and Key process areas for smaller organizations

Embracing CMMI requires deep commitment from the top management and requires dedicated and qualified personnel from the organization that would have to be first trained and certified as assessors and lead assessors. Two concepts need to be clarified before beginning this chapter and they are tailoring and interpretation. Interpret is “the act of analyzing the definitions and/or terms of a general process described with respect to an existing instantiation of the description in order to facilitate the understanding of the relationship between the description and the instantiation”. Examples are an interpretation of the important practices that belong to a key process area and relate it to the current processes used by a software contractor. Tailor is “the act of adjusting the definitions and/or particularizing the terms of a general description to derive a description applicable to an alternate environment”. An example is tailoring important practices of the SW-CMM to produce process requirements for an organization’s standard software process [4].

Key practice Areas have certain features that are common, they give importance to obtaining, ad formalizing the process capability and this is in turn linked to the KPA. Some issues and activities that are addressed include work performance, setting up of plans and procedures, tracking of work status, initiating corrective action when there is some variance. Some coon features and the key practice areas are listed in the following table. The intent of these common features must be understood to ensure that the intent is achieved.

Tailoring Framework

Before beginning to use the key practices of the software capability maturity model integration – SW CMMI, the organization has to find any differences and similarities in the environment specified by the SW CMM and the actual organization environment. Other aanalysesthat must be performed include finding the difference and similarities in the actual and assumed relations with customers; extent of formality, granularity, frequency and scope of the organization OSSP; the existing process capability, and a listing of the business goals and requirements that would be addressed by CMMI. This activity is very important as it identifies the present status of the organization and later after improvements are done, it would help to understand the improvements that have been made [5].

Shown in the following figure is a model of a framework for the CMMI tailoring.

Organizations business needs and goals are mapped with the current process capability to frame the requirements analysis that forms the tailoring of CMM. There is a branching here where the organizations standard software process and the organizations tailoring guidelines are mapped to the OSSP tailoring. This leads to the projects defined software process and project planning and the net result in the software development plan. To tailor the important practices for CMMI, it is important to understand the existing process capability in an organization. CMMI is arranged as per the maturity levels of increasing process capability and the involvement of projects processes have to be based on status of the processes. As the organization matures, tailoring requirements would also change. As the organization moves around the ideal CMMI model it would have to analyze the new process requirements continuously, match it with the current process and attempt to bring in the required changes. Therefore tailoring should not be considered as a one-time event but as a continuous and ongoing analysis. [3].

Organization Structure

CMMI assumes that the organization has a certain structure and size and employees would have specific roles that impact key practices. While multi tasking is productive, it would have a different impact on CMMI practices since there have to be separate function roles that are required for development and maintenance of large systems. In large organizations, this is not a problem since the firm has the resources and sufficient work for a number of employees. In smaller organizations where a role such as the of a purchase manager extends to areas of inventory and stores management, logistics and supply chain, demand planning and others, this can create conflicts. However, in smaller organizations it is imperative to have roles such as software continuation group, quality assurance and training groups. In some cases, groups can be from different departments and can be cross functional. A group can have many managers and individuals from different departments who work full time or part time and are responsible for a certain set of tasks, as in large organizations. In smaller firms, a group can be made up of even a single person who may work part time and is responsible for a certain set of activities. Depending on the context specified in CMM, roles are defined as active and passive and these are related to the activity [5].

While defining groups, roles and responsibilities are detailed at great extent in CMMI procedures, smaller organizations can have difficulty in tailoring and mapping these defined roles to their existing structure. However, one person at least has to be made responsible for the activity or for carrying out CMMI activities. It has been observed that discipline and formality at the group or individual level when adopt yield quantifiable results in productivity, adherence to schedule and to the quality. Some amount of matching may be required for smaller organizations that have lesser resource. Where the structure is different than required by CMMI, the key practices need to be correlated, adjusted or mapped to the actual organization structure [5].

Relations with end users and customers

It is assumed in the contract environment that there is a single known customer who would be used to define the system requirements and that the customer has the resources of knowledge, money, desire and time to be involved in the development reviews. When creating customized and made to order products, this factor becomes very relevant. In cases where there are multiple customers or unknown users who may not be involved in the actual development process then the organizations provides surrogate users and customers who would assume the role of the known customer. In real life development processes, it is worthwhile to translate these ideas into real values. As an example, a customer contract would have system requirements for inventory management and these would frame the requirements for the required products. It is essential to go beyond the interpretation of the words in the key practices and fully know the intent [4].

Tailoring by Degree

The term means that the desired intent of the tailored object is met with a few incidental changes to the detail. Tailored objects would include work products, activities, process artifacts that would have to be changed by a minor amount. Each object has certain attributes and these need to be specified so that tailoring is the same across multiple objects. There are four attributes and they are formality, frequency, granularity and scope [3].

Business Goals

While tailoring CMMI for an organization, the business goals and requirements have to be known. As key practices are meant for a wide audience, certain common business goals are assumed. They are increase in quality, cost reduction, tighter adherence to schedule and continuous improvement of software processes. Depending on the organizations needs, it may set priority to these goals [3].

Requirement Analysis

Requirements analysis and tailoring ensures that the requirement used for OSSP are inline with the requirements of CMMI. Organizations generate requirements from different inputs such as TQM, ISO 9000 or other initiatives for quality management. These may sometime not be documented formally in the required template. The requirements analysis is flexible and as the organization matures, the requirements can be augmented with others. Compatibility is addressed at the important process level. To ensure that there is compatibility with the certain key process area – KPA, it must be ensured that goals of the KPA are met and the processes used for these goals are properly documented. There are a number of process elements in each KPA and some of them are roles, entry criteria, inputs, activities, outputs, exit criteria and others. Requirements are made up these elements. Roles are used to describe individuals or groups that are involved in process activities. Some examples are agents, verifiers, reviewers, customers and suppliers. Entry criteria refer to the conditions under which an activity can commence. Inputs are the work products from previous activities that are used for the next activity and typically software requirements analysis serve as inputs to the software design activities. Activities refer to the action run. Output refers to the result of the processing activities while exit criteria are the conditions and status when an activity is regarded as completed. Among the elements, for the initial maturity model, elements such as output, activities and roles are important. A number of checklists are used to capture the requirements of these elements and they are described in the next sections [3].

Mapping Output Element

Output refer to the items and entities that are created by executing a process. Some examples are testing code, minutes of a meeting, reports generation and so on. Outputs are very important in meeting the goals for each KPA and the best way to show that the goals are met. There are a number of checklists that are used to identify the required output for each KPA. An example of an output checklist is as shown below [3].

There is a column to indicate with a checkmark if the output is produced, entering the organization’s terminology for an output, and including a reference to the specified output in the OSSP. Smaller organizations may not be able to match the document set given as a useful. In such cases, analysis has to be done to find if the organization produces the outputs are are specified in the SW CMM. If the content is not needed for an organization then it can be kept blank. In other cases, codes can be used to denote all the coverage examples such as complete, shared and partial. [3].

Mapping Activity Element

Activity mapping is undertaken after the outputs are mapped. Activity describes actions and happenings that are being done. They may be related directly with the manufacture of a product or a service or they may be a management function. They are designed to help the operations to run more efficiently. Each KPA would have a number of activities and the requirements phase requires that if the activity is performed then it has to be mapped to the existing organization process. A checklist is used for requirement gathering and a sample checklist is as given below [3].

The above checklist gives a list of activities that are specified in the CMMI standards. Each activity for a KPA has to be examined to understand the relevance to the organization. The analysis needs to be performed with the idea that many of the activities may be linked to other activities and any decision can impact other activities. For each of the activity, the disposition code should be entered. Some disposition codes identified are accept, expand, tailor, optional and not recommended. The results can be used for tailoring activities [3].

Role Mapping

Organizations may have different styles of operations with different groups and individuals who are responsible for activities completion. Role mapping helps to identify the roles that are responsible for performing roles that are referenced for each KPA key practices. The mapping is used to identify the existing process holes that can be addressed by any future process improvement activities. The following table gives a list of roles that can be used in the CMMI plan [3].

Example of Requirements Tailoring

As an example, the requirements analysis for an organization is performed here. There are different steps involved. The first step is to define the goal or goals that would be achieved through the tailoring. The next step is to specify the commitment to perform and the ability to perform. Once these are done, then comes the task of specifying the activities that would be performed followed by the measurement and analysis step and the verification and implementation stage. Tailoring is applicable for all the steps and the organization can choose the items for commitment as per its ability and select appropriate activities that it can perform. Measurement and analysis and verification and implementation steps are mandatory and an organization cannot say that it does not wish to take up these last two steps. The steps are explained as below and they should follow the broad framework as explained in the previous section.

Setting Goals

Goals can be defined as “System requirements allocated to software are controlled to establish a baseline for software engineering and management use”. Another goal can be “Software plans, products, and activities are kept consistent with the system requirements allocated to software”. It is up to the organization to define a single goal and CMMI suggests that the goals should be realistic.

Commitment to perform

It is expected that there would be a document organization policy for the projects that would guide in system management. Allocated requirements are the system requirements that are allocated to the software and this is a subset of the requirements that have to be built into the system. Primary inputs for the software development plan are taken from the allocated requirements and these are further refined by the software requirements analysis to form a documented software requirements policy. The policy would imply that the documentation of allocated requirements is done and software managers have reviewed the allocated requirements. When changes to the allocated requirements arise, then work products; software plans and also activities are updated. [5].

Ability to Perform

Responsibility or the project is set by taking up system requirements analysis and allocating system components, software and hardware components. The software engineering group is not responsible for analyses and allocation but the analysis forms the basis for other work. Areas covered as documentation and management of the system requirements; allocation in the life cycle of the project managing changes that are brought on by the system. Some examples are contract terms and conditions, details of products delivered, milestones and schedules and technical requirement examples are details of support, end users, design constraints, interfaces, performance and so on. [5].

Activities Performed

Before the allocated requirements are used in the software project, they are reviewed by the software engineering group. Missing or incomplete requirements are identified and a review is dome to find if the requirements are feasible, suitable for implementation, clear in their statement and intent, consistent and if the results can be tested. The allocated requirements are that would have some problems are then subjected to a review by the responsible group and if necessary, changes are made. Changes that are to be made are reviewed and discussed with the groups and the senior management. Some examples of changes are risk that are evaluated and identified, documented and planned and changes that are subjected to tracking. [5].

Measurement and analysis

Measurement is employed to understand the extent to which activities for allocation management are completed. Some examples are change activity and status for allocated requirements, total number of proposed changes and their status such as closed, open, incorporated or approved. [5].

Verifying implementation

Review of activities with the senior management for allocated requirements periodically has to be done. Periodic review ensures that awareness and insight can be given by the senior management into the activities of the software process. Interval between the reviews can be of sufficient time and exception reporting mechanisms should also be built in. The reviews and audits ensure that problems are attended to before software engineering finds makes a commitment. Issues such as products, activities and the software plans should be revised as and when there are changes to the allocated requirements. If there are any changes to the commitments that occur due to changes in allocated requirements then these have to be discussed with different groups that may be impacted. [5].

Requirements Tailoring for Small Projects and Smaller Organizations

The last section deals with tailoring the OSSP to obtain the defined software process for small organizations. Organizations use the OSSP to reveal requirements that have to be met by the software development process. By using OSSP, a common process is established across the organizations projects to support process continuity and measurement and to take process improvement. Tailoring guidelines are used to develop the processes used on projects. In CMMI, the OSSP is adjusted to a process that matches the particular business and technical requirements in called as tailoring the OSSP to create the defined software process [3].

Project Tailoring for small organizations

For tailoring a project, its business goals and other requirements must be understood. Each individual project would have certain specific goals that would impact certain processes. These goals are in addition to common organizations goals of reducing costs, and delivery time, increasing profits and efficiency. In some projects for pilot study of a technology, other than cost, performance of the technology and delivery of the project may be more important than just controlling costs. In such cases, it is important to understand the current process capability of the organization and the project. It may happen that the project may be attempting to operate at a higher maturity level than that of the organization, because of customer requirements. In such cases, one choice is to make the OSSP reflect the ideal model that other projects can hope to achieve. The other option is to take the average of the projects. At the project level, tailoring is done by using project needs to choose an option from the recommended set. In many cases, selection has to done on intuition. Please refer to the following figure [3].

The project initially starts with the OSSP and then uses the guidance given in the tailoring guidelines to find the suitable alternatives. The selection option is used for modification of the OSSP into the process for the project specific requirement that may be captured separately. In many cases, the OSSP itself would have a checklists and tailoring details can be recorded into them. It is also possible to edit an existing project template and create the project specific processes. The development plan is very important for the project management. The delivery schedules in the plan are an application of the defined software process for the project to development of products. The tailored version must be contained in the defined software process that would be used in the project. The process may be the same or different from the organizations process, Tailoring gives the project the ability to develop reasonable and efficient development plans for management and control of the delivery [3].

Conclusion

The paper has discussed the method of tailoring CMMI Key Processes and Key Process Areas so that they can be applied for smaller organizations and small projects. While the standard CMMI processes require dedicated and trained manpower with sufficient funds, smaller organizations cannot afford such resources. Consequently, tailoring helps organizations to select the key processes and key process areas that suit their organization goals and needs and attempt to implement the best practices of CMMI. Smaller organizations can select specific business processes and area, activities in these processes and specific elements that would be set up for CMMI. The document has provided checklists for role mapping, activity mapping and output mapping as these are important aspects for smaller organizations.

References

1. 1. Ahern. Dennis. M., 2003. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. Addison-Wesley Professional.
2. 2. Chrissis. Mary. Beth., 2006. CMMI: Guidelines for Process Integration and Product Improvement (2nd Edition). Addison-Wesley Professional.
3. 3. Ginsberg. Mark. P, Quinn. Lauren. H., 1995. Process Tailoring and the Software Capability Maturity Model. [Online] SEI: Carnegie Mellon University. Web.
4. 4. Olson. Timothy. G, et all., 1994. A Software Process Framework for the SEI Capability Maturity Model. [Online] SEI: Carnegie Mellon University. Web.
5. 5. Paulk. Mark. C, et all, 1993. Key Practices of the Capability Maturity Model, Version 1.1. [Online] SEI: Carnegie Mellon University. Web.