Capability Maturity Model Integration Is A Tool For Implementing Best Practices Accounting Essay



Software measurement, in order to be effective, must be focused on specific goals; applied to all life-cycle products, processes and resources; and interpreted based on characterization and understanding of the organizational context, environment and goals (Basili, et al., 1994).

Software maintenance, according to the IEEE definition, is a modification of a software product after delivery in order to correct faults, to improve performance or other attributes, to adapt a product to a changed environment, or to improve the product maintainability (Pigosky, 1997).

CMMI-Capability Maturity Model Integration is a tool for implementing best practices for activities concerning products and services in organizations (Chrisses et al. 2007). It was the Software Engineering Institute (SEI) that first began the work with Capability Mauturity Models, and published a book about the subject in 1995. The CMMs have meant success for many organizations; they have gained increased productivity and quality, and more accurate estimates on time and resource consumption (Chrisses et al., 2007). The CMMs was developed to be applied to different specific areas. Three of these models, The Capability Maturity Model for Software (SWCMM), The Systems Engineering Capability Model and The Integrated Product Development Capability Maturity Model were used as source material to develop the CMMI, the CMMI development team at SEI combined these models and built a framework that can be used in multiple disciplines and that has a flexibility to support different approaches (Chrisses et al. 2007). In this thesis the focus is on CMMI for development.

Lady using a tablet
Lady using a tablet


Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

The main purpose of our system is to automate the SM measurement by building an intelligent agent system-based CMMI.

1.1 Problem Statement

To organize the extracted of SM, it is important to classify its information needs. Here, the concept of "measurement" is used; this makes it possible to take a snapshot of each maturity level defined in CMMI without going into too much detail (CMMI PRODUCT TEAM, 2006; ABRAN, 2005). As well as Measurement does not truly or accurately reflect process maturity and tasks difficulty (Humphrey, 2009). Changes to SM processes measurement due to corrective, preventive and perfective maintenance may affect the way users use the measurement. This combined CMMI and agent-based tool technique should be properly managed to allow users easier and automated access to measure the SM using an appropriate ruler to measure process maturity.

1.2 Research Questions

In order to expand the above research problem, the following sub-problems need to be answered:

What is the instrument to measure software maintenance effectiveness?

What is the unit for the measurement?

Is the instrument construct valid?

1.3 Research Objectives

The main objectives of this research are:

To identify the processes of SM and the key activities of the software maintenance organization that impact performance, and which are to be used for measurement.

To formulate a model of CMMI and architecture of multi agent system (MAS) in collaborative software maintenance environment.

To develop and implement an agent-based CMMI tool.

To assess the above CMMI tool's effectiveness and measure its performance.


Many factors must be taken into account before measuring software maintenance processes (Pfleeger, S.L., Bohner, S., 1990). One strategy is to identify the key activities of the process. These key activities have characteristics, which can be measured, but, before measures can be identified, it is essential that the software maintenance processes be defined. Software maintenance measurement prerequisites were presented in April and Al-Shurougi (Desharnais, et al., (1997): 1) definition of maintenance work categories; 2) implementation of a process for requests management; 3) classification of maintenance effort in an activity account data chart (billable/unbillable); 4) implementation of activity management (time sheet) software, data verification; and 5) measurement of the size of change requests.

The SEI (CMMi, 2002) describes process measurement activities as appearing at maturity level 2. This confirms the need for a defined process before measurement can be initiated. While the SEI's recommended measures could have been a starting point for maintainers, (Pigoski, 1997) noted that those measures were created from a development perspective and do not capture the unique features of software maintenance.

Other authors (McGarry, J., 1995; Desharnais, et al., 1997) confirm this view, and specify that a software maintenance measurement program must be planned separately from that of the developers: because the measurement requirements are different, software maintenance measures are more focused on problem resolution and on the management of change requests. Higher-maturity organizations have established a maintenance measurement program.

Lady using a tablet
Lady using a tablet


Writing Services

Lady Using Tablet

Always on Time

Marked to Standard

Order Now

Two different perspectives of maintainability are often presented in the software engineering literature (Lagu, &, April., 1996). From an external point of view, maintainability attempts to measure the effort required to diagnose, analyze, and apply a change to specific application software. From an internal product point of view, the idea is to measure the attributes of application software that influence the effort required to modify it. The internal measure of maintainability is not direct, meaning that there is no single measure of the application's maintainability and that it is necessary to measure many sub-characteristics in order to draw conclusions about it (Pressman, 2001).

The IEEE 1061 standard (IEEE standard, 1988) also provides examples of measures without prescribing any of them in particular. By adopting the point of view that reliability is an important characteristic of software quality, the IEEE 982.2 Guide proposes a dictionary of measures.


This research shall be carried out in five phases as illustrated in Figure 1

Phase 4-1 - Requirements

Phase 4-4 - Verification & Validation

Phase 4-3 - Design and implementation

Phase 4-2 - Analysis

Phase 2 - Pre & Post-Survey on measurement attributes in SM and CMMI

Phase 5 - Evaluation

Phase 3 - Formulate the SM Measurement Model based CMMI

Phase 4 - Develop the Model

Phase 1 - LR and Analysis of measurement attributes in SM and CMMI

Figure 1: Research Methodology Framework

3.1 Phase 1 - LR and Analysis of measurement attributes in SM, MAS and CMMI

This phase involves evaluation of existing measurement attributes of software maintenance processes and activities and literature reviews on academic journals, software maintenance books, and other tools supporting software maintenance activities.

3.2 Phase 2 - Conduct Pre & Post-Survey on measurement attributes in SM, MAS and CMMI

Questionnaire survey shall be used to evaluate the different maintenance measurement models used by selected SM organizations in some universities, Kingdom of Saudi Arabia. The survey shall cover collaborative activities and knowledge required within the SMP and CMMI measurement tools.


The stage of post-survey will be collected and analyzed after the development of the system.

3.3 Phase 3 - Formulate the SM Measurement Model based CMMI

The next step is to formulate new measurement model of applying MAS based CMMI for collaborative software maintenance based on earlier literature reviews and pre-survey results

3.4 Phase 4 - Develop the Model

The model development followed the software development life cycle (SDLC) that include the following steps:



Design and implementation

Verification & Validation

3.4.1 Phase 4-1 - Requirements

Our entire system requirements will be identified in this stage.

3.4.2. Phase 4-2 - Analysis

Our entire system requirements will be analyzed in this stage.

3.4.3 Phase 4-3 - Design and implementation

Based on the identified SM processes and activities, the MAS design shall be specified to determine the types of agents, events, protocols and agent capabilities, using the Prometheus methodology (Padgham, L., & Winikoff, M., 2004). The methodology has a good modeling tool and can be used to generate initial codes that can be used by Agent-oriented tools such as Jack Agent development tool. Prometheus steps are as follows:

Systems specification - identify goals, use case scenarios,

functionalities, actions(outputs) and percepts (inputs).

Architectural design - determine agent types based on data coupling, agent acquaintance and interaction diagram.

Detailed design - refine the agent descriptions by defining and describing the capabilities and plans

The next step is to develop the prototype of Agent-Based CMMI. The platform and development tool shall be determined at a later stage.

3.4.4 Phase 4-4 - Verification & Validation

This is an iterative process, whereby the tools are tested and reworks and enhancements are carried out. We expect several builds are required to stabilize the application.

3.5 Phase 5 - Evaluation

Data evaluation is proposed for each of the following dimension:

Different SM types

Different SM process and applications


The proposed agent-based CMMI model composed of four types of agents described as follows:

4.1 Personal Agent (PA): Main responsibility of this agent is acts as an effective bridge between the user and the rest of the agents. Such agents actively assist a user in operating an interactive interface.

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

4.2 Maintenance Type Agent (MTA): Main responsibility of this agent is to provide the system by the type of software maintenance that willing to be measured.

4.3 Key Process Area Agent (KPAA): Main responsibility of this agent is to provide the system by the KPA of CMMI to measure the software maintenance type.

4.4 Ruler Agent (RA): Main responsibility of this agent is to translate the output of the measurement scale from the number to the ruler measurement style.


5.1 Practical Contribution

The study shall develop and implement an agent-based CMMI which shall be used to support the measurement for all the types of SM. The model shall serve to validate the usage of software agents to assist users to easy measure the SM.

5.2 Methodological Contribution

Three main contributions are expected from this study, as follows:

• Methodology to design Agent types and architecture for agent-based CMMI in Collaborative SM

• Methodology to evaluate the CMMI tools

5.3 Theoretical Contribution

The study shall contribute, to the body of knowledge, the conceptual agent-based CMMI Framework for collaborative SM types.