A FRAMEWORK APPROACH USING CMMI FOR

SPI TO INDIAN SME’S

M. Sivashankar A. M. Kalpana Dr. A. Ebenezer Jeyakumar,
Lecturer, Ph. D. Scholar Director (Academics),
GCE, Anna University, Sri Ramakrishna Engineering College,
Salem- 11. Coimbatore. Coimbatore.
pm.sivashankar@gmail.com kalpana.gce@gmail.com ebey@rediffmail.com

ABSTRACT encompasses both large and small organizations which

are called as Small and Medium Businesses (SMB) or
Software development is carried out in different Small and Medium Enterprises (SME). According to
methods and using several standards. Software Process
Improvisation (SPI) is the key for developing quality software.
Nasscom CEO Summit, November, 2008, software
Software development companies are not only big organizations industry generated revenue of US $12-15Billion in
but there are many small settings usually called SME (Small and exports and SMEs represent 85percent of NASSCOM
Medium Enterprises) or SMB (Small and Medium Business) Membership profile [2]. The SMB contribution to GDP
which plays a major role in the software industry. CMMI model
is applicable to small organizations also for process
has been growing at a steady rate of CAGR 12 percent
improvisation. The primary focus is to develop a framework to over the last seven years. Zinnov defines SMBs as
support the SPI in small organizations so that they meet their organizations having up to 999 employees. Out of the
business goals successfully along with adhering to CMMI total Indian SMB population, approximately 96 percent
standards.
of the SMBs have employee strength of 0 to 10, and
Keywords: SPI, CMMI, SME, SMB, framework there are roughly 33.8 million SMBs which belong to
this segment. Among the 11 to 1,000 employee
segment, there are roughly 1.3 million SMBs[3]. We
INTRODUCTION
consider SMBs / SMEs with 2 to 49 employee strength
as Small Scale Software Organization (SSSO).
A software process can be defined as an
Major problem faced by SSSOs planning to
environment of capable interrelated resources managing
implement process improvement program is large
a sequence of activities using appropriate methods and
companies overhead rates are not substantially affected
practices to develop a software product that conforms to
by their software process improvement programs, but it
customer’s requirements [11]. CMMI developed by
is a major overhead in their project budget for SSSO.
Software Engineering Institute Carnegie Mellon
Small companies are now frequently competing with
University is an upgradation of CMM model. It is one
large businesses for small contracts and they fear that
of the widely used models for SPI. Many companies
their competitive advantage of lower overhead rates
and organizations use the CMMI as a vehicle for SPI.
will be lost when paying for software process
Organizations have spent large amounts of money as
improvement programs [4]. To overcome the problems
well as considerable effort in implementing the
we propose a framework for implementing SPI standard
management practices prescribed by the CMMI.
in small software organization so that it support their
Despite these investments, the organizations have often
business goals and practice standards that improve them
expressed their concern that there is no appreciable
to attain level.
return on their investments. Many organizations are
reluctant to implement a CMMI-based software process
improvement program because the upper management
RELATED WORKS
does not want to commit itself to investing considerable
The motivation for carrying out process
efforts into process improvement without evidence of
assessment and improvement activities is to collect
positive effects to the corporate balance sheet. In
information as to what needs to be changed and to
addition, companies of smaller size are concerned that
establish how to pursue the improvements in order to
they cannot afford the up-front costs of implementing a
minimize development cost and maximize the quality
software process improvement program [1, 3].
of products produced [5]. Process assessment is utilized
The software industry in India is a key
to evaluate the capability of a process [6]. Existing
component of the national economy. Software industry
software engineering and organization development
literature acknowledges that there are fundamental
operational differences between small and large
organizations. Small organizations seem more
concerned about practice, while large organizations
seem more concerned about formal process [7]. Paquin
[8] identifies assessments, project focus,
documentation, required functions and maturity
characteristics as process issues for small organization.
Abbott [9] identifies six keys to software process
improvement in small organizations: Senior
management support, adequate staffing, applying
project management principles to process improvement,
integration with ISO 9001, Assistance from process
improvement consultants and focus on providing value
to projects and to the business. Johnson and Brodman
[10] identify seven small organization / small project
challenges: Handling requirements, Generating
documentation, managing projects, allocating
resources, measuring progress, conducting reviews and
providing training. Kuvaja [11] further supports that it
is quite difficult for any SME to choose an
improvement approach, and to apply it in their
organization without the help of external consultants or
substantial investment in the time of their software
managers. Cultural issues like resistance to change from
the employees or the management areas, who regard the
extra work required for quality assurance as a useless
and complicated burden put on the developing team.
The main problem of the small companies is that they
cannot afford to maintain substantial expertise of
software process improvement within their companies,
but they have to buy it from external sources. A further
problem related to the lack of expertise is to find how to
start the improvement and which experts to use. Due to
budget constraints, the services of a consultant
organization to improve the software quality are not
possible. Still the need for a good quality assurance
program is becoming more evident, and managers are
striving to achieve international quality standards that,
in the long run, result in lower production costs.
The various related works with their set of processes
that facilitated SPI are,
MoProSoft [12] proposes 6 processes (based on ISO
12207, CMM, ISO 9001): Business management,
Process Management, Project Management, Resource
management, Administration of specific projects and
Software development.
MPS.BR [13] proposes 23 processes (based on ISO
12207 and CMMI): Organizational innovation and
deployment, Causal analysis and resolution,
Organizational process performance, Quantitative
project management, Risk management, Decision
analysis and resolution, Requirement development,
Technical solution, Validation, Verification, Software
integration, Software installation, Product release,
Training, Process establishment, Process assessment
and improvement, a Tailoring process for project
management, Configuration management, Quality
assurance, Acquisition, Measurement, Project
management and Requirement management.
ADEPT [14] proposes 12 processes (based on CMMI):
Requirement management, Configuration management,
Project planning, Project monitoring & control,
Measurement & analysis, Process & product quality
assurance, Risk management, Technical solution,
Verification, Validation, Requirement development,
Product integration.
RAPID [15] proposes 8 processes (based on ISO
15504:1998): Requirement elicitation, Software
development, Configuration management, Quality
assurance, Project management, Problem resolution,
Risk management, Process establishment.
PROCESSUS [16] proposes 6 processes (based on
CMM and ISO 9001): Customer relationship
management, Project management, Software
engineering, Supporting activities, Process management
and Process automation
PROPOSED WORK
SPI plan should clearly indicate the current status of the
software development activities with their strengths and
weakness. CMMI is mainly adopted in large
organizations. CMMI version 1.2 it came with the
option that it can be implemented for small setting also
where there are less than 100employees or less than 20
members in a project. CMMI v1.2 can be represented in
two ways namely staged and continuous. Staged
representation, maturity levels provide a recommended
order for approaching process improvement.
Figure 1: Staged Representation.
 The maturity levels of an organization are
measured by the achievement of the specific and
generic goals that apply each set of process areas. In
Figure 1, the structure of the staged representation of
CMMI is shown.
Continuous consists of the same process areas
as the staged representation. However, no process area
is assigned to a particular maturity level. The
continuous representation uses six capability levels
(CLs) to measure the achievement of a specific process
area for an organization. They are:
− Incomplete (CL 0),
− Performed (CL 1),
− Managed (CL 2),
− Defined (CL 3),
− Quantitatively Managed (CL 4), and
− Optimizing (CL 5)
A capability level consists of related specific
and generic practices for a process area that can
improve the organization’s processes associated with
that area. Capability levels build on one another,
providing a recommended order for process
improvement. The continuous representation gives
software organizations the flexibility to select process
areas they want to improve, enabling them to select the
order that best meets their business objectives. We take
the continuous representation for our proposal.
Continuous process is classified into four categories
and it has 25 process areas, out of that we take 13
process area’s that suits the major business needs or
goals of the small software companies they are,
Figure 2: Continuous Process Representation
PROJECT MANAGEMENT:
1. Project Planning (PP)
2. Project Monitoring and Control (PMC)
3. Risk Management (RSKM)
ENGINEERING:
4. Requirements Management (REQM)
5. Requirements Development (RD)
6. Technical Solution (TS)
7. Verification (VER)
8. Validation (VAL)
9. Product Integration (PI)
PROCESS MANAGEMENT:
10. Organizational Training (OT)
11. Organizational Process Definition
+IPPD (OPD)
12. Organizational Process Focus (OPF)
SUPPORT:
13. Process and Product Quality
Assurance (PPQA)
With the help of Questionnaire and tools that
were designed to help the assessment in the respective
category, results and conclusion were drawn based on
the assessment. Each process area is assessed to find
out the current capability level, further the actions and
recommendations are suggested to improve the
capability level. If all of the base practices are
performed, then, the associated Specific Goals and
Generic Goals are satisfied and so, the Process Area is
rated at Capability Level 1(CL1) - Performed. Then it
be further improved to attain the level CL5 –
Optimizing. Similarly each level is assessed and
necessary steps were taken to improve that process to
attain CL5, if can’t reach in a single step, steps were
recommended to attain level CL5.
DISCUSSION
Figure 3: Specific Practices
The following components of the CMMI
Framework were under study: Specific Practices,
Specific Goals and Process Areas. We conducted a trail
and collected the information on the extent of
fulfillment of the specific practices and came to the
conclusions on the fulfillment of the specific goals and
process areas from them. Questions were asked if each
specific practice for the specific goal of the chosen
process area was being followed. Based on the
responses collected, scoring matrix was applied to the
response and the outcome was the score for the specific
practices. Figure 3 shows the sample scores for each
specific practice within each specific goal, in the order
of the process areas chosen. Specific practices for
Process Management indicate that they are at least,
partially managed.
Figure 4: Specific Goals
The specific practices of Organizational
Training are largely implemented, but for, record
keeping of the training, which is not implemented at all.
Specific practices of Project Management indicate that
the specific practices are largely implemented,
especially the periodic reviews which is strongly
implemented.
Looks like the projects remain on track with
the periodic reviews. Specific practices of Engineering
have most of the specific practices largely
implemented, with some of them as partially
implemented. Strengths in verification and validation
practices indicated that the right product is being
delivered because of this area. Some weakness in the
requirements management area is reflected. Specific
practices of the Support indicate lack of record keeping
for the configuration items. However, rests of the
specific practices are partially managed. This again
indicates that, if the present person in charge of the
work moves out of the project, it would be difficult to
keep up, as the information on present configuration is
not maintained in records anywhere. To study the
extent of fulfillment of the specific goals, we used the
score sheet of the specific practices. For scoring the
specific goals, we averaged scores of specific practices
within a specific goal. Figure 4 shows the results.
Specific goals of Process Management indicate that
most of the specific goals are partially managed with
some areas in training, largely managed.
Figure 5: Process Areas
Specific goals of Project Management indicate
that most of the specific goals are largely implemented.
Specific goals of Engineering are somewhere between
partially and strongly implemented. Mostly, the goals
involved with maintaining records fall short of
expectation. However, specific goals of verification and
validation are largely implemented. Specific goals of
Support indicate that a lot of specific practices are not
implemented at all, resulting in the specific goals to lie
between partially implemented and not implemented at
all. Calculating the average of all the specific goals
within a process area, the score sheet for the process
area is prepared and is shown in Figure 5. Process
Management and Support look partially managed,
while process areas of Project Management and
Engineering show more than just partial
implementations. Clear indications of strengths in
Project Monitoring and Control, Verification and
Validation process areas can be seen. Overall, the final
work product seems to keep the clients happy and
satisfied. The organization in study seems to be keeping
up its organizational goal.
CONCLUSION
To SMB/SME’s the full implementation of the
CMMI framework look likes overload. The framework
is very extensive to encompass all types and sizes of
businesses. The CMMI framework is designed to
provide a baseline to study the process standards.
Prudent implementation of the framework with right
choices of process areas for implementation is needed.
Remodeling the framework based on business need
would definitely help any size of business. In small
business environment, it is difficult to determine the
exact reasons for success or failure of projects,
especially when they are short-lived and numerous. Our
framework will help to analyze and improve the weaker
sections in a process area, this will help to achieve SPI
with some implementation of standards also.
REFERENCES
[1] Fergal Mc Caffery and Gerry Coleman ”The development of a
low-overhead assessment method for Irish software SMEs”
Journal of Information Technology Management, Volume
XVIII, Number 2, 2007, ISSN #1042-1319
[2] Raj Jain, PPT, “Nasscom CEO Summit 2008”, Dec 2008,
www.nasscom.com
[3] http://india.smetoolkit.org/india/en/content/en/42648/Is-the-
Indian-SMB-market-lucrative
[4] Minoo Shinde and Sajjan G. Shiva “CMMI Framework in Small
Business Environment – A Case Study”
[5] Abbott, J.J.: Software Process Improvement in a Small
Commercial Software Company. Proceedings of the 1997
Software Engineering Process Group Conference, San Jose, CA,
17-20. (1997)
[6] Dyba, T.: Factors of Software Process Improvement Success in
Small and Large Organizations: An Empirical Study in the
Scandinavian Context. Proceedings of the 9th European
software engineering conference (ESEC/FSE’ 03) September 1-
5, Helsinki, Finland, 148-157. (2003).
[7] Johnson, D. L., Brodman, J.G.: Applying the CMM to Small
Organizations and Small Projects. Proceedings of the 1998
Software Engineering Process Group Conference, Chicago, IL.
9-12 March. (1998).
[8] Kuvaja, P., Palo, J., Bicego, A.: TAPISTRY- A Software
Process Improvement Approach Tailored for Small Enterprises.
Software Quality Journal, 8, 149-156. (1999).
[9] Makinen, T., Varkoi, T.: Assessment Driven Process Modeling
for Software Process Improvement. PICMET 2008 Proceedings,
27-31 July, Cape Town, South Africa. (2008).
[10] Paquin, S.: Struggling with the CMM: Real Life and Small
Projects. in “Key Practices to the CMM: Inappropriate for Small
Projects?” panel, Rita Hadden moderator, Proceedings of the
1998 Sofware Engineering Process Group Conference, Chicago,
IL, 9-12 March. (1998)
[11] Pettersson, F., Ivarsson, M., Gorschek, T., Öhman, P.: A
practitioner’s guide to light weight software process assessment
and improvement planning. The Journal of Systems and
Software, 81, 972-995. (2008)
[12] Oktaba, H. MoProSoft®: A Software Process Model for Small
Enterprises. 2006. Proceedings of the First International
Research Workshop for Process Improvement in Small Settings.
Carnegie Mellon University. pp. 93-101.
[13] Weber, K., E. Araújo, A. Rocha, Machado, D. Scalet, and C.
Salviano, Brazilian Software Process Reference Model and
Assessment Method, in Computer and Information Sciences.
2005, Springer Berlin / Heidelberg. p. 402-411.
[14] McCaffery, F., P. Taylor, and G. Coleman, Adept: A Unified
Assessment Method for Small Software Companies. IEEE
Software, 2007. Vol. 42(1) pp. 24-31.
[15] Cater-Steel, A.P., M. Toleman, and T. Rout, Process
improvement for small firms: An evaluation of the RAPID
assessment-based method. Information and Software
Technology, 2005. Vol. in press December pp. 1-12.
[16] Horvat, R.V., I. Rozman, and J. Györkös, Managing the
complexity of SPI in small companies. Software Process:
Improvement and Practice. 2000. Vol. 5(1)March pp. 45-54.