ACM SIGSOFT Software Engineering Notes

Page 1

March 2014 Volume 39 Number 2

Agile, CMMI, RUP, ISO/IEC 12207...

Is There a Method in this Madness?
Francisco Jos Lpez-Lira Hinojo
TCPIP
+34 610438715
flopezlira@tcpip-es.com

ABSTRACT
Sometimes, a new software development project requires selecting or
proposing a particular model, methodology, or method, called
generically a Set of Practices (SoP). In this paper, we provide a twodimensional model for classifying and thus better understanding where
the different SoPs fit in for software development. The model is applied
to 27 different SoPs and the results are used to generate basic guidelines
for decision support. SoPs vary in both complexity (height) and
specialization (width). The larger the area (height x width) the more
time needed for implementation of the SoP. We suggest the following
advice: Make sure to establish a well-planned implementation project.
Make sure the SoP contains everything you need. Combining SoPs can
lead to success or failure, so be careful. Consider quality, productivity
and volatility of requirements in your decision. Decide whether you
need an SoP for one project or permanently. Dont design an SoP
yourself, at least not for the first time.

Categories and Subject Descriptors

D.2.9 [Software engineering]: Management Software process
models.

differentiate the SoPs we elaborated a classification schema based on

the complexity level or Height of the SoPs.

L1 - Technique A way to perform a task

L2 - Practice A system of tasks

L3 - Method A system of practices

L4 - Methodology A system of methods

L5 - Compendium A system of methodologies, methods,

practices or techniques

We define Principles as general guidelines based on a specific paradigm

or model. There can be principles at any complexity level. For example
the method SCRUM is based on Agile principles and the higher levels
of capability of the Software Engineering Institutes CMMI for
development are based on Statistical Process Control (SPC) principles.
Tools, on the other hand, are software programs or systems used for
partial or total automation of practices and techniques. Tools can be
mostly found in complexity levels from L1 to L3.
While this schema is not exact, it can help us establish the first
differences between SoPs.

General Terms
Management, Standardization, Theory.

L5 Compendium

Keywords
Software engineering, software lifecycle, development methods, project
management, CMMI, Cleanroom.

L4
- Methodology
L3
- Method

Though this be madness, yet there is method in't.

Polonius in The Tragedy of Hamlet, Prince of Denmark

L2
- Practice

by Shakespeare.

L1
Technique

1. INTRODUCTION
When facing a new software development project, sometimes
stakeholders are challenged with the decision of choosing the right
methodology or method. Selecting the wrong one can lead to problems
in the project and following the latest buzzword may not be the best
approach. There is also a risk that the selected methodology or method
does not contain everything we need for our software development
project. In this work we establish a way for stakeholders to distinguish
among different proposals (models, methodologies, standards and
methods), which we call Sets of Practices (SoP). In order to do this, we
define two classification schemes: one based in the complexity level of
each SoP (height) and the other based on how many specialization areas
are covered (width). Then we proceed to classify each SoP.

2. CLASSIFICATION MODEL
2.1 Complexity Levels (Height)
Not all SoPs contain the same amount of information. Some include just
a few practices while others have dozens of them. More practices lead
to more complexity and longer implementations. In order to

DOI: 10.1145/2579281.2579299

Figure 1. Complexity levels

2.2 Specialization Areas (Width)

We also need to understand which parts of the software development
organization are covered by an SoP. For this purpose, we define
specialization areas related to software development.

Management practices are oriented towards planning,

monitoring and controlling at three levels: Organization,
Process, and Project. Organization management has to do
with establishing and assuring the accomplishment of the
mission, vision, goals, and strategies of the whole software
development company. Process management considers the
adoption of a process vision and the definition, deployment,
and continuous improvement of processes. Project

http://doi.acm.org/10.1145/2579281.2579299

ACM SIGSOFT Software Engineering Notes

Page 2

management includes managing the core and support

practices needed in a project.

March 2014 Volume 39 Number 2

3. Analysis
Using our 2D model, we classify 27 SoPs grouped into 5 super-sets:

Core practices comprise those practices directly aimed at

developing the software product: requirements engineering,
architectural design, detailed design, and coding.

1.

Software Engineering Institute

2.

Agile

Support practices are value-enhancing activities, including

Quality management, Configuration Management, Change
management, Human Resource management and Supplier
management. Quality management enhances a teams hability
to prevent failures and correct mistakes while Configuration
management helps keep products consistent across the whole
projects; Change management establishes a formal way to
identify, register and approve changes in the scope of a
project or set of products; Human Resource management
includes recruitment, selection and development of team
members, and Supplier management involves practices for
establishing and supervising agreements with external
suppliers.

3.

Specific ISO/IEC and IEEE

4.

ISO/IEC 12207, ISO/IEC 29110 and MoProSoft

5.

PMBOK, Cleanroom Software Engineering and RUP

3.1 Software Engineering Institute SoPs

The Carnegie Mellon Software Engineering Institute (SEI) has been
working for almost 30 years in advancing the technologies and
practices needed to acquire, develop, operate and sustain software
systems. [1] Among the SoPs proposed by the SEI we can find the
Capability Maturity Model Integrated for Development (CMMI-DEV),
the Personal Software Process (PSP) and the Team Software Process
(TSP).
CMMI-DEV is a compendium of practices1 covering most of the needs
of a software development organization except for Organization
management practices.

This schema allows identifying the scope of the SoPs.

PSP is a methodology for programmers, containing practices and

techniques for planning, detailed design, coding and quality
management.
Support
practices

Core
practices

Project
Process
Organizational
management management management

TSP is a method and its techniques mainly focused on project

management practices. It was mainly designed for teams of
programmers trained in PSP.
Table 1. Sets of practices by specialization: SEI
PRACTICES

CMMI

PSP

TSP

A. Management practices
A1.Organizational
management
Figure 2. Specialization areas

2.3 2D Model
Using these two classification schemas we now can visualize a 2dimensional model for the SoPs based on their area:

A2. Process management

A3. Project management

B. Core practices

Height

B1. Requirements
engineering

B2. Architectural design

B3. Detailed design

B4. Coding

C1. Quality management

C2. Configuration
management

C3. Change management

C4. Human resource

management

C5. Supplier management

L5 - Compendium
L4 - Methodology
L3 - Method

C. Support practices

L2 - Practice
L1 - Technique

Support - Core - Project - Process - Organizational

Width

Figure 3. 2D model for classification of SoP

A word of caution: this model does not imply the more the better. The
right SoP will depend on the particular needs. For example, some SoPs
are only applied during the project, and they may not provide a way for
permanently keeping knowledge in an organization. Or there may not
be a need for support practices or project management because some
other organization has been assigned these tasks.

3.2 Agile SoPs

Agile includes SoPs based on the Agile manifesto. [2] This manifesto
states the principles adopted by several methods also classified as Agile,
1

DOI: 10.1145/2579281.2579299

CMMI-Dev does not include techniques.

http://doi.acm.org/10.1145/2579281.2579299

ACM SIGSOFT Software Engineering Notes

Page 3

such as SCRUM, Extreme programming (XP), and Agile Unified

Process, among others.
The SCRUM method was first presented at the Business Object Design
and Implementation Workshop in 1995[3]. It is a framework within
which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible
value. [4]

The IEEE has also developed many specific standards [10] related to
software development, for instance 1012 (Software verification and
validation), 828 (Software configuration management plans), 829
(Software test documentation), 730 (Software Quality management
Plans), and 1016 (Recommended Practice for Software Design
Descriptions).
Table 3. Sets of practices by specialization: Specific ISO/IEC and
IEEE

Extreme Programming or XP is a methodology created by Kent Beck

[5]. XP includes practices for Requirements engineering and analysis,
detailed design, coding, and testing. It also considers some practices for
planning.

PRACTICES

A2. Process management

A3. Project management

Table 2. Sets of practices by specialization: Agile

SCRUM

XP

Specific
ISO/IEC

15504
33014
16326
14143
16085

B. Core practices

AUP

A. Management practices
A1.Organizational
management

B1. Requirements
engineering

29148

B2. Architectural design

42010

A2. Process management

B3. Detailed design

A3. Project management

C. Support practices

C1. Quality management

25000
29119
18018

B2. Architectural design

B3. Detailed design

C2. Configuration
management

B4. Coding

C3. Change management

C2. Configuration
management

C3. Change management

C4. Human resource

management
C5. Supplier management

3.3 Specific ISO/IEC and IEEE SoPs

The International Electro-technical Commission (IEC) is part of
the International Organization for Standardization (ISO). The IEC is
the worlds leading organization for the preparation and publication of
International Standards for all electrical, electronic and related
technologies. [7] ISO/IEC has developed many standards [8] covering
specific areas. These include 16326 (Project Management plans), 14143
(Functional size measurement), 15026 (Systems and software
assurance), 15504 (Process assessment), 16085 (Risk management),
25000 (Software product Quality Requirements and Evaluation), 29119
(Software testing), 29148 (Requirements engineering), 33014 (Process
assessment - Guide for process improvement), 18018 (Guide for
configuration management tool capabilities), and 42010 (Architecture
description).
The IEEE is an association designed to serve professionals involved in
all aspects of the electrical, electronic and computing fields and related
areas of science and technology that underlie modern civilization. [9]

DOI: 10.1145/2579281.2579299

1012
829
730
828

C4. Human resource

management

C. Support practices
C1. Quality management

1016

B4. Coding

B. Core practices
B1. Requirements
engineering

Specific
IEEE

A. Management practices
A1.Organizational
management

Agile Unified Process (AUP) is a simplified version of the IBM

Rational Unified Process methodology. It describes a simple, easy to
understand approach to developing business application software using
agile techniques and concepts yet still remaining true to the Rational
Unified Process. [6]

PRACTICES

March 2014 Volume 39 Number 2

C5. Supplier management

3.4 ISO/IEC 12207, ISO/IEC 29110 and

MoProSoft
Another two ISO/IEC SoPs related to software development are
12207 (common framework for software lifecycle processes) and 29110
(Lifecycle profiles for Very Small Entities). ISO/IEC 12207
establishes a common framework for software life cycle processes,
with well-defined terminology, that can be referenced by the software
industry. It contains processes, activities, and tasks that are to be applied
during the acquisition of a software product or service and during the
supply, development, operation, maintenance and disposal of software
products. Software includes the software portion of firmware. [11]
ISO/IEC 29110 is aimed at software organizations having less than 25
members2 called Very Small Entities (VSE).
The extinct Mexican Association for Software Engineering Quality
(AMCIS3 is its acronym in Spanish) developed a process model for
software industry (MoProSoft is its acronym in Spanish), an SoP (at the
methodology level) for very small software development organizations.

ISO/IEC 29110 refers here to Part 5-1-1 Management and engineering

guide: Generic profile group: Entry profile

A non-profit Mexican organization devoted to disseminate best

practices in software engineering

http://doi.acm.org/10.1145/2579281.2579299

ACM SIGSOFT Software Engineering Notes

Page 4

March 2014 Volume 39 Number 2

This SoP was later used as a basis for the development of the ISO/IEC
29110 standard.
Table 4. Set of practices by specialization: 12207, 29110 and
MoProSoft
PRACTICES

12207

29110

PRACTICES

Cleanroom
SE

RUP

B2. Architectural design

B3. Detailed design

B4. Coding

MoProSoft

A. Management practices
A1.Organizational
management

PMBOK

C. Support practices

A2. Process management

A3. Project management

B1. Requirements
engineering

B2. Architectural design

B3. Detailed design

B4. Coding

C1. Quality management

C2. Configuration
management

C1. Quality management

C2. Configuration
management
C3. Change management

B. Core practices

C4. Human resource

management
C5. Supplier management

3.6 An Integral view of SoPs

The following figure contains an integral view of SoPs classified using
2D Model.

C. Support practices

C3. Change management

C4. Human resource
management

C5. Supplier management

3.5 PMBOK, CleanRoom SE and RUP

The Project Management Body of Knowledge (PMBOK) from the
Project Management Institute (PMI) provides project managers with
the fundamental practices needed to achieve organizational results and
excellence in the practice of project management. [12] The PMBOK
compendium contains practices for project management, quality
management, configuration, and change management, but not for core
practices.
The Cleanroom Software Engineering (CSE) methodology, developed
in the late 70s and early 80s by Harlan Mills, is a theory-based, teamoriented process for the economic production of high quality software.
IBMs Rational Unified Process (RUP) is a compendium that provides
industry-tested practices for software and systems delivery and
implementation and for effective project management. [13] RUP
contains methods, practices and techniques.

Table 5. Set of practices by specialization: PMBOK, CSE and RUP

PRACTICES

PMBOK

Cleanroom
SE

RUP

A. Management practices
A1.Organizational
management

Figure 4. SoPs classification at a glance

4. CONCLUSIONS
In this paper we present a two-dimensional model for understanding the
different proposals that contain practices for software development and
related areas. Our goal is to help stakeholders select the best SoP for
their particular needs. Some guidelines:
1.

Make sure to establish a well-planned implementation project.

The adoption of an SoP usually requires an implementation
project, which may vary in duration depending on the level of
complexity or Depth of the SoP, and also the specialization
areas it covers, or its Width. It may take from weeks
(methods) to months or years (compendiums).

2.

The implementation project must consider processes

(practices and techniques), people (training), and tools

A2. Process management

A3. Project management

B. Core practices
B1. Requirements
engineering

DOI: 10.1145/2579281.2579299

http://doi.acm.org/10.1145/2579281.2579299

ACM SIGSOFT Software Engineering Notes

Page 5

(selection and adoption). It is important to notice than the

implementation project also requires good practices of project
management and that you will face change resistance from the
members of your team or organization.
3.

4.

5.

6.

7.

Make sure the SoP contains everything you need. Other than
for the simplest projects, you will surely need Quality,
Configuration and Change management practices, which are
not included in all SoPs. Only some SoPs include specific
techniques, which means you may have to do some research.
The IEEEs Guide to the Software Engineering Body of
Knowledge (SWEBOK) [14] is a great source for practices
and techniques related to software development. No SoP, with
the exception of IBMs RUP, contains references to tools.
PMBOK covers project management and support practices,
but does not include core practices for software development.
Combining SoPs can lead to success or failure, so be careful.
Some SoPs are frequently used in combination, like SCRUM
and XP. Others were designed to work together, like TSP and
PSP. SCRUM, XP, Cleanroom SE, PSP and TSP can be
embedded in CMMI-Dev [15] [16] [17]. However, trying to
combine methodologies can be very hard while combining
compendiums is almost impossible.
Consider quality, productivity and volatility of requirements
in your decision. SoPs like Cleanroom approach and TSP and
PSP are oriented to projects where managers must prove they
develop high quality software, while Agile SoPs are more
suitable for projects that need to accommodate frequent
changes in requirements.
Decide whether you need an SoP for one project or
permanently. If you are in search of permanent improvement
in your organization, then look for SoPs that include practices
for Process management, like CMMI-Dev, ISO/IEC 12207 or
MoProSoft.
Dont do it yourself, at least not for the first time. You can, of
course, decide to develop your own SoP, but be willing to
accept that it can take you many months (even years) and that
it is a separate area of specialization.

March 2014 Volume 39 Number 2

[4] Ken Schwaber and Jeff Sutherland, July 2013, The SCRUM Guide,
The Definitive Guide to Scrum: The Rules of the Game, seen at
www.scrum.org
[5] Lee Copeland, December 3, 2001, Extreme programming.
Computer World. Seen at
http://www.computerworld.com/s/article/66192/Extreme_Program
ming
[6] http://www.ambysoft.com/unifiedprocess/agileUP.html
[7] http://www.iec.ch/about/
[8] http://www.iso.org/iso/catalogue_ics
[9] https://supportcenter.ieee.org/app/answers/detail/a_id/190
[10] http://standards.ieee.org/findstds/standard/software_and_systems_e
ngineering_all.html
[11] http://standards.ieee.org/findstds/standard/12207-2008.html
[12] http://www.pmi.org/en/PMBOK-Guide-and-Standards/StandardsLibrary-of-PMI-Global-Standards.aspx
[13] Rational Software, Rational Unified Process: Best practices for
software development teams, 1998, Cupertino, CA. Seen at
http://www.ibm.com/developerworks/rational/library/content/03Jul
y/1000/1251/1251_bestpractices_TP026B.pdf
[14] IEEE Computer Society, Guide to the Software Engineering Body
of Knowledge, 2004 Version. Seen at
http://www.computer.org/portal/web/swebok/htmlformat
[15] AgileDigm Incorporated, Agile/SCRUM Development using the
CMMI framework, 2010. Seen at
http://www.nasa.gov/ppt/482611main_2010_Tuesday_4_cmmi_Jo
hnson_Kent_Agile%20Scrum%20Development%20Using%20CM
MI%20v1.4a.ppt
[16] Hurtado y Bastarrica, Implementing CMMI using a combination of
Agile methods, CLEI Electronic Journal, Volume 9, Number 1,
Paper 7, June 2006
[17] Koch S. Alan, TSP can be the building blocks for CMMI,
Crosstalk, The Journal of Defense Software Engineering, March
2005

5. REFERENCES
[1] http://www.sei.cmu.edu
[2] www.agilemanifesto.org
[3]

Sutherland, Jeffrey Victor; Schwaber, Ken. 1995, Business object

design and implementation: OOPSLA '95 workshop proceedings.
The University of Michigan. p. 118. ISBN 3-540-76096-2

DOI: 10.1145/2579281.2579299

http://doi.acm.org/10.1145/2579281.2579299