Hybriding CMMI and Requirement Engineering Maturity
& Capability Models
Applying the LEGO Approach for Improving Estimates
Luigi Buglione
1
, Jean Carlo Rossa Hauck
2
, Christiane Gresse von Wangenheim
2
and
Fergal Mc Caffery
3
1
Industry & Services BU, Engineering.IT SpA, Rome, Italy
2
Computer Science, UFSC - Federal University of Santa Catarina, Florianopolis, Brazil
3
Computing and Maths, Dundalk Institute of Technology, Dundalk, Ireland
Keywords: Process Appraisals, Process Improvement, CMMI, ISO/IEC 15504, LEGO, Requirement Management,
Maturity & Capability Models.
Abstract: Estimation represents one of the most critical processes for any project and it is highly dependent on the
quality of requirements elicitation and management. Therefore, the management of requirements should be
prioritised in any process improvement program, because the less precise the requirements gathering,
analysis and sizing, the greater the error in terms of time and cost estimation. Maturity and Capability
Models (MCM) represent a good tool for assessing the status of a set of processes, but an inner limit of any
model is its scope and approach for describing a certain issue. Thus, integrating two or more models with a
common area of focus can offer more information and value for an organization, keeping the best
components from each model. LEGO (Living EnGineering prOcess) is an approach projected for this
purpose. This paper proposes a LEGO application hybridizing a ‘horizontal’ model (a MM containing
processes going through the complete supply chain, from requirements right through to delivery, e.g. CMMI
or ISO 12207/15504) with a few specific ‘vertical’ models (MMs with focus on a single perspective or
process category, e.g. TMMi or TPI in the Test Management domain, P3M3 and OPM3 in the Project
Management domain) for Requirement Engineering.
1 INTRODUCTION
One of the latest neologisms from the last 5 years is
‘glocal’(Swyngedouw, 1997), which refers to the
ability to think globally and act locally”. Cultural
differences among countries should be taken into
account more and more when designing processes,
particularly as very interesting ideas may arise from
a comparison among different practices. For
instance, when comparing Western and Eastern
worlds and behaviours, Western people ‘act’,
Eastern people ‘think’ (a bit more) before acting
(Hassan et al., 2010) (Luo, 2008) (Chang, 2010). But
observing both perspectives and attitudes, it is
possible to represent it as a sort of ‘yin-yang’,
complementing each other (Stawicki, 2008). Thus,
there is never a better idea, but different shades to be
considered when (re)designing a process and/or a
technique.
Estimation is one of the core processes in any
organization. According to the Webster-Merriam
dictionary, it is “1. a judgment or opinion about
something; 2. the act of judging the size, amount,
cost, etc., of something : the act of estimating
something; 3. a guess about the size, amount, cost,
etc., of something”. PMBOK defines estimation as
“a quantitative assessment of the likely amount or
outcome. Usually applied to project costs, resources,
effort, and durations and is usually preceded by a
modifier (i.e., preliminary, conceptual, feasibility,
order-of-magnitude, definitive)” (PMI, 2008).
However, estimates often have a higher error rate
than expected, by running a RCA (Root-Cause
Analysis) for detecting issues, it is possible to
remove issuing surrounding requirements. The top-
10 of estimation “deadly sins" (McConnell, 2002)
(McConnell, 2006) can be a valid starting point for
improving it, noting how much the missing (or the
low quality) of requirements and its related historical
data as well their granularity level could largely
impact on the estimation process. Using again
CMMI-DEV elements, Project Planning (PP)
55
Buglione L., Hauck J., Gresse von Wangenheim C. and Mc Caffery F..
Hybriding CMMI and Requirement Engineering Maturity & Capability Models - Applying the LEGO Approach for Improving Estimates.
DOI: 10.5220/0004082700550061
In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 55-61
ISBN: 978-989-8565-19-8
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
process area where estimation is run in the
‘Related Process Areas’ includes also Requirement
Management (RM) and Requirement Development
(RD) for the management of requirements; PP SP1.2
affirms that “The estimates should be consistent with
project requirements to determine the project’s
effort, cost, and schedule”. It’s the same when using
the SPICE (ISO/IEC 15504) language, dealing with
MAN.3 (Project Management) for estimates and
ENG.1 (Requirements Elicitation) plus ENG.4
(Software Requirement Analysis) (Buglione et. al.,
2012)..Thus, there is a huge need for any
organization to first reinforce the Requirement
Management process (in a broader sense, not strictly
in the CMMI terms because it’s a ML2 process
area), starting from elicitation and analyzing (RD
Requirements Development, ML3) throughout
requirements management.
But what’s the problem? What does not currently
exist?
The aim of this paper is to propose a LEGO
(Living EnGineering prOcess) application for the
Requirements Engineering (RE) area, matching
together different RE processes using a four-step
process, in order to obtain a comprehensive process
to be applied in an organization, which could enable
better estimates to be achieved.
The paper is organized as follows: Section 2
proposes a series of specific requirements
management maturity models and frameworks, for
extracting any possible element of interest (EoI) for
reinforcing a typical Requirements Engineering
(horizontal) process. Section 3, summarizes the
LEGO approach, with its main elements and four-
step process. Section 4, shows the deployment of
LEGO to the Requirements Management process,
joining the CMMI-DEV RD process area with the
EoI from the previously examined RE
models/frameworks. Finally, Section 5 provides
some conclusions and the next steps for this work.
2 REQUIREMENT
ENGINEERING: SOME
MATURITY & CAPABILITY
MODELS (MCM)
During the ‘90s the ‘maturity models mania’ started
(Copeland, 2003) and now many ‘something-maturity-
model(s)’ exist in many application areas and
domains, and this is also the case for (software) RE.
Table 1, presents some Maturity Models in the RE
arena that can represent potential “vertical” models
to be integrated into a consolidated and well known
“horizontal” model such as CMMI-DEV (SEI, 2010)
or SPICE (ISO/IEC 15504) (ISO, 2007).. The
specific processes to be involved would be
respectively: RD (Req. Development) and RM (Req.
Management) for CMMI_DEV and ENG.1 (Req.
Elicitation) and ENG.4 (Software Design) processes
for SPICE. For each of the models we present: its
representation types, number of MLs, process
architecture type and further comments/notes.
Some comments about those RE models that could
be useful for the LEGO analysis:
A general trend in RE is to propose staged models
more than continuous ones suggesting a
‘standard’ way to progress maturity within an
organization more than focusing upon each single
RE process. This provides interesting information
should be considered when re-modelling these
models into a target model according to its
process architecture.
No particular architectural elements have been
introduced/modified against well-known
horizontal models, differently than in other
application domain (e.g. see P3M3 (OGC, 2006)
and OPM3 (PMI, 2008) in the Project
Management) there is evidence that many of
those models are still maturing and evolving (e.g.
(Beecham et al., 2003) and (Solemon et al., 2009)
have deployed only details for ML2).
Documentation should be provided to fully
describe the requirements and project scope
this is a point of contact with Quality
Management Systems (QMS) such as ISO 9001 or
20000-1, this is typically stressed less in CMMI
constellations (see also the results from Mutafeljia
& Stromberg’s mapping (Mutafelija, 2008)) but
thus is not the in SPICE related models (including
a specific process on Documentation: SUP.7).
Another interesting related issue concerns the
quest for reducing requirements volatility (e.g.
REAIMS) and defining a taxonomy of
requirement attributes for properly managing
them by interest groups and/or techniques (e.g.
REPM), for instance, making a clear distinction
between functional vs. non-functional product
requirements from the outset. This is a relevant
issue in the FSM (Functional Size Measurement)
community, where there is often at the practical
level a misconception about the roles and
relevance of NFR (Non-Functional Requirements)
against FUR (Functional User Requirements) in
the estimation process, where NFR are typically
underestimated because not properly evidenced
(and sized) from the requirement elicitation phase.
ICSOFT 2012 - 7th International Conference on Software Paradigm Trends
56
Table 1: Some Requirement Engineering Maturity
Models/Frameworks.
Model/
Framework
Repr.
Type
ML (#)
Architect-
Type
Comments/Notes
IBM RMM
(Heurmann,
2003)
(Sehlhorst,
2007)
6 [0-5]
Level-based
---
IAG RMM
(IAG, 2009)
6 [0-5]
Matrix-
based
6 dimensions
(process, practices
& techniques,
deliverables,
technology,
organization, staff
competency)
PRTM
CRMM
(Hepner,
2006)
4 [0-3]
Level-based
---
BTH REPM
Gorschek et al,
2002)
(Gorschek,
2011)
Process-
based
7 processes
Variable number of
sub-process areas
per process
REAIMS
Process MM
(Sommerville,
2005)
3 [1-3]
Process-
based
8 process areas and
66 practices (basic,
intermediate,
advanced)
R-CMM
(Beecham et
al. 2005)
(Beecham et
al., 2003)
5 [1-5]
Process-
based
‘Processes’ =
Practices (e.g. 20
‘processes’ at ML2)
- Adaptation of
GQM for deriving
practices
R-CMMi
(Solemon et
al., 2009)
5 [1-5]
Process-
based
‘Processes’ =
Practices (e.g. 20
‘processes’ at ML2)
- Adaptation of
GQM for deriving
practices using the
CMMI process
architecture
The allowed choices for the “Architectural Type”
column are: Level-based (high-level depth, generic
description of needed actions per ML), e.g. (Ambler,
2010); Matrix-based (mid-level depth, indication of
a series of improvement drivers with a specific text
per each cell), e.g. (ISO, 2009); Process-based (low-
level depth, with a consistent process architecture
and repeatable elements per each defined process),
e.g. (SEI, 2010)(ISO, 2007).
3 EXPERIENCING LEGO TO
REQUIREMENT
ENGINEERING
3.1 The LEGO Approach
Recently we proposed a common-sense approach,
called LEGO (Living EnGineering prOcess)
(Buglione et al., 2011) for stimulating organizations to
improve their own processes, taking pieces (such as
the real LEGO bricks) from multiple, potential
information sources to be integrated to form a
unique, reinforced picture for a particular process or
set of processes. The starting point for this paper
is that any model/framework can represent only a
part of the observed reality, not all of its possible
views, simply because it needs to represent one
single viewpoint at a time. Thus, through handling
similar elements from different sources, we can
hopefully find more ‘fresh blood’ for improving the
organizational processes.
LEGO has four main elements, as shown in
Figure 1:
Figure 1: The four elements of the LEGO approach.
1. a ‘Maturity & Capability Models’ (MCM)
repository (www.gqs.ufsc.br/mcm), from
relevant processes or MMs (meaning also the
other dimensions not yet the process
dimension) can be identified;
2. knowledge about the process architecture of each
model, for understanding how to transform
desired elements from a certain model into the
target format, especially when considering that
the source models may have different
architectures that need to be integrated into a
single model;
3. mapping(s) & comparisons between relevant
models, in order to understand the real
differences or the deeper level of detail from
‘model A’ to import into ‘model B’;
4. a process appraisal method (PAM) to be applied
on the target BPM (Business Process Model).
LEGO has also a related four-step process:
Hybriding CMMI and Requirement Engineering Maturity & Capability Models - Applying the LEGO Approach for
Improving Estimates
57
1. Identify your informative/business goals:
clearly identify your needs, moving from the
current BPM version and content.
2. Query the MCM repository: browse the MCM
repository, setting up the proper filters in order to
obtain the desired elements (processes; practices;
etc.) to be inserted in the target BPM.
3. Include the selected element(s) into the target
BPM: include the new element(s) in the proper
position in the target BPM (e.g. process group,
maturity level, etc.).
4. Adapt & Adopt the selected element(s):
according to the process architecture of both
process models (the target and the source one), the
selected elements may need to be adapted,
tailoring such elements as needed.
3.2 Applying LEGO to Requirement
Engineering
One of the main requirements for improving
estimates is to reinforce the management of
requirements from an overall viewpoint, from their
elicitation through to the day-to-day management.
The focus of this work is exclusively on external
models as opposed to actual (living and active)
organizational practices, so that any reader can
easily access to the original sources and fully
understand the LEGO process, that could
(eventually, if interested) be replicated in his/her
own organization through forward moving from
their existing organizational Business Process
Model (BPM). Our aim is to show how to hybridize
ideas for obtaining a better and more comprehensive
final result. Thus, we list the preconditions, process
and main results from the application of the LEGO
process to the Requirements Engineering (RE)
domain, in order to propose a better RE process that
may be applied in an organization:
1. Identify your informative/business goals:
improve the estimation capability and results by a
refinement in the overall management of
requirements (business, technical):
2. Query the MCM repository: in this paper we
consider CMMI-DEV RE processes (RD; RM) as
the baseline for working upon, adding eventual
practices from the other RE models/frameworks
listed in Table 1. After a detailed analysis, we
discarded the IBM RMM, proposing only a high-
level staged path with no detailed elements, and
focus on the remaining ones. Table 2 proposes the
list of potential elements of interest (EoI) to
consider for improving CMMI processes on RE.
Table 2: RE Maturity & Capability Models (MCM):
Elements of Interest.
Model/
Framework
Elements of Interest (EoI)
IAG RMM
Technology: the introduction of workflow
environments for easily sharing information for
keeping requirements could be useful CMMI-
DEV RD GP2.3 (Elaboration section in Part 1)
Staff competency: suggested the introduction of
Bloom’s levels as informative notes for all GP
2.5, not only for those two PAs
PRTM CRMM
Level 1: link between product and customer
requirements, using e.g. QFD (quality function
deployment) it could be introduced also in
CMMI-DEV RD SP 3.4, not only in SP 2.1 (as
currently done) for closing the analysis
BTH REPM
RE.SI (Stakeholders and Req. Source
Identification) more specific practice to be
added about Requirement Elicitation to CMMI-
DEV RD SG1
RE.GA.a2 (Qualify and Quantify Quality
Requirements) currently missing a more clear
and direct link with CMMI-DEV PP SP 1.2
DS.GA.a2 (Define Requirement Attributes)
currently less stressed (e.g. FUR vs NFR for
FSM/FPA Function Point Analysis, as
requested in CMMI-DEV PP, SP 1.4
REAIMS
Process MM
Basic practices:
3.1 Define a standard document structure:
missing, could be added in CMMI-DEV RD
SG1, stressing the need for having an
organizational ‘standard’ for comparing different
types of requirements, having impact also on
planning (different roles, productivities and
schedules for different activities PP SP 1.4).
Again, it’d help also PP SP 1.2 because it’d
address better the
3.8 Make the document easy to change
criteria for writing better requirements, could be
stressed more in CMMI-DEV RD SG1 / RM
SG1, SP 1.3
6.2 Use language simply and concisely
criteria for writing better requirements could be
added as a note for CMMI-DEV RD SP 1.2, sub-
practice #1
Advanced practices:
9.8 Identify volatile requirements: suggested to
introduce the concept of ‘volatility’ also in the
RD process definition by an informative note
(e.g. “…verifying the new need will not be yet
addressed by a formalized requirement…”, with
a link to RM, SP 1.3), see also R-CMMi P20
process, same issue
R-CMM
ML2: P19: Agree and document technical and
organisational attributes specific to project
CMMI-DEV RD deals with customer and
product requirements, not addressing with further
informative notes about which could be possible
‘constraints’ such as those ones from the analysis
of organizational attributes reinforce RD SP
1.1
R-CMMi
ML2: P20: Institute Process to Maintain Stability
within Project always about the need to
minimize ‘volatility’, in terms of management
same comment than for REAIMS practice 9.8
3. Include the selected element(s) into the target
BPM: looking at the analysis of potential EoI in
Table 2. The main improvements/suggestions
seem to be mainly associated with the RD
process, rather than the RM process. Table 3
ICSOFT 2012 - 7th International Conference on Software Paradigm Trends
58
Table 3: CMMI-DEV RD: suggestions for improvements.
CMMI-DEV v1.3
RD process
Suggested Improvements
SG 1 Develop
Customer Needs
Introduce a new SP 1.0 about
Stakeholders Identification and
Engagement. Rationale: reinforce current
formulation, before running SP 1.1.
Nowadays, stakeholder engagement is the
sub-practice #1 within SP 1.1.
Insert a note about possible standards (de
jure/de facto) that could be
consulted/useful for a better application of
RD process (e.g.. (AccountAbility, 2011)).
SP 1.1 Elicit Needs
Introduce a sub-practice about the
definition of requirement attributes,
inserting a cross-link with PP SP 1.2 for
the classification of work products (by
attribute) to be sized.
Modify the current WP into: ‘results of
requirement elicitation activities by entity
and attribute (see previous comment)
SP 1.2 Transform
Stakeholders needs
Rephrase and make more general sub-
practice #2: not only functional vs. quality
(non-functional) attributes, but possibly
establish all valuable, possible
requirements taxonomies and
classifications for the organization (by
other criteria)
SG 2 Develop
Product
Requirements
Introduce a note within the SG text about
the need and relevance of define a
(standard) document structure (in terms of
‘documentability’) and suggest as
informative note some possible criteria
to follow and appraise (e.g. readability,
simple and concise language for writing
requirements, etc.).
SP 2.1 Establish
Product and Product
components
Sub-practice #3: refine the Example box,
do no mention generic quality attributes,
but be more specific about requirement
classifications (e..g ISO/IEC 14143-
1:1998 functional, quality, technical)
cross-link with PP 1.2 about attributes
for sizing.
SP 2.2 Allocate
Product Components
---
SP 2.3 Identify
Interface
Requirements
---
SG 3 Analyze and
Validate
Requirements
---
SP 3.1 Establish
Operational Concepts
and Scenarios
---
SP 3.2 Establish a
Definition of Required
---
SP 3.3 Analyze
Requirements
---
SP 3.4 Analyze
Requirements to
Achieve Balance
Introduce an informative note about the
possible usage of QFD matrices also here,
not only for eliciting and determining
requirements in SP 2.1
SP 3.5 Validate
Requirements
---
Table 3: CMMI-DEV RD: suggestions for improvements
(cont.).
GP 2.3 Provide
Resources
General: stress the need and opportunity
from workflow environments for an easier
sharing of information among
stakeholders, whatever the (CMMI)
process
Specific (RD Elaboration): specific need
because RD is the starting process for
gathering needs to be translated into
solutions
GP 2.5 Train
People
General: introduce the application of the
six Bloom’s cognitive levels (Bloom et al.,
1956) for classifying knowledge (see also
IEEE SWEBOK
www.computer.org/swebok)
Specific (RD Elaboration): add
‘stakeholder engagement’
(AccountAbility, 2011) and ‘requirement
sizing’ (ISO, 2011)
GP 2.8 Monitor
and Control the
Process
Specific (RD Elaboration): introduce at
least one measure about the effectiveness
of RD SG1 goal (e.g. % of proposed vs
validated requirements)
shows how our suggestions were introduced in the
current RD process, describing a new possible
improved process that may be mapped against
your own QMS internal process(es) covering that
subject.
4. Adapt & Adopt the selected element(s): after
adapting the original RD process, as shown in the
previous table, it should be mapped against the
related QMS internal process covering that
subject. Since many organizations adopt an ISO
management system (e.g. ISO 9001:2008), a
cross-check for validating potential improvements
from the design phase could be achieved through
re-applying the related mapping document to their
own internal process (e.g. using the N/P/L/F
Not/Partially/Largely/Fully achieved ordinal scale
from CMMI or SPICE). In our case, moving from
CMMI-DEV, it could use Mutafeljia &
Stromberg’s mapping document (Mutafelija, 2008)
as a basis. In this paper, our focus was limited to
only the design phase. However, a case study with
the application of the hybrid-RD process will be
included in a future paper.
4 CONCLUSIONS & NEXT STEPS
Requirements are the first step for a project and if
they are not clearly and unambiguously defined this
can increase the probability that project estimates
will be incorrect because the project/activity scope
has not been clearly documented. Even, if there are
many existing requirements management models
and frameworks , each model represents only one
possible view of the inner reality that would be
Hybriding CMMI and Requirement Engineering Maturity & Capability Models - Applying the LEGO Approach for
Improving Estimates
59
captured and reused: the one size doesn’t fit all
motto could be rephrased as one model doesn’t fit
all’. Thus, at least 2 (or more) models/frameworks
should be considered for improving your own
processes (whatever they are), in the areas/issues
needed.
In order to cope with this need, we recently
proposed LEGO (Living EnGineering prOcess) as
an open approach for improving the processes of a
business process model (BPM), based upon the
comparative analysis of the process architecture and
elements of several concurrent models within a
certain domain. Since estimation is one of the key
processes for determining the success of an
organization, we applied LEGO to Requirements
Engineering, with the aim to improving the CMMI-
DEV RD (Req. Development) process by integrating
it with other requirements engineering maturity
models. The final result was the design of a more
encompassing hybrid-RD process that could help
organizations to improve their estimates from the
beginning of the value chain.
In the future, we will apply this hybrid-RD
process to real case studies, proposing it as the meta-
model to be used for the performing the initial gap
analysis against the organizations’ BPM related
processes as part of an improvement initiative.
ACKNOWLEDGEMENTS
This work has been supported by the CNPq
(Conselho Nacional de Desenvolvimento Científico
e Tecnológico www.cnpq.br), an entity of the
Brazilian government focused on scientific and
technological development.
This research is also supported in part by the
Science Foundation Ireland (SFI) Stokes Lectureship
Programme, grant number 07/SK/I1299, the SFI
Principal Investigator Programme, grant number
08/IN.1/I2030 (the funding of this project was
awarded by Science Foundation Ireland under a co-
funding initiative by the Irish Government and
European Regional Development Fund), and
supported in part by Lero (http://www.lero.ie) grant
10/CE/I1855.
REFERENCES
AccountAbility, AA1000 Stakeholder Engagement
Standard 2011, Final Exposure Draft, AA1000SES,
URL: http://goo.gl/VajaE
Ambler S., The Agile Maturity Model, Dr. Dobbs Journal,
2010/04/01, URL: http://goo.gl/nMNsH
Beecham S., Hall T., Rainer A., Defining a Requirement
Process Improvement Model, Software Quality
Journal, 13(3), 247279, 2005
Beecham, S., Hall, T., and Rainer, A. Defining a
Requirements Process Improvement Model, Technical
Report 379, Hatfield, University of Hertfordshire,
February 2003, URL: http://goo.gl/6DvjY
Bloom, B. S., Engelhart, M. D., Furst, E. J., Hill, W. H., &
Krathwohl, D. R. (1956). Taxonomy of educational
objectives: the classification of educational goals;
Handbook I: Cognitive Domain New York,
Longmans, Green, 1956.
Boehm B., Software Engineering Economics, Englewood
Cliffs N.J., Prentice-Hall Inc., 1981, ISBN
0138221227
Buglione L., Ebert C., Estimation, Encyclopedia of
Software Engineering, Taylor & Francis Publisher,
April 2012, ISBN: 978-1-4200-5977-9
Buglione L., Gresse von Wangenheim C., Hauck J.C.R.,
McCaffery F., The LEGO Maturity & Capability
Model Approach, Proceedings of the 5th World
Congress on Software Quality
Chang S.J., When East and West Meet: An Essay of the
Importance of Cultural Understanding in Global
Business Practice and Education, Journal of
International Business and Cultural Studies, Vol.2,
February 2010, URL: http://goo.gl/OvkEw
CMMI Architecture Team, Introduction to the
Architecture of CMMI Framework, Technical Note,
CMU/SEI-2007-TN-009, July 2007, URL: http://
goo.gl/NCPUw
CMMI Product Team, CMMI-DEV (CMMI for
Development) v1.3, Technical Report, CMU/SEI-
2010-TR-033, Software Engineering Institute,
November 2010, URL: www.sei.cmu.edu/cmmi
Copeland L., The Maturity Maturity Model (M3).
Guidelines for Improving the Maturity Process,
StickyMinds, September 2003, URL: http://goo.gl/
PHovg
Gorschek T., Requirement Engineering Process Maturity
Model (Uni-REPM), version 0.9CR, Technical Report,
BTH, Sweden, January 2011, URL: http://goo.gl/
WBxos
Gorschek T., Tejle K., A Method for Assessing
Requirements Engineering Process Maturity in
Software Projects, Master Thesis in Computer
Science, BTH (Blekinge Tekniska Högskola),
Sweden, June 2002, URL: http://goo.gl/Tr5Dt
Hassan A. and Syuhada Jamaludin N., Approaches &
Values in Two Gigantic Educational Philosophies:
East and West, Online Educational Research Journal,
Vol.1, No.2, 2010, pp.1-15, URL: http://goo.gl/
XQO9u
Hepner Brodie C., Are you hearing your customers’
voices?, PRTM, 2006, URL: http://goo.gl/wTz67
Heumann J., The Five Levels of Requirement
Management Maturity, The Rationale Edge, 2003,
URL: http://goo.gl/a7Mvj
ICSOFT 2012 - 7th International Conference on Software Paradigm Trends
60
IAG Consulting, Requirement Maturity Attribute Table,
2009 URL: http://goo.gl/gMgxp
ISO IS 9001:2008, Quality management systems --
Requirements, International Organization for
Standardization, December 2008
ISO IS 9004:2009, Managing for the sustained success of
an organization- A quality management approach,
International Organization for Standardization,
October 2009
ISO/IEC IS 14143-x, Information Technology Software
Measurement Functional Size Measurement, Parts 1-
6, 2002-2011
ISO/IEC IS 15504-x, Information technology -- Process
assessment, Parts 1-7, International Organization for
Standardization, 2001-2007
Kollinger J., 7 Signs You Have a Bad Project Estimate
(and what to do about it), Presentation, 2010/01/20,
URL: http://goo.gl/fp435
Koomen, T. & Pol, M. Test Process Improvement: a
Practical Step-by-Step Guide to Structured Testing,
Addison-Wesley, ISBN 0-201-59624-5, 1999
Luo P., Analysis of Cultural Differences between West
and East in International Business Negotiation,
International Journal of Business and Management,
Vol.3, No.11, November 2008, pp. 103-106, URL:
http://goo.gl/HCzTA
McConnell S., 10 Deadly Sins of Software Estimation,
Presentation, 2002, URL: http://goo.gl/WjbGR
McConnell, Software Estimation: Demystifying the Black
Art, Microsoft Press, 2006, ISBN 978-0735605350
Mutafelija B., Stromberg H., Process Improvement with
CMMI v1.2 and ISO Standards, Auerbach, 2008,
ISBN 978-1420052831
OGC, P3M3: Portfolio,Programme & Project
Management Maturity Model, Version 1.0, February
2006, Office of Government Commerce, URL: http://
www.ogc.gov.uk/documents/p3m3.pdf
PMI, Organizational Project Management Maturity Model
(OPM3), Knowledge Foundation, Project
Management Institute, 2
nd
ed., 2008
PMI, The Guide to the Project Management Body of
Knowledge, Project Management Institute, 4th Ed.,
2008, URL: www.pmi.org
Schauder J., 8 Reasons why Estimates are too low,
Schauderhaft website, 2010/01/17, URL: http://
goo.gl/F3T2f
Sehlhorst S., CMMI Levels and Requirements
Management Maturity Introduction, TynerBlain,
2007/01/25, URL: http://goo.gl/ARBLX
Solemon B., Sahibuddin S., Abd Ghani A.A., Re-defining
the Requirements Engineering Process Improvement
Model, Proceedings of the 16th Asia-Pacific Software
Engineering Conference (APSEC’09), Penang
(Malaysia) pp. 87-92, URL: http://goo.gl/ZpqZE
Sommerville I., Ransom J., An Empirical Study of
Industrial Requirements Engineering Process
Assessment and Improvement, ACM Transactions on
Software Engineering and Methodology, Vol. 14, No.
1, January 2005, Pages 85117, URL: http://goo.gl/
xKIih
Standish Group, CHAOS Summary 2009. The 10 Laws of
CHAOS, URL: http://goo.gl/ONXi4
Stawicki J., Principles of connecting East and West
cultural differences in project management, XXII
IPMA World Congress, Rome (Italy), 2008, URL:
http://goo.gl/S8lTP
Stellman A., Greene J., Applied Software Project
Management, Chapter 3: Estimation, O’Reilly
Publishing, 2005, ISBN 978-0596009489
Swyngedouw, E., Neither global nor local: `glocalization’
and the politics of scale, in: K.Cox (Ed.) Spaces of
Globalization, New York: Guilford Press, 1997, pp.
137-166, URL: http://goo.gl/Lker1
Van Veenendaal, Test Maturity Model Integration
(TMMi) version 3.1, TMMi Foundation, 2010, URL:
www.tmmifoundation.org
APPENDIX - LIST OF ACRONYMS
BPM
Business Process Model
CL
Capability Level
CMMI
Capability Maturity Model Integration
CMMI-
DEV
CMMI for Development
ENG.1
Requirement Elicitation
ENG.4
Sw Requirement Analysis
IEC
Int. Electrotechnical Commission
ISO
Int. Organization for Standardization
LEGO
Living EnGineering prOcess
MAN.3
Quality Management process
MCM
Maturity & Capability Model
ML
Maturity Level
MM
Maturity Model
NFR
Non-Functional Requirement
OPM3
Organizational Project Management
Maturity Model
P3M3
Portfolio, Programme, and Project
Management Maturity Model
PAM
Process Assessment Model
PMBOK
Project Management Body of Knowledge
PMI
Project Management Institute
PP
Project Planning
PRM
Process Reference Model
QMS
Quality Management System
RCA
Root-Cause Analysis
RD
Requirement Development
RE
Requirement Engineering
REAIMS
Requirements Engineering adaptation and
improvement for safety and dependability
REPM
Requirements Engineering Process Model
RM
Requirement Management
SEI
Software Engineering Institute
SPICE
Software Process Improvement Capability
dEtermination (ISO/IEC 15504)
TMMi
Test Maturity Model Integration
TPI
Test Process Improvement
Hybriding CMMI and Requirement Engineering Maturity & Capability Models - Applying the LEGO Approach for
Improving Estimates
61