ACM SIGSOFT Software Engineering Notes Page 1
Agile, CMMI®, RUP®, ISO/IEC 12207...
Is There a Method in this Madness?
Francisco José López-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 two-
dimensional 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. Don’t design an SoP
yourself, at least not for the first time.
Categories and Subject Descriptors
D.2.9 [Software engineering]: Management – Software process
models.
General Terms
Management, Standardization, Theory.
Keywords
Software engineering, software lifecycle, development methods, project
management, CMMI, Cleanroom.
Though this be madness, yet there is method in't.
Polonius in The Tragedy of Hamlet, Prince of Denmark
by Shakespeare.
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
March 2014 Volume 39 Number 2
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 Institute’s 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.
L5 -
Compendium
L4
- Methodology
L3
- Method
L2
- Practice
L1
-
Technique
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 March 2014 Volume 39 Number 2

management includes managing the core and support 3. Analysis

practices needed in a project. Using our 2D model, we classify 27 SoPs grouped into 5 super-sets:
 Core practices comprise those practices directly aimed at 1. Software Engineering Institute
developing the software product: requirements’ engineering,
architectural design, detailed design, and coding. 2. Agile

 Support practices are value-enhancing activities, including 3. Specific ISO/IEC and IEEE
Quality management, Configuration Management, Change 4. ISO/IEC 12207, ISO/IEC 29110 and MoProSoft
management, Human Resource management and Supplier
management. Quality management enhances a team’s hability 5. PMBOK, Cleanroom Software Engineering and RUP
to prevent failures and correct mistakes while Configuration
management helps keep products consistent across the whole 3.1 Software Engineering Institute SoPs
projects; Change management establishes a formal way to The Carnegie Mellon Software Engineering Institute (SEI) has been
identify, register and approve changes in the scope of a working for almost 30 years in “advancing the technologies and
project or set of products; Human Resource management practices needed to acquire, develop, operate and sustain software
includes recruitment, selection and development of team systems.” [1] Among the SoPs proposed by the SEI we can find the
members, and Supplier management involves practices for Capability Maturity Model Integrated for Development (CMMI-DEV),
establishing and supervising agreements with external the Personal Software Process (PSP) and the Team Software Process
suppliers. (TSP).
This schema allows identifying the scope of the SoPs. CMMI-DEV is a compendium of practices1 covering most of the needs
of a software development organization except for Organization
management practices.
PSP is a methodology for programmers, containing practices and
techniques for planning, detailed design, coding and quality
management.
TSP is a method and its techniques mainly focused on project
management practices. It was mainly designed for teams of
Support Core Project Process Organizational
practices practices management management management 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 A2. Process management 

2.3 2D Model A3. Project management   

Using these two classification schemas we now can visualize a 2- B. Core practices
dimensional model for the SoPs based on their area:
B1. Requirements

Height engineering
B2. Architectural design 
L5 - Compendium
B3. Detailed design  
L4 - Methodology
B4. Coding  
L3 - Method
C. Support practices
L2 - Practice
C1. Quality management  
L1 - Technique C2. Configuration

Width management
Support - Core - Project - Process - Organizational
C3. Change management 
Figure 3. 2D model for classification of SoP C4. Human resource

A word of caution: this model does not imply ‘the more the better.’ The management
right SoP will depend on the particular needs. For example, some SoPs C5. Supplier management 
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 3.2 Agile SoPs
other organization has been assigned these tasks. Agile includes SoPs based on the “Agile manifesto.” [2] This manifesto
states the principles adopted by several methods also classified as Agile,

1
CMMI-Dev does not include techniques.

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

ACM SIGSOFT Software Engineering Notes Page 3 March 2014 Volume 39 Number 2

such as SCRUM, Extreme programming (XP), and Agile Unified The IEEE has also developed many specific standards [10] related to
Process, among others. software development, for instance 1012 (Software verification and
validation), 828 (Software configuration management plans), 829
The SCRUM method was first presented at the Business Object Design (Software test documentation), 730 (Software Quality management
and Implementation Workshop in 1995[3]. It is “a framework within Plans), and 1016 (Recommended Practice for Software Design
which people can address complex adaptive problems, while Descriptions).
productively and creatively delivering products of the highest possible
value.” [4] 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, Specific Specific
PRACTICES
detailed design, coding, and testing. It also considers some practices for ISO/IEC IEEE
planning. A. Management practices
Agile Unified Process (AUP) is a simplified version of the IBM A1.Organizational
Rational Unified Process methodology. “It describes a simple, easy to management
understand approach to developing business application software using 15504
A2. Process management
agile techniques and concepts yet still remaining true to the Rational 33014
Unified Process.” [6] 16326
A3. Project management 14143
Table 2. Sets of practices by specialization: Agile 16085
PRACTICES SCRUM XP AUP B. Core practices
A. Management practices B1. Requirements
29148
engineering
A1.Organizational
management B2. Architectural design 42010
A2. Process management B3. Detailed design 1016

A3. Project management    B4. Coding

B. Core practices C. Support practices
B1. Requirements 1012
  25000
engineering C1. Quality management 829
29119
B2. Architectural design  730
C2. Configuration 828
B3. Detailed design   18018
management
B4. Coding   C3. Change management
C4. Human resource
C. Support practices
management
C1. Quality management   C5. Supplier management
C2. Configuration

management
C3. Change management  3.4 ISO/IEC 12207, ISO/IEC 29110 and
C4. Human resource MoProSoft
management Another two ISO/IEC SoPs related to software development are
12207 (common framework for software lifecycle processes) and 29110
C5. Supplier management (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
3.3 Specific ISO/IEC and IEEE SoPs industry. It contains processes, activities, and tasks that are to be applied
The International Electro-technical Commission (IEC) is part of during the acquisition of a software product or service and during the
the International Organization for Standardization (ISO). The IEC is supply, development, operation, maintenance and disposal of software
“the world’s leading organization for the preparation and publication of products. Software includes the software portion of firmware.” [11]
International Standards for all electrical, electronic and related ISO/IEC 29110 is aimed at software organizations having less than 25
technologies.” [7] ISO/IEC has developed many standards [8] covering members2 called Very Small Entities (VSE).
specific areas. These include 16326 (Project Management plans), 14143
(Functional size measurement), 15026 (Systems and software The extinct Mexican Association for Software Engineering Quality
assurance), 15504 (Process assessment), 16085 (Risk management), (AMCIS3 is its acronym in Spanish) developed a process model for
25000 (Software product Quality Requirements and Evaluation), 29119 software industry (MoProSoft is its acronym in Spanish), an SoP (at the
(Software testing), 29148 (Requirements engineering), 33014 (Process methodology level) for very small software development organizations.
assessment - Guide for process improvement), 18018 (Guide for
configuration management tool capabilities), and 42010 (Architecture
description). 2
ISO/IEC 29110 refers here to Part 5-1-1 Management and engineering
The IEEE is an association “designed to serve professionals involved in guide: Generic profile group: Entry profile
all aspects of the electrical, electronic and computing fields and related 3
A non-profit Mexican organization devoted to disseminate best
areas of science and technology that underlie modern civilization.” [9] practices in software engineering

DOI: 10.1145/2579281.2579299 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 PMBOK Cleanroom RUP
PRACTICES
29110 standard. SE
B2. Architectural design  
Table 4. Set of practices by specialization: 12207, 29110 and
MoProSoft
B3. Detailed design  
PRACTICES 12207 29110 MoProSoft
B4. Coding  
A. Management practices
C. Support practices
A1.Organizational
  
management C1. Quality management 
A2. Process management   C2. Configuration  

management
A3. Project management     
C3. Change management 
B. Core practices C4. Human resource 
B1. Requirements management
  
engineering C5. Supplier management 
B2. Architectural design   
B3. Detailed design   
3.6 An Integral view of SoPs
B4. Coding    The following figure contains an integral view of SoPs classified using
C. Support practices 2D Model.

C1. Quality management   

C2. Configuration
 
management
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, team-
oriented process for the economic production of high quality software.”
IBM’s 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. Figure 4. SoPs classification at a glance

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

PMBOK Cleanroom RUP In this paper we present a two-dimensional model for understanding the
PRACTICES
SE different proposals that contain practices for software development and
A. Management practices related areas. Our goal is to help stakeholders select the best SoP for
their particular needs. Some guidelines:
A1.Organizational
management 1. Make sure to establish a well-planned implementation project.
The adoption of an SoP usually requires an implementation
A2. Process management
project, which may vary in duration depending on the level of
A3. Project management    complexity or Depth of the SoP, and also the specialization
areas it covers, or its Width. It may take from weeks
B. Core practices (methods) to months or years (compendiums).
B1. Requirements  2. The implementation project must consider processes

engineering (practices and techniques), people (training), and tools

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

ACM SIGSOFT Software Engineering Notes
(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. 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 IEEE’s 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 IBM’s RUP, contains references to tools.
PMBOK covers project management and support practices,
but does not include core practices for software development.
4. 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.
5. 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.
6. 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.
7. Don’t 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.
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
Page 5 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/Standards-
Library-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
http://doi.acm.org/10.1145/2579281.2579299