ISO/IEC Assessment of the Assigned Model

Compatibility Maturity Model (CMM) Assessment of the Assigned Procedure

Background:

This assignment requires us to perform a Compatibility Maturity Model (CMM) assessment of a given process belonging to Software Service Center (SSC). This process consistent of several interactions between the contractor (Municipality) and the service center is modeled in Appendix -I and described in Appendix - II.

The Approach

The CMM has five well defined maturity levels describing the evolutionary plateaus towards achieving a mature software process. Each of these levels has a set of process goals that, when satisfied, stabilize an important component of the software process (Zahran, 1998). For our CMM assessment, we will decompose these maturity levels in sufficient enough detail so that we can apply them to our process. Then, we will be in the position to make evaluations, assessments and improvement recommendations on this process. The characteristics of each level are listed briefly in Table -1.

CMM Levels	Brief Description
Level 1: Initial	The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.
Level 2: Repeatable	Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
Level 3: Defines	The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.
Level 4: Managed	Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
Level 5: Optimizing	Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

Table-2 CMM level key practices

Internal Structure of the CMM

Each key process area is described in terms of the key practices that contribute to satisfying its goals. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area.

Except for Level 1. each maturity level is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process. These are listed in Table-2.

CMM Level 1

CMM Level

CMM Level Key Pratices

Level 2 : Repeatable The key process areas at Level 2 focus on the project's concerns related to establishing basic project management controls. They are Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management.

Level 2 : Defined The key process areas at Level 3 address both project and organizational issues, as the organization establishes an infrastructure that institutionalizes effective software engineering and management processes across all projects. They are Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering. Inter-group Coordination, and Peer Reviews.

Level 3 : Managed The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are Quantitative Process Management and Software Quality Management.

Level 4 : Optimizing The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement. They are Defect Prevention, Technology Change Management, and Process Change Management.

Table - 2 ISO/IEC 15504 Process Capability Levels

In our given process, there are a number of questions that are left unanswered. Ideally, before we go any further with the process evaluation and assessment, we must get the answers to these questions to clarify or fill in the missing information. Some of these questions are listed in Appendix -III. However, since we do not have that freedom in our assigned procedure, we will make appropriate assumptions to fill in the missing blanks, where required.

Process Evaluation and Assessment

Process evaluation is achieved by identifying the missing critical practices of the key processes on the side of contractors, and evaluating the potential risk that these could cause (Zahran, 1998). Process assessment identifies the process strengths and weaknesses (relative to the CMM process definition).

To perform the evaluation and assessment, we will now analyze the procedure in detail based upon the CMM key process areas as listed in Table -2. Our finding are listed in the tables below.

CMM Level 2

Area of Maturity

Purpose

Application to the Service Center

Requirements Management To establish a common understanding between the customer and the software project of the customer's requirements that will be addressed by the software project. We assume that SSC puts high emphasis on high quality of customer service to stay profitable. Although there's no mention of how the contract is initially drawn, but there appears to be a general client-customer trust and understanding between the Municipality and the SSC staff.

Software Project Planning To establish reasonable plans for performing the software engineering and for managing the software project. There seems to be no set procedure being followed to complete the assigned task. However, the project appears to have been completed within the allotted time. We can, therefore, assume that the SSC has previous experience in preparing data for the THEBIT, though the procedures are not documented.

Software Project Tracking and Oversight
To establish adequate visibility into the actual progress of the project.
We cannot see any visibility in the process that enables the management to take effective action when the software project's performance deviates significantly from the software plan.

Software Subcontract Management To select qualified software subcontractors and to manage them effectively.

The given SSC procedure does not require any subcontractors. So this does not apply.

Software Quality Assurance To provide management with appropriate visibility into the process being used by the software project and of the products being built.
The given SSC procedure does not have any software quality assurance. So this does not apply.

Software Configuration Management
To establish and maintain the integrity of the products of the software project throughout the project's software cycle.

The given SSC procedure does not have any software product integrity. So this does not apply.

CMM Level 3

Area of Maturity	Purpose	Application to the Service Center
Organization Process Focus	To establish the organizational responsibility for software process activities that improve the organization's overall software process capability.	If we are to assume that the whole organization consists of Jupiter, Dorian, Moll, Bruce and Frances, then we can say that this organization (or the project team headed Jupiter) has a process focus. Otherwise, we will have to conclude the opposite.
Organization Process Definition	To develop and maintain a usable set of software process assets.	The assets learned from the past experience improve process performance across the projects and provide a basis for cumulative, long term benefit. We can safely assume that this is true in the case of SSC, since Jupiter and his staff appear to have a good grasp on the project objectives.
Training Programs	To develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently.	We cannot comment on the validity of this part since there is not sufficient information given for us to decide.
Integrated Software Management	To integrate the software engineering and management activities into a coherent, defined software process for the project.	We cannot comment on the validity of this part since there is not sufficient information given for us to decide.
Software Product Engineering	To consistently perform a well-defined engineering process that integrate all the software engineering activities to produce correct, consistent software products effectively and efficiently.	The SSC appears to lacks a Software Product Engineering that describes the technical activities of the project, including requirement analysis, design, coding, integration and testing. Looks like the tasks are performed In ad-hoc fashion. Jupiter probably has the plan in his head and he acts as seems appropriate with the arising situations.
Intergroup Coordination	To establish a means for the software engineering group to participate actively with the other engineering groups. This makes the project better able to satisfy the customers' needs effectively and efficiently.	We consider each individual at SSC as a software engineering group. We see that these groups interactions are coordinated and controlled. However, there are not any mechanism in place to ensure these smooth lines of communication. These interactions happen as need arises.
Peer Reviews	To remove defects from the software work products early and efficiently.	This effect is important and it can be implemented via inspections, structured walk thorough, or a number of other review methods. For SSC we are unaware of their testing procedures. There must be some personal inspections by each person after they finish their assigned task. This checking must be done in order for all the process steps to go smoothly.

We will use this model to comment on the recommendations for improvements in the process. These improvement areas are listed in Table -7 below.

Recommendations

Features	Interpretation
Commitment to Perform	SSC should have policy statements to emphasize the connection between organizational commitment and the process
Activities Performed	An organizational structure is absent in SSC. It is needed to support the key process areas for example, the quality assurance teams Access to special skills, adequate funding, and access to tools must be provided. A lack of these will result in poor work performance Formal and informal training of the staff is recommended as well
Measurements and analysis	At SSC, establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary can offer a great deal of process improvements. It keeps the project team focused onto the goal.
Measurements and analysis	Such measures as quality of training, effectiveness of management, and functionality and quality of software products can boost the SSC software development performance.
Verifying Implementation	Software quality assurance in the form of review/audit by the software quality assurance group is recommended

Table -7 CMM process improvement recommendations

Conclusion

A CMM evaluation and assessment was performed on the assigned process of a software service center. An in depth analysis of the process based upon CMM maturity levels key practices revealed that the process is in the initial stage (CMM maturity level 1). This stage is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics. To improve this process we recommended redesign in the areas of Commitment to perform, Ability to perform, Activities performed, Measurements and analysis, and Verifying implementation.

APPENDIX - II

"After the commercial department has obtained an OK both from the Municipality and from the management in Engineering, Max contacts the municipality and obtains the tapes and the list of additional requirements, that is, the request for personalized data treatment. Max then notifies Jupiter about the project start, and sends the tapes to Dorian. Dorian converts the data set in a format readable and processable by Engineering's internal servers with the help of Moll.

In the meantime, Max has notified Jupiter that the Municipality required a personalization: in particular, the Municipality requires that on-line normalization be carried out by externally, by the Municipality itself. Jupiter is the only one that has the skills for it, so he starts working.

When the archives are ready, Dorian sends them to Bruce, and then notifies Jupiter of the task completion. Bruce runs the batch procedures for normalization and upload, and notifies Jupiter when the task is complete.

When Jupiter completes the personalization, he notifies Bruce and waits for him to finish. Then it converts the archives for exporting them to the Municipality, and delivers them to Max with the Municipality, which is in charge of actually delivering the data.

The Municipality performs the on-line normalization, and then returns the data to Max.

Max then notifies Jupiter that the data are ready, and simultaneously delivers the data to Bruce who (thanks to Jupiter's personalization) can load the data and start the automatic filtering procedure.

When Bruce finishes, he notifies Jupiter, and passes the data to Frances. Frances performs the on-line filtering and when she finishes she notifies Jupiter and handles the archives to Bruce.

Bruce unloads the data from the conversion program and loads them into the main software: THEBIT. He informs Jupiter about it and then starts the data calculation procedure in THEBIT. When the calculation is over. Bruce presents the results to who in turn notifies both Max and the commercial interface that the product is ready and an invoice must be sent to the Municipality."

APPENDIX - III

Here's a list of questions that should be asked from the Software Service Center before proceeding with the CMM assessment.

1. Is the company currently employing CMM?

2. Is the work done in a team environment with well defined projects? If so, is there a project manager?

3. Are the employee roles defined?

4. Are the company rules and regulation, code of behaviour, company vision, etc. documented?

5. Are all the daily procedures documented? Is it routinely practiced?

6. Is there a quality assurance body to enforce the company rules and regulations?

7. Is there procedures in place to test and verify the finished products for the pre-set goals?

8. How are the contracts given to the customers? Is the customer-client relationship based on common understanding?

9. Is there effective actions taken when the project's performance deviates from the software goals?

10. Is there small checks or modular testing during the progress of the software procedure to see whether the software is on track?

11.\s there formal or informal training for the staff to keep up-to-date with the new skills and technology?

12. How do the engineering groups interact with each other? On average how often does this contact take place and by what means?

13. How are the conflicts between team members, or teams resolved? Is there a quality assurance committee responsible for this?

14. Is the knowledge gained from previous projects taken into use for the future or present projects?

15. What procedures were in place in case of crisis, such as a delay in the completion date of a project?

16. What mechanisms were set up for feedback on company products from the customers or the company employees?

Bibliography

Zahran, Sami. Software Process Improvement. Addison Wesley Longman. Essex. England: 1998.

Area of Maturity	Purpose	Application to the Service Center
Process Management	To control the process performance of the software project quantitatively. Software process performance represents the actual results achieved from following a software process.	We are simply not provided with enough information to decide whether or not the focus is on identifying special causes of variation within a measurably stable process and correcting, as appropriate, the circumstances that drove the transient variation to occur.
Software Quality Management	To develop a quantitative understanding of the quality of the project's software products and achieve specific quality goals.	Software Quality Management applies comprehensive measurement program to the software work products. In the case of SSC, we probably don't have product quality goals except the ones provided by the customer.

Area of Maturity	Purpose	Application to the Service Center
Defect Prevention	To identify the causes of defects and prevent them from recurring. This should lead to continuous improvements of the software process.	No such scenario is given in the assigned procedure.
Technology Change Management	To identify beneficial new technologies and transfer then into the organization in an orderly manner. Innovative technologies could lead to revolutionary process improvements	We don't have enough information to comment on its validity. No such scenario is given in the assigned procedure.
Process Change Management	To improve continually the software processes used in the organization with the intentions of improving software quality, increasing productivity and decreasing the cycle time.	The focus of technology change is performing innovation efficiently in an ever changing world of the software processes used. But unfortunately, we don't have enough information to comment on its validity in the case of SSC.