Systems development life cycles and methodologies guide the development of software, services, and other products and may serve other purposes within an organization. For example, the Mesquida and Mas (2015, February) article describes how software life cycle processes were used as a framework to help support the integration of information security best practices into software development and use.
Consider your studies, reflect on your experience with the development processes in organizations, and provide your own analysis to respond to the following questions in your initial post:
What systems development processes have you been a part of in your work history? Briefly describe the type of methodology used by an organization with which you are familiar. Also, describe any roles you have had during a systems life cycle process.
What are your observations about how these processes worked? What did the methodology help the developers and organization achieve? Was the organization using the methodology to support activities other than systems development?
How important do you think it is for an organization to use a formal methodology in its systems development efforts?
What are the benefits of following a systems development methodology, and what are the downsides?
Response Guidelines
Return to the discussion at the end of the week to read and review the posts of your peers. Does anyone else’s experience resonate with your own? Post a comment and add questions to further explore the experiences of your classmates. Also, in your response posts, comment on whether the methodologies described by a peer could be used to support or inform activities other than systems development.
Softw Syst Model (2013) 12:439–440
DOI 10.1007/s10270-013-0362-4
EDITORIAL
Model-based lifecycle management of software-intensive systems,
applications, and services
Robert France · Bernhard Rumpe
Published online: 18 June 2013
© Springer-Verlag Berlin Heidelberg 2013
The lifecycle of a successful system is the time period that
covers all activities associated with developing, configuring,
deploying, operating, and retiring the system. Variations in
system lifecycles can be expected, for example, differences
may arise as a result of the inclusion of physical parts in the
system and the number of installations. In addition, software
retirement activities may extend over a long period of time,
for example, in cases where access to data provided by a
system may be required long after the system is terminated.
Lifecycle management has a lot to do with managing the
available information about a system. A significant amount
of this information can typically be found in the models pro-
duced during various development. Software models can thus
play a vital role in system lifecycle management. For exam-
ple, requirement models can be used to support management
of requirements, feature models can be used to manage sys-
tem and user specific variabilities as well as commonalities,
and architecture and design models can provide information
that support management of deployment and validation activ-
ities. The potential role that models can play in lifecycle man-
agement raises the following questions: “To what extent do
the models produced during software development help (or
hinder) lifecycle management?” “Should the software mod-
eling activity be integrated with the lifecycle management of
systems, and, if yes, how can this be done?” “What tools are
needed to better leverage the use of models in lifecycle man-
agement?” “Does a model also have a lifecycle that needs to
be managed?”
R. France
Colorado State University, Fort Collins, Colorado, USA
B. Rumpe (B)
RWTH Aachen University, Aachen, Germany
e-mail: Bernhard.Rumpe@sosym.org
A variety of models may be needed to support lifecy-
cle management, each describing a particular aspect of the
system for particular lifecycle management purposes. In
such situations, it is important to have an understanding
of how the models relate to each other. Such an under-
standing is needed, for example, to develop appropriate
technologies for maintaining consistency across the models
and for managing the propagation of changes across the
models.
In various conferences, workshops and discussions, we
have observed the following model and language integration
trends:
• Integration of heterogeneous models and of their cor-
responding modeling languages remain a challenging
research problem. For example, the many semantic vari-
ation points in the UML make it difficult to produce an
integrated, semantically coherent language in which the
variation points are resolved in a consistent manner. It
may also be the case that the manner in which the UML
notations are integrated vary, leading to the need to sup-
port variations on the forms of integration.
• Providing effective support for model evolution is still
a pressing problem. Some of the challenging problems
include developing support for semantic differencing
(diffing) and merging of models. For graphical model-
ing languages, the lack of support of modularity and
encapsulation in modeling languages, as well as their
two-dimensional graphical nature, presents challenges;
comparing text on a line basis is much easier than com-
paring model elements arranged in graph structures.
• The need to provide support for tracing information
through various models is widely appreciated, particu-
larly in software evolution activities. We suspect that this
problem is best tackled by developing language-specific
123
440 R. France, B. Rumpe
solutions, rather than general solutions that are language
agnostic.
• Language and model integration is particularly chal-
lenging when there is a need to model non-software
aspects of a system. For example, in the domain of
cyberphysical systems, language integration involves
providing the means to integrate underlying “commu-
nication” paradigms, namely calculi from control the-
ory, physics, and engineering disciplines with the digital
state based theory from computer science. Such integra-
tion should lead to better model-based lifecycles of these
systems.
• We anticipate that a variety of domain specific lan-
guages will be more widely used in software development
projects, and thus support for integrating DSLs with gen-
eral purpose modeling and programming languages will
be needed.
• Variability of hardware and software is often handled
externally to modeling languages, but it may be more
effective to provide support for such variability within the
languages. An approach to managing variability in pro-
duct lines that is built on top of modeling languages may
help to some extent, but a language-integrated approach
that leverages context conditions and language semantics
may be more effective.
• Semantic integration of models is furthermore needed
in situations in which integrated models are used as the
basis for static or dynamic analysis (e.g., formal analysis
of functional properties and simulation). Few integration
techniques adequately address semantic issues.
• Recent research has focused on the use of models at run-
time to support runtime adaptation of software. For exam-
ple, in plant control systems an explicit representation
of the controlled plant that faithfully captures monitored
aspects of the plant can be used as the basis for adapt-
ing the plant control software. Runtime models cannot
be distinguished anymore from requirements and design
models produced during development, in terms of the
abstractions they embody. From this perspective, the life-
cycle of requirements and design models extends beyond
the development and maintenance phase into the ope-
rational phases. In fact, using these models at runtime
makes the models an integral part of the operation of the
system, while at the same time, enables evolution of the
running system through evolution of the runtime models.
This integrated co-evolution can be viewed as a form of
lifecycle management based on these models.
In summary, the use of models in system lifecycle manage-
ment raises interesting and challenging research opportu-
nities. Furthermore, we in the software and system model-
ing community cannot ignore lifecycle management issues:
As the use of models becomes more widespread, the need
for lifecycle management of models will become necessary.
Sound lifecycle management of development artifacts is a
core competence of integrated software-intensive systems
development and becomes even more pressing in the con-
text of globalized software development environments.
123
Copyright of Software & Systems Modeling is the property of Springer Science & Business
Media B.V. and its content may not be copied or emailed to multiple sites or posted to a
listserv without the copyright holder’s express written permission. However, users may print,
download, or email articles for individual use.
- Model-based lifecycle management of software-intensive systems, applications, and services
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Software Development Practices and Software Quality: A Survey
Kassab, Mohamad;Neill, Colin;Laplante, Phillip
Software Quality Professional; Sep 2014; 16, 4; ProQuest Central
pg. 36
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The Journal of Systems and Software 68 (2003) 199–215
www.elsevier.com/locate/jss
Nenad Medvidovic a,*, Paul Gr€uunbacher b, Alexander Egyed c, Barry W. Boehm a
a Computer Science Department, University of Southern California, Los Angeles, CA 90089-0781, USA
b Systems Engineering and Automation, Johannes Kepler University Linz, 4040 Linz, Austria
c Teknowledge Corporation, 4640 Admiralty Way, Suite 231, Los Angeles, CA 90292, USA
Received 23 December 2002; accepted 27 December 2002
Abstract
Numerous notations, methodologies, and tools exist to support software system modeling. While individual models help to
clarify certain system aspects, the large number and heterogeneity of models may ultimately hamper the ability of stakeholders to
communicate about a system. A major reason for this is the discontinuity of information across different models. In this paper, we
present an approach for dealing with that discontinuity. We introduce a set of ‘‘connectors’’ to bridge models, both within
and
across the ‘‘upstream’’ activities in the software development lifecycle (specifically, requirements, architecture, and design). While
the details of these connectors are dependent upon the source and destination models, they share a number of underlying char-
acteristics. These characteristics can be used as a starting point in providing a general understanding of software model
connectors.
We illustrate our approach by applying it to a system we have designed and implemented in collaboration with a third-party or-
ganization.
� 2003 Elsevier Inc. All rights reserved.
Keywords: Software model; Software requirements; Software architecture; Software design; Refinement; Traceability; Model connector
1. Introductio
n
Software engineering researchers and practitioners
have developed a plethora of models that focus on dif-
ferent aspects of a software system. These models fall into
five general categories: domain, success, process, product,
and property models. Numerous notations, methodolo-
gies, and tools exist to support models in each category.
For example, within the last decade, the heightened in-
terest in software architectures has resulted in several
product and property models based on architecture de-
scription languages (ADLs), architectural styles, and
their supporting toolsets (Medvidovic and Taylor, 2000;
Perry and Wolf, 1992; Shaw and Garlan, 1996).
Models are an indispensable tool in software devel-
opment. They help developers curb system complexity;
they also help the many stakeholders in a project convey
their concerns to other stakeholders in a manner that is
* Corresponding author.
E-mail addresses: neno@sunset.usc.edu (N. Medvidovic), pg@sea.
uni-linz.ac.at (P. Gr€uunbacher), aegyed@ieee.org (A. Egyed), boehm@
sunset.usc.edu (B.W. Boehm).
0164-1212/$ – see front matter � 2003 Elsevier Inc. All rights reserved.
doi:10.1016/S0164-1212(03)00063-3
understandable and that will ensure the proper treat-
ment of those concerns. However, the preponderance of
models actually renders the ultimate goal of develop-
ment––implementing dependable software––more diffi-
cult in many ways. The reason for this is the
discontinuity of information across different models. Fo
r
example, a system�s requirements might be described
using use-case scenarios and entity-relationship dia-
grams, while its design may be captured in class, object,
collaboration, and activity diagrams. The problem,
then, is twofold:
1. ensuring the consistency of information across mod-
els describing the same artifact (e.g., a class
instance
in object and collaboration diagrams in a design), and
2. ensuring the consistency of information across mod-
els describing different artifacts (e.g., use-cases in a
system�s requirements and classes in its design).
In both cases, each model provides (different) infor-
mation in different ways, making it very difficult to es-
tablish any properties of the modeled phenomena as a
whole.
mail to: neno@sunset.usc.edu
200 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215
In principle, this discontinuity among models can be
dealt with by employing synthesis and analysis. Synthe-
sis enables one to generate a new model (e.g., collabo-
ration diagram) from an existing model (e.g., class
diagram), while analysis provides mechanisms for en-
suring the preservation of certain properties across (in-
dependently created) models. Software engineers
extensively employ both kinds of techniques. For ex-
ample, program compilation involves both the analysis
of the syntactic and semantic correctness of one model
(source code) and the synthesis of another model from it
(executable image).
Synthesis and analysis techniques span a spectrum
from manual to fully automated. Manual techniques tend
to be error prone, while fully automated techniques are
often infeasible (Partsch and Steinbruggen, 1983). Fur-
thermore, in some cases one technique (e.g., analysis) is
easier to perform than another (synthesis). For this rea-
son, one typically must resort to using some combination
of synthesis and analysis techniques of varying degrees of
automation when ensuring inter-model consistency.
The focus of our previous work was on identifying
and classifying different categories of models and pro-
viding support for specific models within each category
(e.g., requirements models (Boehm et al., 1998), archi-
tecture models (Medvidovic et al., 1999), and design
models (Egyed and Medvidovic, 2000)). This paper dis-
cusses a set of techniques we have developed to bridge the
information gap created by such heterogeneous models.
In many ways, we view the problem of bridging het-
erogeneous models as similar to the one that has recently
generated much interest in the software architecture
community: a software architecture can be conceptual-
ized as a diagram consisting of ‘‘boxes,’’ representing
components, and ‘‘lines,’’ representing component rela-
tionships (i.e., connectors); while we may have a more
complete understanding of the components, many of the
critical properties of a software system are hidden within
its connectors (Mehta et al., 2000; Shaw, 1993). Similarly,
the individual models produced during a software sys-
tem�s lifecycle comprise the ‘‘lifecycle architecture’’
boxes; the properties of these individual models are typ-
ically well understood. Much more challenging is the
problem of understanding and providing the necessary
support for the lines between the boxes, i.e., the model
‘‘connectors.’’
The work described in this paper focuses on model
connectors traditionally associated with the ‘‘upstream’’
activities in the software lifecycle: requirements, archi-
tecture, and design. In particular, we have devised a set
of techniques for bridging
1. requirements and architecture models,
2. architecture and design models, and
3. different design models, both at the same level and
across levels of abstraction.
As this paper will demonstrate, each of the three cases
introduces its own issues and challenges. Moreover, for
practical reasons, our investigation to date has focused
on a limited number of models. Nevertheless, we have
been able to successfully develop and combine a set of
model connectors that allow us to start with a high-level
requirements negotiation and arrive at a low-level ap-
plication design in a principled manner. In the process,
we have developed a novel, light-weight technique for
transferring requirements into architectural decisions.
We have also introduced a model transformation
framework that supports multiple views of a system�s
design.
The results outlined above are specific to our ap-
proaches to requirements, architecture, and design
modeling. However, we have leveraged this experience,
along with existing literature on software model trans-
formations, to devise a set of shared principles we be-
lieve to be model-independent. In particular, we classify
the properties of model connectors and relationships
among individual elements of different models. We il-
lustrate these properties and relationships both via ex-
amples drawn from our work and from well-understood
software transformation techniques (e.g. compilation).
The remainder of the paper is organized as follows.
Section 2 introduces the notion and properties of model
connectors. Section 3 outlines the example application
we will use for illustration throughout the paper. Sec-
tions 4–6 briefly introduce the requirements, architec-
ture, and design modeling approaches we developed in
the past and used as the basis of this work, and then
provide in-depth discussions of the model connectors we
have developed for bridging them. Due to the scope of
our work and number of model connectors we have
developed, at times we are forced to omit some of the
techniques� details and convey their general flavor to the
reader instead. Section 7 revisits the general properties
of software model connectors we have identified and ties
them to the examples discussed throughout the paper. A
discussion of related work and conclusions round out
the paper. It is important to note that our approach does
not assume any particular lifecycle model (e.g., waterfall
or spiral) or software development process. The se-
quential ordering of lifecycle activities implied by the
paper�s organization (Sections 4–6 in particular) was
adopted for presentation purposes only.
2. Connecting the software lifecycle
When we speak of models, diagrams, or views, we
mean any form of graphical or textual depiction that
describes the software system itself and/or decisions
about the system made along the way. Models may be
described separately, but they are not independent of
one another. Models may be created individually and
N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 201
validated for syntactic and even semantic correctness
within a given context. However, models are interde-
pendent because they must somehow reflect the general
objectives of the software system under development.
Successful modeling thus requires more than generating
and validating individual models––it is also about en-
suring the consistency of all models with the general
objectives of the software system.
This paper discusses ways of bridging information
across models. Connectors between models satisfy two
primary goals:
1. they are able to transform model information (a form
of model synthesis) or
2. they are able to compare model information (a form
of model analysis).
In both cases, model connectors maintain consistency
by helping to transform or compare the information two
or more models have in common. When we talk about
model transformation and comparison in the context of
this work, we really mean ‘‘inter-model’’ transformation
and comparison, that is, transformation and compari-
son between separate models, diagrams, or views with
the primary goal of ensuring a common objective. Al-
though this paper discusses various instances of bridging
model information across the software lifecycle, we must
emphasize that the key contribution of this work is not
those instances, but rather their combined, collective
properties. The most generic property of a model con-
nector is that it re-interprets information. Re-interpre-
tation is a fundamental requirement for model
connectors in order to baseline the relationships between
models to overcome syntactic and semantic differences
between them.
This paper will show that model connectors can have
very unique implementations. However, we will also
show that there are some common ways of categorizing
their differences by using a set of properties. In partic-
ular, model connectors may be directional in that one
type of model can be transformed into another type of
model, but perhaps not vice versa; model connectors
may also only be partially automatable or reliable (i.e.,
‘‘trustworthy’’). We will discuss in this paper that some
of those properties apply to model connectors directly
whereas other properties apply to the modeling elements
they bridge. For instance, modeling elements belonging
to different models may complement or outright con-
tradict one another. Sometimes, one modeling ele
ment
may relate to exactly one element in another model (1-
to-1 mapping); or the mappings may be more complex
(i.e., many-to-many mappings). In creating and vali-
dating model connectors, one has to define and analyze
these properties. As an illustration of these properties,
the next section will introduce an example. The follow-
ing sections will then outline some connectors between
different models developed in the context of this exam-
ple. We will then revisit the general properties of model
connectors.
3. Example application
We use an example application to illustrate the con-
cepts introduced in this paper. The application is moti-
vated by the scenario we developed in the context of a
US Defense Advanced Research Project Agency
(DARPA) project demonstration and recently refined in
collaboration with a major US software development
organization. The scenario postulates a natural disaster
that results in extensive material destruction and casu-
alties. In response to the situation, an international
humanitarian relief effort is initiated, causing several
challenges from a software engineering perspective.
These challenges include efficient routing and delivery of
large amounts of material aid; wide distribution of
participating personnel, equipment, and infrastructure;
rapid response to changing circumstances in the field;
using existing software for tasks for which it was not
intended; and enabling the interoperation of numerous,
heterogeneous systems employed by the participating
countries.
We have performed a thorough requirements, archi-
tecture, and design modeling exercise to address these
concerns. We have also provided a partial implementa-
tion for the resulting system (referred to as ‘‘cargo
router’’). This implementation is an extension of the
logistics applications discussed in Medvidovic et al.
(1999).
4. Software requirements model connectors
4.1. Modeling software re
quirements
During requirements engineering, the needs, expec-
tations, constraints, and goals of a project�s stakeholders
have to be gathered, communicated, and negotiated to
achieve a mutually satisfactory solution. We have de-
veloped the WinWin approach for collaborative re-
quirements negotiation and successfully applied it in
over 100 real-client projects (Boehm et al., 1998; Boehm
et al., 2001). WinWin defines a model guiding the ne-
gotiation process: stakeholder objectives and goals are
expressed as win conditions; known constraints, prob-
lems, and conflicts among win conditions are captured as
issues; options describe possible alternative solutions to
overcome the issues; if a consensus is achieved among
stakeholders, agreements are created. We have re-
cently enhanced the WinWin approach and have used
a COTS groupware environment as its implemen-
tation substrate (GroupSystems, 2001). The result,
202 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215
‘‘EasyWinWin,’’ supports brainstorming, categoriza-
tion, and prioritization of win conditions, identification
and resolution of conflicts, as well as collaborative
characterization of application domain properties (Bo-
ehm et al., 2001; Gr€uunbacher and Briggs, 2001).
A team of stakeholders used EasyWinWin to gather,
negotiate, and elaborate requirements for the cargo
router system. In the first round of requirements nego-
tiation the team came up with 64 win conditions, which
provided a starting point for further negotiation and
architectural refinements. Fig. 1 shows a snapshot of the
EasyWinWin negotiation tool: WinWin artifacts are
organized in a tree and marked with artifact type and
stakeholder tags (top pane); a voting tool is used to aid
the transformation of software requirements into an
architecture, as discussed in Section 4.2.
4.2. Requirements-to-architecture model connector
The relationship between a set of requirements, such
as those produced by an EasyWinWin negotiation, and
an effective architecture for the desired system is not
readily obvious. Requirements largely describe the
problem to be solved (and constraints on its solution),
whereas architectures model a solution to the problem.
The terminology and concepts used to describe the two
also differ. For example, WinWin deals with win condi-
tions, issues, options, and agreements, while architectures
Fig. 1. EasyWinWin negotiation
deal with components, their interactions (i.e., software
connectors or buses), system topologies, and properties
(Shaw and Garlan, 1996). For these reasons, we have
investigated principled ways of relating requirements
and architecture models and defining a viable architec-
ture that addresses a given set of requirements. Unfor-
tunately, the large semantic gap between high-level,
sometimes ambiguous requirements artifacts and the
more specific architectural artifacts (e.g., modeled in a
formal ADL) often does not allow one to establish
meaningful links between them. This section proposes a
model connector that remedies the problem and facili-
tates the bridging of the two models.
We have developed the Component, Bus, System,
Property (CBSP) model connector that bridges re-
quirements and architectures. CBSP artifacts refine
WinWin�s artifacts into architectural decisions. CBSP is
a tool-aided, but highly human-intensive technique.
Software architects assess the win conditions for their
relevance to a system�s architecture: its components (i.e.,
processing and data elements (Perry and Wolf, 1992)),
buses (i.e., connectors; Shaw and Garlan, 1996), overall
configuration (i.e., the system itself or a particular sub-
system), and their properties (e.g., reliability, perfor-
mance, and cost). If it is deemed architecturally relevant,
a win condition
is refined into
one or more artifacts in
the CBSP model connector. Each CBSP artifact thus
explicates an architectural concern and represents an
tree and CBSP vote views.
N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 203
early architectural decision for the system. For example,
a win condition such as
W: The system should provide an interface to a Web
browser.
can be recast into a processing component CBSP
artifact
Cp: A Web browser should be used as a component in
the system.
and a bus CBSP artifact
B: A connector should be provided to ensure interoper-
ability with a third-party Web browser.
The CBSP dimensions include a set of general
architectural concerns that can be applied to systemat-
ically classify and refine requirements negotiation arti-
facts and to capture architectural tradeoff issues and
options. There are six possible CBSP dimensions. They
are discussed below and illustrated with examples drawn
from the cargo router system negotiation.
(1) C: artifacts that describe or involve a Component in
an architecture. For example, the win condition.
W12: Allow customizable reports, generated on the
fly.
is refined into CBSP artifacts describing both pro-
cessing ðCpÞ and data ðCdÞ components
Cp: Report generator component.
Cd: Data for report generation.
(2) B: artifacts that describe or imply a Bus. For exam-
ple
W30: The system should have interfaces to related
applications (vehicle management system, staff
availability).
can be refined into
B: Connector to staff and vehicle management sys-
tems.
(3) S: artifacts that describe System-wide features or
features pertinent to a large subset of the system�s
components and connectors.
For example
W6: Capability to react to urgent cargo needs.
is refined into
S: The system should deploy automatic agents to
monitor and react to urgent cargo needs.
(4) CP: artifacts that describe or imply Component
Properties. For example
W44: Client UI should be accessible via a palm-top
or lap-top device.
is refined into
CP: The client UI component should be portable
and efficient to run on palm-top as well as lap-top
devices.
(5) BP: artifacts that describe or imply Bus Properties.
For example
W42: Integration of third-party components should
be enabled without shutting down the system.
is refined into
BP: Dynamic, robust connectors should be provided
to enable ‘‘on the fly’’ component addition and re-
moval.
(6) SP: artifacts that describe or imply System (or sub-
system) Properties. For example
W6: Operators must be promptly notified of subsys-
tem failures.
is refined into
SP: The system should support real-time communi-
cation and awareness.
During this process of refining requirements, a given
CBSP artifact may appear multiple times as a by-
product of different requirements. For example, in
the cargo router system requirements negotiation,
two win conditions
W1: Optimize concurrent routing to increase speed
of high-priority cargo delivery.
and
W3: Support for different types of cargo.
result in the identification of a cargo data compo-
nent (see Fig. 2). Such redundancies are identified
and eliminated by the CBSP model connector, re-
sulting in a minimal (intermediate) CBSP
model.
During minimization, it is also possible to merge
multiple related CBSP artifacts and converge on a
single artifact. The minimal CBSP model thus allows
architects to maintain arbitrarily complex depen-
dencies between a system�s requirements and its ar-
chitecture.
We have developed tool support for identifying and
classifying the architectural relevance of win conditions
as part of the EasyWinWin environment (recall Fig. 1).
The CBSP dimensions are applied in a voting process
involving multiple experts (e.g., software architects, de-
velopers). The experts use the six criteria described above
to classify the architectural relevance of each win condi-
tion as unknown, not relevant, and partially, largely, or
fully relevant. The voting results assist architects in fo-
cusing on the relevant subset of the system requirements.
The bottom pane of Fig. 1 shows a screenshot of the
voting tool. Shaded cells in the figure indicate large dis-
crepancies in votes among the experts and reflect po-
tentially confusing win conditions. These win conditions
must be discussed, and often re-framed, in order to avoid
costly errors and misunderstandings.
4.3. Application to the cargo router example
CBSP bridges the requirements and architecture
models by providing comprehensible views accessible
to both the requirements engineer and the software
architect. Fig. 2 shows an example of the use of CBSP;
it depicts the relationships between partial models
taken from the cargo router case study. The Negotiation
Rationale View shows a set of WinWin artifacts. The
W1
Optimize
concurrent routing
to increase speed
of high-priority
cargo delivery
W2
Support real-time
communication
from system to
vehicle
I1
Problem: In order to
optimize concurrent
routings, we need to
support bi-directional real-
time communication
Support bi-directional real-time
communication between
system and vehicle
<
W4
Optimizer
Vehicle
Warehouse
One-Way
Bus
Two-Way
Bus
<
Negotation Rationale View CBSP View
support for different
types of cargoW3
real-time bi-
direct.
Cargo
Cargo
Cargo
types
CargoRouter
Optimizer
VehicleWarehouse
ServicesC
onn
Artist
Conn
Artist
Clock
ClockConn
C2 Architectural View
Reporter
CommunicationConn
Port
Two-Way
Bus
Cargo
Vehicle
Warehouse
<
Minimal CBSP View
<
<
Cargo
types
real-time bi-
direct.<
Optimizer
Fig. 2. Transforming a requirements model into an architectural model using the CBSP model connector (shown in the two middle diagrams). Grey
arrows indicate traceability links between model elements. As discussed further in Section 5.1, an architectural model cannot be directly derived from
a (minimal) CBSP model. However, the intermediate CBSP model maps to an architecture in a more obvious way than does a requirements
model.
204 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215
Architectural View is a possible architecture for the
cargo router example further discussed in Section 5.
The CBSP model connector comprises two views: the
CBSP View, created by classifying and refining win
conditions, and the Minimal CBSP View, created by
eliminating replaced and merging related CBSP arti-
facts.
In the example shown in Fig. 2, win condition W1
was voted as being fully component relevant, largely bus
relevant, and largely bus property relevant. Win condi-
tions W2 and W4 were voted as being fully bus property
relevant (omitted from the diagram for simplicity) and
largely bus relevant. Finally, W3 was voted as being
largely component relevant. Upon further analysis, it is
revealed that W1 describes multiple architectural ele-
ments. The two middle diagrams in Fig. 2 show the re-
sult of this process: W1 is eventually divided into several
components, a connector, and a connector property in
the minimal CBSP view.
5. Software architecture model connectors
5.1. Modeling software architectures
A minimal CBSP view suggests the key architectural
elements and their properties for an application. How-
ever, it does not provide guidance for achieving an ef-
fective topology of those architectural elements: the S
and SP categories of architectural decisions provide only
hints about the characteristics of the topology. Simi-
larly, in the course of architectural decomposition, the
architect may discover that additional components and
connectors are needed that have not been identified
through requirements elicitation and refinement. For
these reasons, the architectural details suggested by
CBSP must be complemented with architectural design
principles.
There exists a large body of work on arriving at an
effective architecture for a given problem. Architectural
styles (Shaw and Garlan, 1996) provide rules that ex-
ploit recurring structural and interaction patterns across
a class of applications and/or domains. Domain-specific
software architectures (DSSA) and product-line archi-
tectures (Perry, 1998) provide generic, reusable archi-
tectural solutions (reference architectures) for a class
of applications in a single domain and instantiate
those solutions to arrive at a specific application archi-
tecture. Finally, a large body of ADLs and their sup-
porting toolsets (Medvidovic and Taylor, 2000) allow
developers to model, analyze, and implement software
systems.
In our work to date, we have chosen to use archi-
tectural styles as guides in transforming the initial ar-
chitectural decisions produced by the CBSP model
connector into an actual architecture. We have explored
the feasibility of composing CBSP artifacts into an ar-
chitecture according to the Pipe-and-Filter (Shaw and
Garlan, 1996), GenVoca (Batory and O�Malley, 1992),
Weaves (Gorlick and Razouk, 1991), and C2 (Medvi-
dovic et al., 1999) styles. An analysis of the key
requirements for the cargo router system (e.g., scale,
distribution, evolvability, heterogeneity) suggested
Weaves and C2 as suitable styles. Since our software
architecture research is centered around C2 and we had
previously applied C2 in the design and implementation
of a logistics application, it became our primary choice,
as already foreshadowed in Fig. 2.
C2 provides a number of useful rules for high-level
system composition. A C2-style architecture consists of
processing components, buses, and their configurations;
data components are treated implicitly, as attributes
of the processing components� interactions. For exam-
ple, in Fig. 2 Cargo is not explicitly represented in the
C2 architecture. C2 imposes a particular topological
order on the components and buses in an architecture:
N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 205
components may interact only via buses and may have
at most one bus on their top and one on their bottom
sides; as a side-effect, topologically adjacent components
may not directly interact. Furthermore, each component
is substrate-independent and may only have knowledge
of the components above it in the architecture.
Based on the dependencies among the elements in the
minimal CBSP view, the rules of the C2 style allow us to
compose them into an architecture. For example, as
shown in Fig. 2, Optimizer depends on Vehicle and
Warehouse; C2�s substrate independence principle
mandates that Optimizer be placed below them in the
CargoRoute
Optimizer
Warehou
ServicesC
ArtistConn
Artist
Clock
ClockCon
Communication
Port
architecture CargoRouteSystem is {
component_types {
component Port is extern {Port.c2;
}
component Artist is virtual {}
… }
connector_types {
connector RegConn is {filter no_filter;} }
architectural_topology {
component_instances {
aPort : Port;
Display : Artist; … }
connector_instances {
ClockConn, ArtistConn : RegConn; … }
connections {
connector Clock Conn {
top SimClock;
bottom aPort; }
connector ArtistConn {
top Optim, Report, ServicesConn;
bottom Display; }
… } }
}
(a
)
(b) (c
Fig. 3. (a) Architectural breakdown of the cargo routing system. (b) Partial ca
component type specified in C2SADEL. ‘‘�’’ denotes the value of a variabl
nality. C2SADEL uses a backslash to distinguish a keyword from an identifi
architecture. Since there are no direct dependencies be-
tween Vehicle and Warehouse, they may be adjacent.
Note that the same dependency relationship would have
different topological implications in a different style. For
example, GenVoca would require Optimizer to be above
the Vehicle and Warehouse components (while still al-
lowing Vehicle and Warehouse to be at the same level).
Furthermore, unlike C2, GenVoca would allow direct
interactions among its components, without the inter-
vening connectors.
The C2 architecture of a subset of the cargo routing
application is shown in Fig. 3a. The Port, Vehicle, and
r
Vehiclese
onn
n
Reporter
Conn
component Port is
subtype CargoRouteEntity (int \and beh) {
state {
cargo : \set Shipment; selected : Integer; … }
invariant { (cap >= 0) \and (cap <= max_cap); } interface {
prov ip_selshp: Select(sel : Integer);
req ir_clktck: ClockTick(); … }
operations {
prov op_selshp: {
let num : Integer;
pre num <= #cargo;
post ~selected = num; }
req or_clktck: {
let time : STATE_VARIABLE;
post ~time = time + 1; }
… }
map {
ip_selshp -> op_selshp (sel -> num);
ir_clktck -> or_clktck ();
… }
}
)
rgo routing system architecture specified in C2SADEL. (c) Partial port
e after an operation has been performed, while ‘‘#’’ denotes set cardi-
er with the same name (e.g., ‘‘nset’’ versus ‘‘set’’).
Fig. 4. Partial rule set for transforming a C2SADEL model into a UML model. This rule set is implemented by the integration of DRADEL and
Rational Rose.
206 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215
Warehouse components maintain the state of the appli-
cation. Optimizer ensures the most efficient distribution
of vehicles at the delivery ports, assignment of cargo to
the vehicles, and routing of vehicles to the warehouses.
CargoRouter tracks the cargo during its delivery to a
warehouse, while Reporter allows progress tracking of
the system by a human operator. SystemClock provides
consistent time measurement to interested components.
Finally, the Artist component renders the application�s
user interface.
C2-style architectures are modeled in an ADL,
C2SADEL (Medvidovic et al., 1999). C2SADEL allows
modeling of component and connector types, which are
then instantiated and composed into a configuration. For
illustration, an excerpt of a C2SADEL model of the
cargo router architecture is shown in Fig. 3b, while a
partial specification of the Port component type is given
in Fig. 3c. Such a specification is analyzed for consistency
by C2�s DRADEL environment (Medvidovic et al., 1999).
5.2. Architecture-to-design model connector
Based on the information provided in a C2SADEL
model of an architecture, DRADEL is capable of gen-
erating a partial implementation of that architecture
(Medvidovic et al., 1999). However, many lower-level
issues needed to complete the implementation (e.g.,
specific data structures and algorithms) are not provided
at the architectural level. For that reason, the ‘‘outer
skeleton’’ of the application generated from the archi-
tectural model must be complemented with the details
typically provided through lower-level design activities.
To ensure the traceability of design-level details to the
architecture and vice versa, we have developed a model
connector that synthesizes a design model from an ADL
model. We selected the Unified Modeling Language
(UML) (Booch et al., 1998) as the target design lan-
guage and conducted an in-depth study of the feasibility
of mapping several ADLs to UML (Medvidovic et al.,
2002). 1 Based on this earlier study, we have imple-
1 A more detailed overview of UML is given in Section 6.
mented a model connector between C2SADEL to UML.
The transformation results in an inter
mediate model
that is represented in UML, but reflects the structure,
details, and properties of the original architectural
model. 2 The model connector is defined by a set of rules
that ensure that every C2SADEL feature is transferred
into UML. A preliminary attempt at such a rule set
was discussed in Abi-Antoun and Medvidovic (1999).
We have since refined and completed these rules. Ad-
ditionally, we have integrated DRADEL with the
Rational Rose UML modeling environment (Abi-
Antoun and Medvidovic, 1999), allowing fully auto-
mated synthesis of UML models from C2SADEL
architectures.
A small excerpt of the rule set comprising the model
connector between C2SADEL and UML models is
shown in Fig. 4. It indicates that, for example, a C2
component is modeled in UML as a collection of ‘‘ste-
reotyped’’ UML elements (classes, operations, and at-
tributes). Stereo-types are an extension mechanism
provided by UML to enable modeling of constructs
(e.g., �C2-Component�) not originally envisioned by
UML�s designers. As demonstrated in Medvidovic et al.
(2002), the semantics of such constructs are specified
formally using UML�s Object Constraint Language
(OCL), which is based on first-order predicate logic
(Booch et al., 1998).
5.3. Application to the cargo router example
The C2 architecture of the cargo router application is
mapped into several UML diagrams as indicated by the
rules in Fig. 4. Each C2 component and connector is
mapped to a specific set of UML class diagrams, rep-
resenting its internal details as modeled in C2SADEL,
while the overall configuration is mapped to UML
component and object diagrams. Fig. 5 shows the syn-
thesized (partial) UML view of the cargo router archi-
2 We should note that the ADL and UML models are not entirely
isomorphic. Space limitations prevent us from further elaborating on
this issue here. Additional details can be found in Medvidovic et al.
(2002).
Fig. 5. Synthesis of an intermediate UML model from the C2 architectural model shown in Fig. 3.
N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 207
tecture. All the details of the architecture represented
in C2SADEL are transferred into this intermediate
model.
6. Software design model connectors
6.1. Modeling software designs
Our support for software design leverages a large
body of mainstream design notations and methodolo-
gies, collected into the UML (Booch et al., 1998). UML
is a graphical language that provides a useful and ex-
tensible set of predefined constructs, it is semi-formally
defined, and it has substantial (and growing) tool sup-
port. UML allows designers to produce several models
of a software system via the supported diagrams: class,
object, collaboration, package, component, use-case,
statechart, activity, sequence, and deployment diagrams.
As discussed above, UML allows additional semantic
constraints to be placed on its modeling elements via
OCL.
Once the intermediate UML model is synthesized
from the architecture in the manner discussed in Section
5, that model must be further refined to address the
missing lower-level design issues, such as additional
processing and data elements, specific data structures,
and algorithms. This section discusses model connectors
we have developed to bridge related design models (e.g.,
class diagrams) at different levels of abstraction, as well
as different design models (e.g., class and statechart di-
agrams) at the same level of abstraction.
208 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215
6.2. Inter-design model connectors
In order to help bridge design models, we have de-
vised a set of design model connectors, accompanied by
a set of activities and techniques for identifying incon-
sistencies among the models in an automatable fashion.
We refer to the model connectors, activities, and tech-
niques as a view integration framework (Egyed, 2000).
The view integration framework identifies and supports
two categories of design model transformations: design
refinement and design view transformations. Design re-
finement involves bridging between higher-level and
lower-level views, while design view transformations
provide bridges among different system views at the
same level of abstraction.
As discussed above, UML supports a wide range of
diagrams to model a system. Our view integration
framework currently encompasses eight transformations
between models expressed in four different UML dia-
grams: class, object, sequence, and statechart diagrams.
Due to space constraints, we will discuss the general
principles of the view integration framework, but will
only focus on the details of transformations across class
and object diagrams.
In our investigation of UML diagrams, we have
identified three major transformational dimensions (see
Fig. 6). Views can be seen as abstract or concrete, generic
or specific, and behavioral or structural (Egyed, 2000).
The abstract–concrete dimension was foreshadowed in
Section 5, where a C2 architecture was the abstract view
and the generated UML model the concrete view. The
generic-specific dimension denotes the generality of
modeling information. For instance, a class diagram
naturally describes a relationship between classes that
must always hold, whereas an object diagram describes a
specific scenario. Finally, the behavior–structure dimen-
statechart
view
object
view
sequence
view
class
view
C2SADEL
view
statechart
view
object
view
sequence
view
class
view
instance
type
behaviorstructure
concrete
abstract
Fig. 6. Design model connectors.
sion takes information about a system�s behavior to
infer its structure. For instance, test scenarios (which are
behavioral) depict interactions between objects (struc-
tural) and may thus be used to infer structure.
Manual management of design model connectors
across these three dimensions is often infeasible due to
the complexity of the models. Two factors contribute to
the complexity: (1) the existence of model elements that
are only relevant to one view, but not to others (e.g.,
‘‘helper’’ classes such as theWarehouseCollection in Fig.
8d), and (2) the large number of interdependencies be-
tween model elements that must be traced and under-
stood (e.g., the grey arrows between elements in the four
models shown in Figs. 2, 5, 8, and 9). In order to control
this complexity, we have developed a tool, UML/Ana-
lyzer (Egyed, 2000), that uses an abstraction technique
to eliminate helper classes. UML/Analyzer searches for
class and object patterns and replaces them with simpler,
more abstract patterns of the same type based on a set of
over 60 rules. An excerpt of UML/Analyzer�s rule set is
shown in Fig. 7.
For instance, to identify a mismatch in the class di-
agram shown in Fig. 8d, we need to eliminate the helper
classes availableGoods and aSurplus that ‘‘obstruct’’ our
view of the relationship between aVehicle and aWare-
house. In this example, UML/Analyzer sees an aggre-
gation from aVehicle to availableGoods, followed by a
generalization (inheritance) from availableGoods to
aSurplus, which is, in turn, followed by an association
from aSurplus to aWarehouse (Fig. 8c). The tool then
uses its abstraction rules to replace the class and rela-
tionship patterns. Further applying our abstraction rules
on the example, we end up finding an association rela-
tionship between aVehicle and aWarehouse (Fig. 8a).
This example is further discussed in Section 6.3.
6.3. Application to the cargo router example
As already discussed, we will focus on the application
of design model connectors to class and object views of
the cargo router system. We use the UML model pro-
duced by the transformation discussed in Section 5 as
our starting point. Fig. 9 shows an excerpt of the con-
sistency checking process in the context of cargo router
Fig. 7. Partial rule set used by UML/Analyzer to simplify class and
object diagrams. These rules have been created in collaboration with
the Rational Software Corporation. Rational also implemented our
abstraction method in a tool called Rose/Architect (Egyed and
Kruchten, 1999).
aVehicleaVehicleaVehicle
aVehicle
aWarehouse
Design Excerpt
aSurplus
availableGoods
aWarehouse
IM1IM2IM3
aSurplus
Potential Mismatch:
Vehicle’s ability to interact
with aWarehouse violates
C2 behavior
aWarehouse
availableGoods
aWarehouse
aVehicleCollection
availableGoods
theCargoRouter
theWarehouseCollection
(a) (b) (c) (d)
Fig. 8. Series of intermediate models (from right to left) produced to identify behavioral mismatch.
Fig. 9. Use of an intermediate model to find a structural inconsistency between architecture and design models.
N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 209
(Egyed and Medvidovic, 2000). The figure depicts a
lower-level design (right side) and its intermediate ab-
straction produced by UML/Analyzer in the manner
outlined above (middle). The intermediate model can be
compared more easily with the original model (i.e., ar-
chitecture, shown on the left) to ensure consistency. For
example, the association relationship between CargoR-
outer and Vehicle in the middle diagram is in violation of
the original architecture�s structure since no corre-
sponding link between the two can be found in the C2
architecture (left diagram).
Another potential mismatch between the two models
depicted in Fig. 9 is a result of C2�s rule that two to-
pologically adjacent components (e.g., Vehicle and
Warehouse) are not allowed to directly interact. The
intermediate model again helps to detect that mismatch
as shown in Fig. 8. The object aVehicle is part of avai-
lableGoods, which, in turn, is a child of aSurplus. Since
aSurplus can only access the object aWarehouse (part of
another component), it follows that it is possible for
Vehicle to interact with Warehouse––a violation of the
original architectural model.
7. Properties of model connectors
This paper has presented three classes of model
connectors needed at the ‘‘upstream’’ stages of the
210 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215
software lifecycle. Each of the three is different from the
others and, in this paper, they have been applied only on
our own modeling techniques. At the same time, the
model connectors share several characteristics we believe
to be more generally applicable (e.g., they all employ
intermediate models and a combination of synthesis and
analysis). Explicating such characteristics will help
software researchers and practitioners to better under-
stand software model connectors; it will also potentially
help them in developing their own or adapting existing
techniques for bridging software models.
In this section, we discuss several properties of model
connectors we have identified to date. We illustrate each
property with examples drawn from the model connec-
tors discussed earlier in the paper. The properties can be
organized in two major categories:
• Properties relevant to a model connector as a whole.
The identified properties are purpose, directionality,
automatability, and reliability.
• Properties relevant to the relationships between indi-
vidual elements of the involved models. These specify
the nature of traceability links between the elements.
7.1. Purpose
Models are transformed to achieve certain objectives
during development. The transformation purpose de-
scribes the underlying intent behind a model transfor-
mation. Examples of purposes are refinement, mismatch
detection, or the creation of a stakeholder-specific (e.g.,
user) view.
A single model connector often serves several pur-
poses. For example, the main purpose of the CBSP
model connector is the refinement of WinWin require-
ments negotiation artifacts into architectural elements.
CBSP also supports analysis indirectly, by capturing
architectural trade-offs and mismatches revealed in the
process of architectural modeling. Problems detected
during architectural modeling and simulation can be
captured as CBSP architectural decisions, such as
S: Three seconds system response time not possible due
to limited network bandwidth.
7.2. Directionality
We can distinguish between unidirectional and bi-
directional model connectors. Unidirectional connectors
allow transformation in one direction only. For exam-
ple, in Section 6 (Fig. 6) we discussed a unidirectional
connector that allows derivation of a model�s structural
view from its behavioral view. Another common model
connector that is typically unidirectional is compilation:
it is difficult to derive source code from a compiled
image. Another example is CBSP. While it allows feed-
back from architecture modeling to requirements ne-
gotiation via the traceability links it maintains (recall
Fig. 2), CBSP currently does not make any specific
provisions for actually traversing those links, leaving the
task to humans and external tools.
Bi-directional model connectors establish a ‘‘two-way
bridge’’ between two models. An example of a bi-di-
rectional connector is the bridge between C2SADEL
and UML: the mapping between a C2SADEL model
and the UML model initially generated by the trans-
formation discussed in Section 5 is objective.
7.3. Reliability
Reliability describes the degree of confidence in a
model connector. Reliability depends on the rules that
can be established to guide the application of a model
connector. We distinguish between informal, semi-for-
mal, and formal rules. While model connectors in the
later stages of the lifecycle (e.g., compilation) are typi-
cally based on formal rules, connectors that are em-
ployed early in the process (e.g., CBSP) depend on
heuristics.
For example, transforming a requirements model
into an architecture model is heavily influenced by the
ambiguity and imprecision of natural language and
cannot be considered highly reliable. We have tried to
mitigate that in CBSP via guided, expert-based refine-
ments of negotiation results and guidelines for analyzing
the vote spread of the experts (recall discussion of Fig.
1). The higher degree of formalization of architectural
and design models typically renders a model connector
between them more reliable. At the same time, in our
particular approach to bridging architectures and de-
signs, we faced the problem that several aspects of UML
semantics remain informal. DRADEL, Medvidovic et
al. (1999) has tried to address this issue by placing for-
mal constraints, specified in OCL, on UML modeling
elements (recall Section 5).
7.4. Automation
This property describes the degree to which tools
support the rules guiding a model connector. We dis-
tinguish between manual, semi-automated, and fully
automated support.
To a large extent, the degree of automation depends
upon the level of formality of the involved models. For
example, the derivation of CBSP artifacts from (infor-
mal) requirements is semi-automated using EasyWin-
Win. On the other hand, the comparatively higher
degree of design formalization allows one to build fully
automated model connectors between design models.
For example, UML/Analyzer (Egyed, 2000) automati-
cally synthesizes intermediate models during a trans-
formation. These intermediate models are then used to
N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 211
detect structural and behavioral inconsistencies by em-
ploying automated comparison (i.e., analysis) tech-
niques. As it can be seen in the context of Fig. 8, a series
of intermediate models may be generated by a single
model connector.
7.5. Element relationship properties
The properties discussed thus far characterized model
connectors as a whole. We now turn our attention to
properties of the relationships between individual ele-
ments of different models.
7.5.1. Qualifier
Elements from two models related by a model con-
nector can be unrelated, complementary, redundant, or
contradictory. Model connectors use various mecha-
nisms to identify and/or make use of these types of re-
lationships, as indicated by the following examples.
• Unrelated: If no relationship is established between
two model elements by a model connector, we regard
these elements as unrelated. This happens if certain
elements of the source model are not refined or the
target model deals with different concerns. For exam-
ple, the CBSP voting process emphasizes architec-
tural relevance, helping the architect to focus on the
most relevant subset of the negotiation results and
to ignore unrelated artifacts (e.g., a development
schedule win condition may have no bearing on a
component property CBSP artifact).
• Complementary: If a model element completes infor-
mation provided by another model element we de-
note that relationship as complementary. For
example, the services a C2 component requires are ex-
plicit, first-class constructs in C2SADEL and are used
as the basis of architectural analysis. In the UML
model, these services become a part of system docu-
mentation, intended as a guide to the designer.
• Redundant: A single model element is often used in
multiple models. Relationships among different oc-
currences of such an element can be qualified as re-
dundant. For example, VehicleComponent is
represented in the architecture diagram, as well as
the object and component UML diagrams in Fig. 5.
Such redundancy is unavoidable when a model con-
nector�s source and target models have overlapping
concerns. At the same time, the redundancy presents
a problem in that changes in one such view must al-
ways be propagated to all other views.
• Contradictory: The relationship of two or more ele-
ments is contradictory if it is impossible for (some
subset of) the model properties that depend upon
the elements to be valid simultaneously. For example,
the architectural model in Fig. 9 indicates that no in-
teraction relationship may exist between Vehicle and
CargoRouter, which is contradicted by the design
model.
7.5.2. Cardinality
In addition to the qualifier, the cardinality of the
relationship between model elements has to be identi-
fied. We can distinguish the following relationships.
Examples of each relationship can be found in Fig. 2.
• Transmute: One element of the source model is re-
lated to exactly one element in the destination model.
An example is a win condition that is related to ex-
actly
one component in an architecture.
• Diverge: One element of the source model relates to
multiple elements in the destination model. An exam-
ple is a win condition that is refined into a component
and a connector in an architecture.
• Converge: Multiple elements of the source model are
related to one element in the destination model. Ex-
amples are several win conditions that converge into
one component in an architecture.
7.6. Summary
The table shows the model connectors discussed in
Sections 4.2, 5.2, and 6.2, together with their properties
presented in this Section 2 and revisited above. De-
scribing model connectors in such a way serves several
purposes:
1. it helps to better understand existing software devel-
opment methodologies by characterizing the transi-
tions between the various modeling approaches used,
2. it assists in identifying ‘‘missing links’’ inside method-
ologies, and
3. provides a roadmap for methodology developers who
want to improve their approaches or need to adapt a
methodology to specific needs (automation, high reli-
ability, and so on).
8. Related work
The work described in this paper is related to several
areas of research covering requirements, architecture,
and design modeling and transformation. Our model
connector between requirements and architectures was
applied to WinWin, an example of a class of techniques
that focus on capturing requirements, their tradeoffs,
and their refinements in a structured, but not always
formal manner (Chung et al., 1999; Dardenne et al.,
1993; Kazman et al., 1999; Mullery, 1979; Robertson
and Robertson, 1999). For this reason, even though we
have developed and applied our CBSP approach spe-
cifically in the context of WinWin, we believe CBSP to
be more generally applicable.
Model connector properties
Inter-model properties Inter-model element properties
Elements of inter-
mediate model
Purpose Directionality Reliability Degree of
automation
Qualifier Cardinality
CBSP (requirements-to-architecture)
Cp, Cd, B, S, CP,
BP, SP (see Fig. 2)
Refine requirements
into architecture;
enable backward
traceability between
architecture and re-
quirements
Unidirectional Informal (based on
expert judgement)
Semi-automated in
EasyWinWin
groupware environ-
ment
Unrelated, comple-
mentary, redun-
dant, contradictory
Transmute, diverge,
con
verge
C2SADEL to UML (architecture-to-design)
Class, Class Op.,
�C2-component�
class, etc. (see Fig.
4)
Ensure traceability
of design-level de-
tails to the architec-
ture and vice versa
Bi-directional Formal Fully via the DRA-
DEL to Rational
Rosee Interface
Complementary, re-
dundant
Typically transmute
Class model abstractor (inter-design)
Classes of interme-
diate models (see
Fig. 8)
Identify behavioral
mismatch; ‘‘zoom
out’’ to reduce
complexity
Unidirectional Formal rules and
heuristics
Fully via UML/An-
alyzer
Complementary, re-
dundant, contradic-
tory, unrelated
Transmute, con-
verge
2
1
2
N
.
M
ed
vid
o
vic
et
a
l.
/
T
h
e
J
o
u
rn
a
l
o
f
S
y
stem
s
a
n
d
S
o
ftw
a
re
6
8
(
2
0
0
3
)
1
9
9
–
2
1
5
N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 213
The refinement of requirements into architecture and
design is often discussed in the context of requirements
capture. Generally, those discussions focus on processes
(e.g., Robertson and Robertson, 1999), but not autom-
atable techniques. Our work on refining requirements
extends such a process with a structured transformation
technique and tool support. A handful of other ap-
proaches exist that, at least in principle, also enable
automated refinement of requirements. However, those
approaches are predicated on a more formal treatment
of requirements artifacts (e.g., Nuseibeh et al., 1994)
than a technique such as WinWin would allow.
A key issue in transforming requirements into archi-
tecture and design is effectively tracing development
decisions across modeling artifacts. Researchers have
recognized the difficulties in capturing such traces
(Gieszl, 1992; Gotel and Finkelstein, 1994). Gotel and
Finkelstein (1994) suggest a formal approach for en-
suring the traceability of requirements during develop-
ment. Our approach is less formal, but captures
extensive trace information throughout the development
process, thus satisfying many of the traceability needs
defined in Gieszl (1992) and Gotel and Finkelstein
(1994).
Software architecture researchers have studied the
issue of refining an architecture into a design. An ap-
proach representative of the state-of-the-art in this area
is SADL (Moriconi et al., 1995). SADL incrementally
transforms an architecture across levels of abstraction
using a series of refinement maps, which must satisfy a
correctness-preserving criterion. While powerful, this
transformation technique can be overly stringent (Gar-
lan, 1996). It sacrifices design flexibility to a notion of
(absolute) correctness. Furthermore, formally proving
the relative correctness of architectures at different re-
finement levels may prove impractical for large archi-
tectures and numbers of levels.
Different elements of our model connectors between
architectural and UML models can be found in existing
work. Cheng et al. (1995) enable transformations by
converting models into a formal environment (e.g., al-
gebraic specification) to allow precise reasoning. Like-
wise, our approach, defines C2 architectures in UML via
formal OCL constraints to allow precise reasoning. Al-
though a formal approach to transformation has a
number of advantages, we have found that it is not al-
ways suitable or practical. Several of our design model
connectors are therefore based on diagrammatic trans-
formations of UML analogous to Khriss et al. (1998)
and Koskimies et al. (1998). In fact, we adopted as one
of our inter-design model connectors the approach for
transforming sequence diagrams to statecharts intro-
duced by Koskimies et al. (1998).
The work described in this paper also relates to the
field of transformational programming (Bauer et al.,
1989; Liu et al., 1992; Partsch and Steinbruggen, 1983).
The main differences between transformational pro-
gramming and model connectors are in their degrees of
automation and scale. Transformational programming
is fully automated, though its applicability has been
demonstrated primarily on small, well defined problems
(Partsch and Steinbruggen, 1983). Our approach, on the
other hand, can be characterized only as semi-auto-
mated; however, we have applied it on larger problems
and a more heterogeneous set of models, representative
of real development situations.
9. Discussion and conclusion
In this paper, we have discussed a set of model con-
nectors whose ultimate goal is to facilitate the consistent
transformation of a system�s requirements into its im-
plementation. We believe that this is an important
contribution in that our approach provides some novel
solutions to a difficult problem, studied extensively by
software engineering researchers. For example, the
CBSP model connector provides a good balance of the
structure and flexibility needed to address the problem
of deriving an effective architecture from a system�s re-
quirements. System quality requirements in particular
tend to drive the choice of architecture (Kazman et al.,
1999); at the same time, the ‘‘optimal’’ architecture if
often a discontinuous function of the required quality
level. Highly formal approaches are typically unable to
adequately deal with this discontinuity, while the col-
laborative CBSP approach can handle it more readily.
CBSP addresses the issue by involving experts in a
voting process to determine the architectural relevance
of negotiation artifacts and to identify incomplete and
inconsistent requirements.
Another contribution of this paper lies in its identi-
fication of a set of underlying principles needed to en-
able a series of model connectors: all connectors
discussed in this paper rely on the use of intermediate
models, the coupling of analysis and synthesis of varying
degrees of automation, and a set of shared properties
(recall Section 7). While we have developed and applied
these principles in the context of specific require-
ments, architecture, and design modeling approaches,
we have taken special care to ensure their broader ap-
plicability. Thus, for example, the CBSP approach does
not depend on the use of WinWin, but can instead be
applied to a wide range of requirements model artifacts.
Similarly, we have already applied our ADL-to-UML
model connector to several ADLs (Medvidovic et al.,
2002). Other well understood software model connec-
tors also appear to adhere to these principles. For ex-
ample, compilation is a fully automated, typically
unidirectional, highly reliable synthesis model connec-
tor whose intermediate models include abstract syntax
trees.
214 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215
Our work in this arena continues along several di-
mensions. The MBASE approach and its support for
multiple model categories is used as the conceptual in-
tegration platform for this work. We also integrating the
tool support provided by EasyWinWin, DRADEL, and
UML/Analyzer to facilitate easier development and
implementation of model connectors; we intend to le-
verage all three tools� existing interfaces to Rational
Rose to this end. We are also investigating additional
model connectors that will, in particular, allow the use
of multiple ADLs to enable architectural modeling of
different system characteristics. Finally, we are exploring
the suitability of open hypertext engines (Anderson,
1999) for automatically maintaining the numerous
traceability links produced by our model connectors, a
task our work to date has not supported.
Acknowledgements
This material is partly based upon work supported by
the National Science Foundation under grant no. CCR-
9985441. Effort also sponsored by the Defense Ad-
vanced Research Projects Agency, Rome Laboratory,
Air Force Materiel Command, USAF under agreement
nos. F30602-99-1-0524, F30602-00-C-0200, F30602-00-
C-0218, and F30602-00-2-0615. The US Government is
authorized to reproduce and distribute reprints for
Governmental purposes not-withstanding any copyright
annotation thereon. The views and conclusions con-
tained herein are those of the authors and should not be
interpreted as necessarily representing the official poli-
cies or endorsements, either expressed or implied, of the
Defense Advanced Research Projects Agency, Rome
Laboratory or the US Government. Paul Gr€uunbacher
was supported by a grant from the Austrian Science
Fund (1999/J 1764 ‘‘Collaborative Requirements Ne-
gotiation Aids’’).
References
Abi-Antoun, M., Medvidovic, N., 1999. Enabling the refinement of a
software architecture into a design, UML�99, October.
Anderson, K.M., 1999. Supporting software engineering with open
hypermedia. In: ACM Computing Surveys� Electronic Symposium
on Hypermedia, December.
Batory, D., O�Malley, S., 1992. The design and implementation of
hierarchical software systems with reusable components. ACM
Transactions on Software Engineering and Methodology.
Bauer, F.L., Moller, B., Partsch, H., Pepper, P., 1989. Formal program
construction by transformations––computer-aided, intuition-
guided programming. IEEE Transactions on Software Engineer-
ing 15 (2).
Boehm, B., Egyed, A., Kwan, J., Port, D., Shah, A., Madachy, R.,
1998. Using the WinWin spiral model: a case study. IEEE
Computer 7, 33–44.
Boehm, B., Gr€uunbacher, P., Briggs, B., 2001. Developing groupware
for requirements negotiation: lessons learned. IEEE Software, 46–
55.
Booch, G., Jacobson, I., Rumbaugh, J., 1998. The Unified Modeling
Language User Guide. Addison-Wesley.
Cheng, B.H.C., Wang, E.Y., Bourdeau, R.H., Richter, H.A., 1995.
Bridging the gap between informal and formal approaches to
software development. Software Engineering Research Forum.
Chung, L., Gross, D., Yu, E., 1999. Architectural design to meet
stakeholder requirements. In: Donohoe, P. (Ed.), Software
Architecture. Kluwer Academic Publishers.
Dardenne, A., Fickas, S., van Lamsweerde, A., 1993. Goal-directed
concept acquisition in requirement elicitation. In: 6th Interna-
tional Workshop on Software Specification and Design (IWSSD
6), October.
Egyed, A., 2000. Heterogeneous view integration and its automation.
Ph.D. Dissertation. University of Southern California, August.
Egyed, A., Kruchten, P., 1999. Rose/architect: a tool to visualize
architecture. In: Proceedings of the Hawaii International Confer-
ence on System Sciences, January.
Egyed, A., Medvidovic, N., 2000. A formal approach to heterogeneous
software modeling. In: Conference on the Fundamental Aspects of
Software Engineering, March.
Garlan, D., 1996. Style-based refinement for software architecture.
In: Proceedings of the Second International Software Architec-
ture Workshop (ISAW-2), San Francisco, CA, October, pp. 72–
75.
Gieszl, L.R., 1992. Traceability for integration. In: 2nd International
Conference on Systems Integration, pp. 220–228.
Gotel, O.C.Z., Finkelstein, C.W., 1994. An analysis of the require-
ments traceability problem. In: First International Conference on
Requirements Engineering, pp. 94–101.
Gorlick, M.M., Razouk, R.R., 1991. Using weaves for software
construction and analysis, ICSE 13, Austin, TX, May.
http://www.groupsystems.com/.
Gr€uunbacher, P., Briggs, B., 2001. Surfacing tacit knowledge in
requirements negotiation: experiences using EasyWinWin. In:
Proceedings of the Hawaii International Conference on System
Sciences. IEEE Computer Society.
Kazman, R., Barbacci, M., Klein, M., Carriere, S.J., Woods, S.G.,
1999. Experience with performing architecture tradeoff analysis,
ICSE�99, Los Angeles, CA, May.
Khriss, I., Elkoutbi, M., Keller, R., 1998. Automating the synthesis of
UML statechart diagrams from multiple collaboration diagrams,
UML�98, June.
Koskimies, K., Systa, T., Tuomi, J., Mannisto, T., 1998. Automated
support for modelling OO software. IEEE Software.
Liu, J., Traynor, O., Krieg-Bruckner, B., 1992. Knowledge-based
transformational programming. In: Fourth International Confer-
ence on Software Engineering and Knowledge Engineering.
Mehta, N.R., Medvidovic, N., Phadke, S., 2000. Towards a taxonomy
of software connectors, ICSE 2000, June.
Medvidovic, N., Rosenblum, D.S., Taylor, R.N., 1999. A language
and environment for architecture-based software development
and evolution, ICSE�99, May.
Medvidovic, N., Rosenblum, D.S., Redmiles, D.F., Robbins, J.E.,
2002. Modeling software architectures in the unified modeling
language. ACM Transactions on Software Engineering and
Methodology 11 (1), 2–57.
Medvidovic, N., Taylor, R.N., 2000. A classification and comparison
framework for software architecture description languages. IEEE
Transactions on Software Engineering 26 (1).
Moriconi, M., Qian, X., Riemenschneider, R.A., 1995. Correct
architecture refinement. IEEE Transactions on Software Engi-
neering 21 (4), 356–372.
Mullery, G., 1979. CORE: A method for controlled requirements
specification, ICSE 4, Munich, Germany, September.
http://www.groupsystems.com/
N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 215
Nuseibeh, B., Kramer, J., Finkelstein, A., 1994. A framework for
expressing the relationships between multiple views in require-
ments specification. IEEE Transactions on Software Engineering.
Partsch, H., Steinbruggen, R., 1983. Program transformation systems.
ACM Computing Surveys 15 (3).
Perry, D.E., 1998. Generic descriptions for product line architectures.
In: 2nd International Workshop on Development and Evolution
of Software Architectures for Product Families (ARES II), Spain,
February.
Perry, D.E., Wolf, A.L., 1992. Foundations for the study of software
architectures. Software Engineering Notes.
Robertson, S., Robertson, J., 1999. Mastering the Requirements
Process. Addison-Wesley.
Shaw, M., 1993. Procedure calls are the assembly language of software
interconnection: connectors deserve first-class status. In: Proceed-
ings of the Workshop on Studies of Software Design.
Shaw, M., Garlan, D., 1996. Software Architecture: Perspectives on an
Emerging Discipline. Prentice Hall.
-
Bridging models across the software lifecycle
Introduction
Connecting the software lifecycle
Example application
Software requirements model connectors
Modeling software requirements
Requirements-to-architecture model connector
Application to the cargo router example
Software architecture model connectors
Modeling software architectures
Architecture-to-design model connector
Application to the cargo router example
Software design model connectors
Modeling software designs
Inter-design model connectors
Application to the cargo router example
Properties of model connectors
Purpose
Directionality
Reliability
Automation
Element relationship properties
Qualifier
Cardinality
Summary
Related work
Discussion and conclusion
Acknowledgements
References
ww.sciencedirect.com
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 4
Available online at w
ScienceDirect
journal homepage: www.elsevier .com/locate/cose
Implementing information
security
best practices on software lifecycle processes:
The ISO/IEC 15504 Security Extension
Antoni Lluı́s Mesquida*, Antonia Mas 1
Department of Mathematics and Computer Science, University of the Balearic Islands, Ctra. de Valldemossa,
Km. 7.5, 07122 Palma de Mallorca, Spain
a r t i c l e i n f o
Article history:
Received 9 July 2013
Received in revised form
12 September 2014
Accepted 22 September 2014
Available online 2 October 2014
Keywords:
ISO/IEC 27002
Information security
management
systems
ISO/IEC 15504 (SPICE)
Security extension
Software process improvement (SPI)
* Corresponding author. Tel.: þ34 971 172 99
E-mail addresses: antoni.mesquida@uib.
e
1 Tel.: þ34 971 172 991; fax: þ34 971 173 0
http://dx.doi.org/10.1016/j.cose.2014.09.003
0167-4048/© 2014 Elsevier Ltd. All rights rese
a b s t r a c t
The ISO/IEC 15504 international standard can be aligned with the ISO/IEC 27000 informa-
tion security management framework. During the research conducted all the existing re-
lations between ISO/IEC 15504-5 software development base practices and ISO/IEC 27002
security controls have been analysed and the ISO/IEC 15504 Security Extension has been
developed. This extension details the changes that software companies should make in the
software lifecycle processes for the successful implementation of the related security
controls. To attain our research objectives, we evaluate the ISO/IEC 15504 Security Extension
through case studies in a sample of software development organizations. This study fol-
lows the design science research paradigm that is based on constructive research.
© 2014 Elsevier Ltd. All rights rese
rved.
1. Introduction
Nowadays information has become a very important asset for
companies and, as well as other crucial assets, it requires
special protection. In fact, information should be adequately
protected independently of its format and transmissionmode.
The main objective of information security is to properly
protect information from unauthorized access, use, disclo-
sure, disruption, modification and destruction (Bernard, 2007;
Gerber and von Solms, 2008; Mellado et al., 2010a).
The implementation of information security controls as
those defined in ISO/IEC 27002 is a priority for companies to
1; fax: þ34 971 173 003.
s (A.L. Mesquida), antoni
03.
rved.
assure its continuity, minimise possible injuries and maxi-
mize the return of investment and business opportunities
(Karabacak and Sogukpinar, 2006; Lai andDai, 2009; von Solms
and von Solms, 2001).
In software development companies in particular, infor-
mation security is also fundamental (Mellado et al., 2010b,
2008; Zuccatoy, 2007). A significant number of software com-
panies, that have been or are currently involved in a
process
improvement programme according to ISO/IEC 15504 (ISO/IEC,
2004b, 2004c), demand the implementation of ISO/IEC 27000 as
a security
standard.
In order to guide software organizations involved in pro-
cess improvement programmes according to ISO/IEC 15504 in
a.mas@uib.es (A. Mas).
mailto:antoni.mesquida@uib.es
mailto:antonia.mas@uib.es
http://crossmark.crossref.org/dialog/?doi=10.1016/j.cose.2014.09.003&domain=pdf
www.sciencedirect.com/science/journal/01674048
www.elsevier.com/locate/cose
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 420
the implementation of the ISO/IEC 27000 standard, even
obtaining a certification against ISO/IEC 27001 (ISO/IEC 2013a),
it is necessary to adequately select and efficiently implement
the appropriate security controls between all the
controls
provided by the ISO/IEC 27002 standard (ISO/IEC 2013b).
During the last years, several initiatives relating quality
and security best practices have emerged (Boynton, 2007; Da
Veiga and Eloff, 2010; Knapp et al., 2009; Lepmets et al., 2012;
Xiao-yan et al., 2011; Zvanut and Bajec, 2010). Barafort et al.
(2006) developed a process reference model and a process
implementation model which provide a framework for
assessing and increasing process capability and organisa-
tionalmaturity in the field information security. Valdevit et al.
(2009) proposed a guide for amore affordable, easier and faster
way to implement a vast majority of ISO/IEC 27001 in SMEs.
The authors of this paper are experienced in implementing
ISO/IEC 15504 in software companies (Amengual and Mas,
2007; Mas and Amengual, 2005; Mas et al., 2012, 2010) and in
using multiple standards in a combined way (Amengual and
Mas, 2003; Mesquida et al., 2009; Pardo et al., 2012). We have
also examined the relationship between this standard with
other ISO standards, such as ISO 9001 (Amengual and Mas,
2003; Mas and Amengual, 2004) and ISO/IEC 20000 (Mesquida
et al., 2012). Moreover, we have analysed the alignment of
ISO/IEC 15504 and other software process assessment and
improvement models such as CMMI-DEV (SEI, 2010), ITmark
(ITmark, 2013) and Competisoft (Oktaba et al., 2007) and taken
into account the lessons learned from the development of
other models based on ISO/IEC 15504 (Garz�as et al., 2013;
Tudor,
2009).
With the main intention of joining forces in the combined
implementation of ISO/IEC 15504 and ISO/IEC 27000, we
focused on the relationship between the base practices of ISO/
IEC 15504-5 (ISO/IEC, 2006) and the security controls of ISO/IEC
27002 with a double objective:
� To facilitate the implementation of ISO/IEC 27001 in orga-
nizations which have already reached a particular matu-
rity level according to ISO/IEC 15504.
� To define a method for the implementation of ISO/IEC
15504 that already considers the ISO/IEC 27001 security
aspects.
After a complete analysis of all the existing relations be-
tween ISO/IEC 15504-5 processes and ISO/IEC 27002 security
controls, it can be stated that ISO/IEC 15504-5 considers, or
could easily consider, an important number of the security
aspects which are necessary for the implementation of an
Information Security Management System. Consequently,
software companies which have been involved in a process
improvement programme according to ISO/IEC 15504 could
take advantage of their experience in the implementation of
the proposed base practices in order to implement the
selected ISO/IEC 27002
security controls.
Delving into this result, from the existing relations be-
tween the ISO/IEC 27002 security controls and the ISO/IEC
15504-5 base practices
, and after analysing in depth the pur-
pose and requirements of each security control and the
related base practices, a security extension to ISO/IEC 15504 is
proposed. The ISO/IEC 15504 Security Extension describes the
adaptations and modifications that should be done in ISO/IEC
15504-5 processes in order to include the security aspects of
the ISO/IEC 27002 related controls.
At the time of constructing this security extension we
analysed the structure and contents of the ISO/IEC TS 15504-
10 standard (ISO/IEC, 2011), which provides specialized pro-
cesses and techniques for developing safety-related systems.
This safety extension describes three new processes: safety
management, safety engineering and safety qualification. The
goal of our new security extension was to detail all process
amplifications in the existing ISO/IEC 15504-5 software
development processes to cover ISO/IEC 27002
information
security controls.
Moreover, we examined the alignment of ISO/IEC 15504
and other software process assessment and improvement
models such as CMMI-DEV (SEI, 2010), ITmark (ITmark, 2013)
and Competisoft (Oktaba et al., 2007) and also took into ac-
count the lessons learned from the development of other
models based on ISO/IEC 15504 (Garz�as et al., 2013; Tudor,
2009).
This paper presents the ISO/IEC 15504 Security Exten
sion and
how it can be used by an organization involved in a software
process improvement initiative to facilitate the implementa-
tion of ISO/IEC 27000 security aspects. The paper is structured
as follows: Section 2 describes the research method used to
meet the research objectives. Section 3 presents the interna-
tional standards used and the process followed to develop the
ISO/IEC 15504 Security Extension. Section 4 describes how the
security extension can be applied in software development
organizations and section 5 shows the lessons learned from
its validation in industry. Finally, Section 6 concludes this
paper and opens discussions regarding the results.
2. Research method and approach
This study follows the design science research paradigm that
is based on constructive research. The design science para-
digm is fundamentally about problem-solving and it seeks to
create artefacts to solve identified organizational problems
(Hevner et al., 2004). Design science attempts to create things
that serve human purposes and these things are then
assessed against criteria of value or utility. Rather than posing
theories as in natural science, design science strives to create
models, methods, and implementations that are innovative
and valuable (March and Smith, 1995).
As shown in Fig. 1, in design science a method or model is
first built for specific purposes, and then evaluated to deter-
mine howwell it works (March and Smith, 1995). In building an
artefact we first have to demonstrate that it is needed, i.e. we
have to illustrate the problem relevance as described by
Hevner et al. (2004), and that the artefact can be constructed to
address an important organizational problem (March and
Smith, 1995). Once the artefact has been built, we need to
know if it performs the specific task it was built for. In order to
know how well the artefact works, the artefact must be eval-
uated scientifically to see if any progress has been made
compared to existing solutions. Design science research ef-
forts may begin with simplified conceptualization and repre-
sentation of problems but with the changes in organizational
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
Fig. 1 e Design science research paradigm (adapted from Hevner et al. (2004)).
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 4 21
environments, assumptions made in prior research may
become invalid and need to be revisited and the artefact
refined. Evaluation is therefore an iterative cycle where
rigorous scientific evaluation methods are used (Hevner et al.,
2004) to review and refine the artefact.
The evaluation strategy considered naturalistic (e.g., field
setting) versus artificial evaluation (e.g., laboratory setting)
(Venable et al., 2012).
Following the principles of constructive research (J€arvinen,
2001), we first developed the ISO/IEC 15504 Security Extension
based on existing knowledge in different domains (Mesquida
et al., 2009, 2012; Mas et al., 2010), and then we evaluated
the extension in industry to determine its validity in a sample
of its end-users. Validity means that the framework works
and does what it is meant to do; that it is dependable in
operational terms in achieving its goals (Gregor and Hevner,
2013).
As shown on Fig. 1, the scientific knowledge base produced
by information security, process improvement, measurement
frameworks and systems thinking researchers is related in
this paper to the pragmatic and creative work of the IT
practitioners.
Although the different aspects of information security are
considered critical and vital for software development com-
panies, they tend not to be often measured, systemically
analysed and deployed on their production processes.We aim
to fill that gap in three iterative cycles through the develop-
ment, evaluation and refinement of the ISO/IEC 15504 Security
Extension.
In the first iteration, the existing principles of information
security management and process improvement measure-
ment practices were collected and synergised resulting in the
preliminary ISO/IEC 15504 Security Extension described in
greater detail in Section 3. We used the existing body of
knowledge of information security management to build the
extension: the information security management ISO/IEC
27000 family of standards (ISO/IEC, 2013a; ISO/IEC, 2013b) with
the measurement framework elements from the ISO/IEC
15504-2 (ISO/IEC, 2004c) standard.
In the second iteration, we further evaluated the extension
to understand its validity in industry through testing it in a
small sample of software development organizations. This
perspective offers the possibility of evaluating the extension
in reality, not just in theory. Naturalistic evaluation methods
offer the possibility to evaluate the artefact by practitioners.
Section 5 provides the results of the validation of the ISO/IEC
15504 Secu
rity Extension.
As a result of the second iteration, the extension will be
refined addressing the gaps, weaknesses and areas of
improvement detected by information security management
practitioners.
3. Development of the ISO/IEC 15504
Security Extension
This section outlines the systematic approach adopted during
the first iteration in order to map the ISO/IEC 27002 security
controls and the ISO/IEC 15504-5 base practices and develop
the ISO/IEC 15504 Security Extension. Moreover, an analysis
of all the detected relations between them is provided.
The complete mapping between the ISO/IEC 27002 controls
and the ISO/IEC 15504-5 base practices can be found in
Appendix 1.
3.1. Standards used
The structure of the international standards used to build the
security extension is firstly introduced.
3.1.1. ISO/IEC 27000 series
The ISO/IEC 27000 series, also known as the Information Se-
curity Management System (ISMS) Family of Standards, pro-
vides best practice recommendations on information security
management, risks and controls within the context of an
overall ISMS. In order to conduct the research presented in
this paper only two standards of this series, ISO/IEC 27001 and
ISO/IEC 27002, have been used.
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
Table 2 e ISO/IEC 27002 Category
structure.
Category name
Control Objective
Controls
(For each control
of the Category)
Control name Control description
Implementation guidance
Other information
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 422
ISO/IEC 27001 Information technology e Security tech-
niques e Information security management systems e Re-
quirements (ISO/IEC, 2013a) promotes the adoption of a
process approach and specifies the requirements for estab-
lishing, implementing, operating, monitoring, reviewing,
maintaining and improving a documented ISMS within the
context of an organization. This standard can be used in order
to assess conformance by interested internal and external
parties. The requirements set out in ISO/IEC 27001 are generic
and are intended to be applicable to all organizations,
regardless of type, size and nature. The standard is aligned
with ISO 9001 and ISO 14001 in order to support consistent and
integrated implementation and operation with related man-
agement standards. It is designed to enable an organization to
align or integrate its ISMS with related management system
requirements.
ISO/IEC 27002 Information technology e Security tech-
niques e Code of practice for information security controls
(ISO/IEC, 2013b) is the rename of the ISO/IEC 17799 standard.
It establishes guidelines and general principles for initi-
ating, implementing, maintaining, and improving informa-
tion security management in an organization. The control
objectives and controls of this international standard pro-
vide general guidance on the commonly accepted goals of
information security management. This standard may serve
as a practical guideline for developing organizational secu-
rity standards and effective security management practices
and to help to build confidence in inter-organizational ac-
tivities. ISO/IEC 27002 contains 14 security control clauses
collectively containing a total of 35 security categories and
114 controls. Table 1 summarizes the structure of the
standard.
Each category contains a control objective, stating what is
to be achieved, and one ormore controls that can be applied to
achieve the control objective. Control descriptions are struc-
tured into three different fields: control, implementation
guidance and other information. Table 2 shows this Category
structure.
Table 1 e ISO/IEC 27002 structure.
ISO/IEC 27002 clauses Categories Controls
5 Information security policies 1 2
6 Organization of information security 2 7
7 Human resource security 3 6
8 Asset management 3 10
9 Access control 4 14
10 Cryptography 1 2
11 Physical and environmental security 2 15
12 Operations security 7 14
13 Communications security 2 7
14 System acquisition, development and
maintenance
3 13
15 Supplier relationships 2 5
16 Information security incident
management
1 7
17 Information security aspects of
business continuity management
2 4
18 Compliance 2 8
Total 35 114
3.1.2. ISO/IEC 15504
ISO/IEC 15504 Information technology e Process assessment
(ISO/IEC, 2004b), also known as SPICE (Software Process
Improvement and Capability dEtermination), is an Interna-
tional Standard for process assessment and improvement. It
can be used by any organization to determine the current and
potential capability of its own processes, and also to define
areas and priorities for process improvement. ISO/IEC 15504 is
composed of ten parts that provide guidance to process
assessment. In order to perform a process assessment con-
formant with ISO/IEC 15504-2 (ISO/IEC, 2004c) a Process
Assessment Model (PAM), based upon a suitable Process
Reference Model (PRM), needs to be properly defined.
ISO/IEC 15504-5 (ISO/IEC, 2006) describes an exemplar PAM
for the particular case of the software lifecycle processes
defined in ISO/IEC 12207 Software life cycle processes (ISO/IEC,
2004a). In this part the standard defines process performance
indicators, also known as Base Practices (BP), for each one of
the 48 software lifecycle processes which are structured in 9
process groups. Table 3 shows these nine process groups, the
number of processes and the number of base practices per
group.
ISO/IEC 12207 describes each process in terms of a process
name, a process purpose and process outcomes. ISO/IEC
15504-5 extends this definition of a process by adding infor-
mation in the form of a set of base practices, which provide a
definition of the tasks and activities needed to accomplish the
process purpose and fulfil the process outcomes, and a num-
ber of input and output work products related to the process
outcomes. The complete structure of a process is shown in
Table 4.
3.2. Analysis of the relations between ISO/IEC 27002
and ISO/IEC 15504-5
The analysis of the relations between the two standards was
done by following an iterative and evolving strategy in which
each one of the ISO/IEC 27002 information security controls
Table 3 e ISO/IEC 15504-5 summary of process groups.
ISO/IEC 15504-5 process groups Processes Base practices
Acquisition (ACQ) 5 23
Supply (SPL) 3 25
Engineering (ENG) 12 66
Operation (OPE) 2 11
Management (MAN) 6 52
Process improvement (PIM) 3 23
Resource & infrastructure (RIN) 4 29
Reuse (REU) 3 26
Support (SUP) 10 73
Total 48 328
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
Table 4 e ISO/IEC 15504-5 process structure.
Process ID
Process Name
Process Purpose
Process Outcomes
Base Practices
Work Products
Inputs Outputs
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 4 23
was compared with the base practices of the ISO/IEC 15504-5
processes. Fig. 2 shows the procedure used to detect the re-
lations between these two standards. This successive refine-
ment process flow consists of three activities, which are
described
below.
1. With the aim of sharing knowledge and contrasting the
different points of view of the authors, the relations be-
tween the standards were analysed as a group. It took
several working sessions (joint meetings) to obtain a pre-
liminary version of the whole mapping. During each
meeting two or three of the 14 ISO/IEC 27002 clauses were
analysed. As sown in Fig. 3, for each of the 114 security
controls in the 35 categories, the fields Description, Imple-
mentation guidance and Other information were analysed in
depth. It should be noted that the authors’ knowledge of
the ISO/IEC 15504 standard facilitated the initial selection
of the set of processes related to the control under
consideration. After a detailed analysis of the base prac-
tices of the ISO/IEC 15504-5 selected processes, it was
possible to determine the existence or not of a connection
between the ISO/IEC 27002 control and a particular ISO/IEC
15504-5 process.
2. In the second activity, and with the aim of consolidating
the results of the joint meetings, the first version of the
mapping was again examined individually to confirm the
decisions reached or, conversely, make modifications on
the preliminary version.
3. Finally, during the joint review activity, the proposals from
each of the authors were discussed thoroughly, until a
general consensus to accept or reject each proposal was
reached.
3.2.1. Types of correspondence between ISO/IEC 27002 and
ISO/IEC 15504-5
From the analysis of the relations between ISO/IEC 27002
controls and ISO/IEC 15504-5 base practices, five different
Fig. 2 e The mappin
types of correspondence between both standards were
established:
1. Correspondence between a control and thewhole set of the
base practices of a process. The connection between the
12.1.2 Change Management control and the base practices of
the SUP.10 Change request management process can be
considered an example of this case. Although this set of
base practices is performed in order to ensure that changes
to products in development are managed and controlled,
the same set of base practices could be performed in order
to manage changes to information processing facilities in
the manner indicated by the
control.
Another example of this case can be observed in the
connection between the 12.1.1 Documented operating
procedures
control and the SUP.7 Documentation process.
2. Correspondence between the control and part of the set of
the base practices of a process. This is the case of the 12.3.1
Information backup control which is clearly related to
SUP.8.BP10 Manage the backup, storage, archiving,
handling and delivery of configured items and
RIN.4.BP2
Define the infrastructure requirements. The description of
this control states that backup copies of information,
software and system images shall be taken and tested
regularly in accordance with the agreed backup policy.
This description fits with SUP.8.BP10 description: Ensure
the integrity and consistency of configured items through
appropriate scheduling and resourcing of backup, storage and
archiving. Control the handling and delivery of configured
items.
Likewise, the control description also fits with RIN.4.BP2
description: Define the infrastructure requirements to support
the performance of appropriate processes. Infrastructure
process requirements may include: security, throughput and
data sharing requirements, backup and recovery, remote ac-
cess facility, physical workspace and equipment, user support
requirements and maintenance requirements.
3. Correspondence between a control and a process. In this
case there is a correspondence between a control and a
process without an explicit connection with a particular
base practice of the process. The relation has been identi-
fied by comparing the control description with the process
purpose.
g process flow.
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
Fig. 3 e Procedure used to detect the relations between ISO/IEC 27002 and ISO/IEC
15504-5.
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 424
This is the case of the
6.1.5 Information security in project
management control with the MAN.3 Project Management pro-
cess. The description of this control states that information
security shall be addressed in projectmanagement, regardless
of the type of the project. The purpose of MAN.3 is to identify,
establish, co-ordinate, and monitor the activities, tasks, and
resources necessary for a project to produce a product and/or
service, in the context of the project’s requirements and con-
straints. In this case, in order to include the security aspects
considered by the control in the related process two possible
solutions could be undertaken. On the one hand, a new base
practice could be added to the process in order to satisfy the
control objective. The description of this new base practice
could be adapted from the control implementation guidance.
On the other hand, the description of the existent base prac-
tices and the process purpose could be modified or expanded.
For the particular of case of MAN.3, MAN.3.BP1 Define the
scope of work, MAN.3.BP4 Determine and maintain estimates
for project attributes, MAN.3.BP5 Determine project activities
and tasks, MAN.3.BP9 Allocate responsibilities, MAN.3.BP10
Establish project plan and MAN.3.BP11 Implement the project
plan should be expanded in order to meet the control objec-
tive. Moreover, the process purpose could also be changed to
“to identify, establish, co-ordinate, and monitor the activities,
tasks, resources and information security implications
necessary for a project to produce a product and/or service, in
the context of the project’s requirements and constraints”.
4. Nonexistence of a correspondence between a control and a
process. This is the case of controls 12.4.3 Administrator and
operator logs and 12.4.4 Clock synchronization. Because of its
particular nature, these controls are related to system
administration activities which are not covered by ISO/IEC
15504-5.
5. Correspondence between a control and the RIN.4 Infra-
structure process. In this case, a control is only related to
the RIN.4 Infrastructure process which purpose is to main-
tain a stable and reliable infrastructure that is needed to
support the performance of any other process. The
RIN.4
base practices most frequently connected are RIN.4.BP2
Define the infrastructure requirements and RIN.4.BP4
Establish the infrastructure.
An example of this case can be observed in the first control
of the category 12.4 Logging and monitoring, 12.4.1 Event log-
ging, which objective is to produce, keep and regularly review
event logs recording user activities, exceptions, faults and
information security events. If this objective is understood as
a security infrastructure requirement, the control should be
related to RIN.4.BP2 and RIN.4.BP4.
3.2.2. Summary of the relations between ISO/IEC 27002 and
ISO/IEC 15504-5
Table 5 shows a high level view of the relations between the
ISO/IEC 27002 clauses and the ISO/IEC 15504-5 process groups.
Appendix 1 shows at a more detailed level the complete
mapping between the ISO/IEC 27002 controls and the ISO/IEC
15504-5 base
practices.
Table 5 can be analysed from two different points of view.
On the one hand, an analysis by columns gives information
about the relations from the perspective of ISO/IEC 15504 pro-
cessgroups.On theotherhand,ananalysisby rowsdetermines
the relations from the perspective of ISO/IEC 27002 controls.
Beginning with an analysis of Table 5 by columns, it can be
seen that the Resource and Infrastructure process group (RIN) is
the only process group that is related to almost all ISO/IEC
27002 clauses, except clause 10 Cryptography. This process
group consists of processes performed in order to provide
adequate human resources and the necessary infrastructure
as required by any other process. Not surprisingly, the re-
lations established between this process group and the ISO/
IEC 27002 clauses are quite evident.
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
Table 5 e Summary of the relations between the ISO/IEC 27002 Clauses and the ISO/IEC 15504-5 process groups.
ISO/IEC 27002 clauses ISO/IEC 15504-5 process groups
ACQ SPL ENG OPE MAN PIM RIN REU SUP
5 Information security policies ✓ ✓
6 Organization of information security ✓ ✓
7 Human resource security ✓ ✓
8 Asset management ✓ ✓
9 Access control ✓ ✓ ✓
10 Cryptography
11 Physical and environmental security ✓
12 Operations security ✓ ✓ ✓ ✓
13 Communications security ✓ ✓ ✓
14 System acquisition, development and maintenance ✓ ✓ ✓ ✓ ✓ ✓
15 Supplier relationships ✓ ✓ ✓
16 Information security incident management ✓ ✓ ✓
17 Information security aspects of business continuity management ✓ ✓ ✓
18 Compliance ✓ ✓ ✓ ✓ ✓ ✓
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 4 25
On the contrary, the Operation process group (OPE) and the
Reuse process group (REU) have a weak or non-existent
connection with any clause in ISO/IEC 27002. The OPE pro-
cess group contains base practices for the correct operation
and use of the software product and/or service. Consequently,
it is hardly surprising that no relation with the ISO/IEC 27002
standard has been found.
The purpose of the REU processes is to manage the life of
reusable assets and to plan, establish, manage, control, and
monitor an organization’s reuse program to systematically
exploit reuse opportunities. These activities are better related
to the ISO/IEC 27001 standard than to ISO/IEC 27002. That is
the reason why no evidences of REU base practices in ISO/IEC
27002 controls have been identified.
Finally, analysing Table 5 from the perspective of the ISO/
IEC 27002 clauses, it can be observed that the clause 11 Physical
and environmental security has only weak connections with the
RIN process group. Moreover, clauses 5 Information security
policies, 6 Organization of information security and 7 Human
resource security are only related to the MAN and RIN process
groups and clause 8 Asset management is only related to the
RIN and SUP process groups. Conversely, clauses 14 System
acquisition, development and maintenance and 18 Compliance are
related to six different process groups.
Controls in clause 14 System acquisition, development and
maintenance are aimed at ensuring that information security is
an integral part of information systems across the entire
lifecycle and is designed and implemented within the devel-
opment lifecycle of information systems. Being such a
Table 6 e Kinds of actions proposed by the ISO/IEC 15504 Secu
Kind of action
1 To use the ISO/IEC 15504-5 process purpose or its base pract
manage the security requirements of the related control
2 To modify or extend ISO/IEC 15504-5 base practices
3 To add a new base practice from the related control objectiv
linked to the existent base practices
4 To modify or extend the purpose of an ISO/IEC 15504 process
transversal clause, its controls are applicable to base practices
of procurement, engineering, management and support pro-
cesses during the whole
software development lifecycle.
The clause 18 Compliance contains controls for avoiding
breaches of legal, statutory, regulatory or contractual obliga-
tions related to information security and ensuring that infor-
mation security is implemented and operated in accordance
with the organizational policies and procedures. Conse-
quently, these controls are also applicable during the entire
software development lifecycle.
4. The ISO/IEC 15504 Security Extension
The ISO/IEC 15504 Security Extension details the changes
needed to be made in the ISO/IEC 15504-5 processes in order
make them compliant with the security requirements of the
related ISO/IEC 27002 controls. This extension has been
developed from the relations detected between the base
practices proposed by ISO/IEC 15504-5 and the security con-
trols of the ISO/IEC 27002 standard.
The modifications and amplifications proposed by the ISO/
IEC 15504 Security Extension can affect to different process
components: process purpose, process outcomes, base prac-
tices or work products. Table 6 shows the four different kinds
of actions to be performed on an ISO/IEC 15504-5 process in
order that it covers a specific ISO/IEC 27002 security control.
In order to clarify the meaning and the results of each kind
of action proposed by the ISO/IEC 15504 Security Extension
rity Extension.
ISO/IEC 15504 process component affected
ices to Process purpose (No modification)
Base practice (Expansion)
Process outcomes (Revision)
e, closely Base practice (Creation)
Process purpose (Expansion)
Process outcomes (Revision)
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
Table 7 e ISO/IEC 27002 controls related to the
ACQ.3
Contract agreement process.
ISO/IEC 27002 controls related to the ACQ.3 process
13.1.2 Security of network
services
13.2.2 Agreements on information transfer
14.2.7 Outsourced development
15.1.1 Information security policy for
supplier relationships
15.1.2 Addressing security within supplier
agreements
15.1.3 Information and communication
technology supply chain
18.1.2 Intellectual property
rights
18.1.4 Privacy and protection of personally
identifiable information
18.1.5 Regulation of cryptographic controls
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 426
different examples for some security controls are provided
below.
Kind of action 1: To use the ISO/IEC 15504-5 process pur-
pose or its base practices tomanage the security requirements
of the related control. In this first case, ISO/IEC 15504-5 base
practices can be directly used to satisfy the security aspects of
the related control. No process modification or amplification
needs to be done to completely cover the security control.
One example of this case can be observed in the connection
between the 12.1.2 ChangeManagement control (Changes to the
organization, business processes, information processing fa-
cilities and systems that affect information security shall be
controlled) and the SUP.10 Change request management process
whose purpose is to ensure that changes to products in
development are managed and controlled. The SUP.10 base
practices BP1 to BP9 can be performed in order to manage
changes to information processing facilities and systems that
affect information security in the manner indicated by the
related control.
Another example of this case is the relation between the
12.1.1 Documented operating procedures control (Operating pro-
cedures shall be documented and made available to all users
who need them) and the SUP.7 Documentation process whose
purpose is to develop and maintain the recorded information
produced by a process. The SUP.7 base practices BP1 to BP8 can
be performed in order to develop and make available the
operating procedures.
Kind of action 2: To modify or extend ISO/IEC 15504-5 base
practices. In this case, the related ISO/IEC 15504-5 base prac-
tices could be widened to cover all the security aspects of the
control.
One example of this case can be observed in the relation
between the 16.1.2 Reporting information security events control
(Information security events shall be reported through
appropriatemanagement channels as quickly as possible) and
the RIN.3.BP4 Capture knowledge (Identify and record each
knowledge item according to the classification schema and
asset criteria). In order to cover all the security aspects of the
control, the description of RIN.3.BP4 could be widened with
the underlined sentence: Identify and record each knowledge
item according to the classification schema and asset criteria,
including information security events through appropriate
management channels as quickly as possible.
Another example of this case is in the connection between
the 7.2.2 Information security awareness, education, and training
control (All employees of the organization and, where rele-
vant, contractors shall receive appropriate awareness educa-
tion and training and regular updates in organizational
policies and procedures, as relevant for their job function. On-
going training should include security requirements, legal
responsibilities and business controls, as well as training in
the correct use of information processing facilities) and the
RIN.2.BP2 Identify needs for training (Identify and evaluate skills
and competencies to be provided or improved through
training). As the previous example, the description of this base
practice could be widened to state: Identify and evaluate skills
and competencies to be provided or improved through
training, including security requirements, legal re-
sponsibilities and business controls, as well as training in the
correct use of information processing facilities.
Kind of action 3: To add a new base practice from the
related control objective, closely linked to the existent base
practices. In this case, the related ISO/IEC 15504-5 process
does not have any specific base practice that covers the se-
curity control and, therefore, it is necessary to create a new
one.
One example is the case of the
14.3.1 Protection of test data
control (Test data shall be selected carefully, protected and
controlled. If personally identifiable information or otherwise
confidential information is used for testing purposes, all
sensitive details and content should be protected by removal
or modification). This control is related to the ENG.8 Software
testing processwhose purpose is to confirm that the integrated
software product meets its defined requirements. In this case,
a new base practice has been created: ENG.8.BP0 Protect test
data (Remove or modify beyond recognition before use, pro-
tect and control all personal or sensitive information used for
testing purposes).
A second example can be observed in the 7.1.2 Terms and
conditions of employment control (The contractual agreements
with employees and contractors shall state their and the or-
ganization’s responsibilities for information security), which
is related to the RIN.1 Human resource management process
purpose (Provide the organization and projects with in-
dividuals who possess skills and knowledge to perform their
roles effectively and to work together as a cohesive group). In
order to cover the security aspects of the control, the
description of the new base practice, called RIN.1.BP4 Assign
responsibilities for information security, should be: Assign infor-
mation security responsibilities according to the skills and
competencies of recruited staff.
Kind of action 4: Tomodify or extend the purpose of an ISO/
IEC 15504 process. In this case, there is a correspondence be-
tween a control and a process without an explicit connection
with a particular base practice of the process. The relation has
been identified by comparing the control description with the
process purpose. Consequently, the action to be performed
should consist on modifying or expanding the process pur-
pose in order to cover the
security requirements of the control.
One example of this case can be observed in the ACQ.3
Contract agreement process whose purpose is to negotiate and
approve a contract/agreement that clearly and unambigu-
ously specifies the expectations, responsibilities, work prod-
ucts/deliverables and liabilities of both the supplier(s) and the
acquirer. This process is related to nine different ISO/IEC
27002 security controls, which are shown in Table 7.
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 4 27
In order to satisfy these controls, contracts or agreements
negotiated and approved according to ACQ.3 should be
widened, including specific clauses:
� including all the security features, service levels, and
management requirements of all network services (to
satisfy control 13.1.2)
� treating the exchange of information and software be-
tween the organization and external parties (to satisfy
control 13.2.2)
� including relevant aspects related to licensing arrange-
ments, code ownership, intellectual property rights, rights
of access for audit of the quality and accuracy of work done
and contractual requirements for quality and security
functionality of code, when software development is out-
sourced (to satisfy control 14.2.7)
� involving accessing, processing, communicating or man-
aging the organization’s information or information pro-
cess facilities (to satisfy controls 15.1.1, 15.1.2 and 15.1.3)
� ensuring the compliance with legislative, regulatory, and
contractual requirements on the use of material in respect
of which there may be intellectual property rights and on
the use of proprietary software products (to satisfy control
18.1.2)
� ensuring data protection and privacy as required in legis-
lation and regulation agreed (to satisfy control 18.1.4)
� referring to the cryptographic controls that should be used
in compliance with all relevant agreements, laws, and
regulations agreed (to satisfy control 18.1.5)
In this way, if an organization which has implemented the
ACQ.3 base practices adds to the standard contract the former
clauses, it would have also implemented the nine ISO/IEC
27002 security controls related to this process.
4.1. Application of the ISO/IEC 15504 Security Extension
The ISO/IEC 15504 Security Extensionhas a double application. It
could be used, on the one hand:
� To facilitate the implementation of the ISO/IEC 27001
standard in software organizations which are or have been
involved in SPI programmes according to ISO/IEC 15504 or,
on the other hand,
� To facilitate the simultaneous implementation of both ISO/
IEC 27001 and ISO/IEC 15504 standards, avoiding the
Table 8 e Actions proposed by the ISO/IEC 15504 Security Exten
ISO/IEC 15504-5 process Kind of action
SUP.9 Problem resolution management
process
4. To modify or extend the pu
of an ISO/IEC 15504 process.
MAN.5 Risk Management process 4. To modify or extend the pu
of an ISO/IEC 15504 process.
RIN.3 Knowledge Management process 2. To modify or extend ISO/IE
15504-5 base practices
repetition of similar tasks included in both standards, and
therefore, reducing the amount of effort required by the
organization.
In both cases, the organization must firstly select the ISO/
IEC 27002 applicable controls, depending on the kind of or-
ganization and its main activities. For each of these selected
security controls, the ISO/IEC 15504 Security Extension proposes
a set of actions on the ISO/IEC 15504-5 processes to meet the
security requirements of the control.
In order to illustrate the use of this security extension, we
consider, as an example, the implementation of the control
16.1.6 Learning from information security incidents, which
description is: Knowledge gained from analysing and
resolving information security incidents shall be used to
reduce the likelihood or impact of future incidents. There
should be mechanisms in place to enable the types, volumes,
and costs of information security incidents to be quantified
and monitored. The evaluation of information security in-
cidents may indicate the need for enhanced or additional
controls to limit the frequency, damage, and cost of future
occurrences or to be taken into account in the security policy
review process.
In order to satisfy the security requirements related to this
control, the ISO/IEC 15504 Security Extension proposes to
perform different actions in three ISO/IEC 15504-5 processes:
SUP.9 Problem resolution management process, MAN.5 Risk
management process and RIN.3 Knowledge management process.
Table 8 lists the actions to perform on these
processes.
Regarding the two first processes, SUP.9 and MAN.5, their
purposes should bemodified or expanded as shown in Section
4 (kind of action 4). Regarding the RIN.3 process,
RIN.3.BP4
should be extended, as shown in Section 4 (kind of action 2).
5. Validation of the ISO/IEC 15504 Security
Extension
During the second iteration, case studies were conducted in a
small sample of software development organizations in order
to:
1. Evaluate the validity of the ISO/IEC 15504 Security Exten-
sion and
2. Determine what security controls they apply or could be
easily deployed on their development processes.
sion to satisfy control 16.1.6.
Description (guidelines)
rpose SUP.9 Problem resolution management process must
ensure that information security incidents are identified,
analysed, managed and controlled to resolution in the
manner indicated by the security policy
rpose MAN.5 Risk Management process must ensure that
information security incidents are continuously identified,
analysed, quantified, treated and monitored.
C RIN.3.BP4 Capture knowledge should also be extended to
include the capture of information gained from the
evaluation of information security incidents.
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 428
To select organizations to participate in the evaluation we
used a convenience sample drawing on the authors’ industry
contacts of IT managers known to have conducted process
assessments according to ISO/IEC 15504. Next subsection
presents the results of the application of the ISO/IEC 15504
Security Extension in one of the companies that participated in
its validation.
5.1. Case study: validation of the ISO/IEC 15504
Security Extension in a company
This company began its activity in 2000 with a staff of six.
Today, it has 120 employees dedicated to the development of
internet-based marketing and management applications and
the implementation of the infrastructure which supports
them. It provides tailored, unique and global solutions that
include consultancy, training and the technology necessary
for the evolution of customers’ businesses and needs. The
implementation of a quality management system and the ISO
9000 certification obtained by the company initiated what has
become one of themain insignias of the company: quality as a
management strategy. In 2005, the company introduced the
EFQM Excellence Model into its quality management system.
The company initiated a software process improvement
programme according to the ISO/IEC 15504 international
standard by the end of 2007. In 2009 the company incorpo-
rated information security management in its existing man-
agement model and obtained the ISO/IEC 27001 certification.
To date, the company has continued working on the
improvement of its processes and on their deployment in all
its projects. Table 9 shows the capability level of the fourteen
ISO/IEC 15504-5 processes implemented in the organization.
Because the company had already got the ISO/IEC 27001
certification, it applied the ISO/IEC 15504 Security Extension in
order to validate its usefulness, completeness, and suitability.
The company used the security extension to identify and
validate the ISO/IEC 27002 security controls which had been
deployed on each of the ISO/IEC 15504-5 processes imple-
mented in the organization. In addition, the company could
observe that there existed other security controls not covered
so far that could be easily deployed on these processes.
Table 9 e Capability level of the ISO/IEC 15504-5
implemented processes.
ISO/IEC 15504-5 process Capability level
ACQ.3 Contract agreement 1
ACQ.4 Supplier monitoring 1
ACQ.5 Customer acceptance 1
SPL.2 Product release 2
ENG.1 Requirements elicitation 1
ENG.4 Software requirements analysis 1
ENG.8 Software testing 1
ENG.11 Software installation 1
ENG.12 Software and system maintenance 1
MAN.3 Project management 1
MAN.5 Risk management 2
SUP.1 Quality assurance 2
SUP.7 Documentation 2
SUP.9 Problem resolution management 1
Table 10 shows, once applied the ISO/IEC 15504 Security
Extension, the ISO/IEC 27002 security controls deployed on
the ISO/IEC 15504-5 processes implemented in the
company.
32 different security controls have been deployed on thirteen
of the fourteen ISO/IEC 15504-5 implemented processes.
ENG.12 Software and system maintenance process could not be
used to facilitate the implementation of any control, not
being this process directly related to information security
management.
5.2. Lessons learned from the validation of the ISO/IEC
15504 Security Extension
In this section, the remarks we have made during the vali-
dation of the ISO/IEC 15504 Security Extension in the participant
companies are described. Regarding general aspects, we can
state that:
� These companies are fully devoted to their productive
work and to solve their day-to-day survival problems. They
are often unable and unwilling to devote time and efforts to
define new processes or to improve the existing ones.
Software engineers are more oriented to product, service
or management instead of establishing new working
practices.
� Participant companies need external consultancy that of-
fers support in information security process deployment
and improvement, issues that they generally unknown and
consider very complex, utopian and distant.
� Software companies not only need to know what to do in
order to improve their processes, but they need to have
specific procedures describing in detail the work they have
to perform, with a clear set of best practices that will help
to carry them out. These procedures should be simple and
applicable to the types of projects that they normally
undertake.
� They spend very little effort to improve employee training
on information security and, when done, it is not according
to an established training plan, but as an ad-hoc action
derived from a detected short-term need.
� It is not traditionally accustomed to perform information
security riskmanagement activities. Incidents are assumed
and companies react as they can.
Based on the evaluation of the ISO/IEC 15504 Security
Extension we have observed that the organizations which
already have implemented the ISO/IEC 15504 standard can
reuse previous experiences, knowledge, processes and prac-
tices when implementing the applicable ISO/IEC 27002 secu-
rity controls. The following are themost significant examples:
� The ENG.1 Requirements elicitation process can be also used
to gather, process, and track evolving customer needs and
requirements related to information security throughout
the life of the product and/or service.
� The processes MAN.1 Organizational alignment and
MAN.2
Organization management can be also applied to establish
and perform information security management policies
needed for providing software products and services that
are consistent with the business goals of the organization.
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
Table 10 e ISO/IEC 27002 security controls deployed on the ISO/IEC 15504-5 processes.
ISO/IEC 15504-5 process ISO/IEC 27002 security controls deployed on the ISO/IEC 15504-5 process
ACQ.3 Contract agreement 13.1.2 Security of network services
13.2.1 Information transfer policies and procedures
14.2.7 Outsourced development
15.1.1 Information security policy for supplier relationships
15.1.2 Addressing security within supplier agreements
15.1.3 Information and communication technology supply chain
18.1.2 Intellectual property rights
18.1.4 Privacy and protection of personally identifiable information
18.1.5 Regulation of cryptographic controls
ACQ.4 Supplier monitoring 14.2.7 Outsourced development
15.2.1 Monitoring and review of supplier services
15.2.5 Managing changes to supplier services
ACQ.5 Customer acceptance 14.2.7 Outsourced development
14.2.9 System acceptance testing
SPL.2 Product release 8.3.3 Physical media transfer
ENG.1 Requirements elicitation 14.1.1 Information security requirements
analysis and specification
14.1.2 Securing application services on
public networks
14.1.3 Protecting application services
transactions
18.1.1 Identification of applicable legislation
and contractual requirements
18.1.2 Intellectual property rights
18.1.4 Privacy and protection of personally identifiable information
18.1.5 Regulation of cryptographic controls
ENG.4 Software requirements analysis 14.1.1 Information security requirements analysis and specification
14.3.1 Protection of test data
18.1.1 Identification of applicable legislation and contractual requirements
ENG.8 Software testing 12.1.4 Separation of development, testing
and operational environments
14.3.1 Protection of test data
ENG.11 Software installation 12.5.1 Installation of software on
operational systems
MAN.3 Project management 6.1.5 Information security in project management
MAN.5 Risk management 12.6.1 Management of technical
vulnerabilities
16.1.1 Responsibilities and procedures
16.1.2 Reporting
information security events
16.1.3 Reporting information security
weaknesses
16.1.4 Assessment of and decision on information security events
16.1.5 Response to information security
incidents
16.1.6 Learning from information security incidents
SUP.1 Quality assurance 18.2.2 Compliance with security policies and
standards
SUP.7 Documentation 12.1.1 Documented operating procedures
18.1.3 Protection of records
SUP.9 Problem resolution management 16.1.1 Responsibilities and procedures
16.1.2 Reporting information security events
16.1.3 Reporting information security weaknesses
16.1.4 Assessment of and decision on information security events
16.1.5 Response to information security incidents
16.1.6 Learning from information security incidents
16.1.7 Collection of evidence
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 4 29
� MAN.3 Project management base practices can be used to
identify, establish, co-ordinate and monitor the activities,
tasks, and resources necessary for information security, in
the context of the project’s requirements and constraints.
� Similarly, MAN.5 Risk management process can be applied to
identify, analyse, treat and continuously monitor the risks
related to information security issues.
� Having deployed the PIM.1 Process establishment process
means that the organization has already in place a suite of
organizational processes for all life cycle processes as they
apply to its business activities. Information security best
practices can be easily deployed on these processes.
� Thanks to the PIM.3 Process improvement process the exist-
ing information security policies can be continually
improved andmaintained alignedwith the business needs.
� Information security skills and knowledge for staff to
perform their roles effectively can be defined by taking
advantage of the RIN.1 Human resource management process
assets and tools.
� The information security infrastructure requirements
(backup and recovery, remote access facility, physical
workspace and equipment) can be defined using the base
practices and outcomes of the RIN.4 Infrastructure process.
� SUP.7 Documentation process can be used to develop and
maintain the recorded information produced by the in-
formation security activities.
� The SUP.9 Problem resolution management process can be
applied to ensure that all discovered information security
problems are identified, analysed, managed and controlled
to resolution.
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 430
� SUP.10 Change request management process can be used to
ensure that change requests related to information secu-
rity issues are also managed, tracked and controlled.
As key strengths for the ISO/IEC 15504 Security Extension
validation success it is worth highlighting:
� The active participation, commitment and motivation of
top management in all the participant companies. Top
management has always provided and trained the neces-
sary human resources to achieve the stated objectives and
support the business strategy. Moreover, an important
financial investment to facilitate the implementation and
standardization of new procedures and incorporating new
support tools has been required. These changes have
taken place in all departments and at all levels of the
company.
� The willingness to share knowledge among companies. It
is important to note that these companies are in the same
sector and they sometimes compete to obtain a new proj-
ect/client.
6. Conclusion and further work
This paper presented the ISO/IEC 15504 Security Extension
that may be relevant for a software development company
involved in a process improvement programme according
to the ISO/IEC 15504 international standard. The major
contribution of the work is the development and valida-
tion of this software extension, built from a thorough
mapping between the ISO/IEC 27002 security controls and
the ISO/IEC 15504-5 base practices for software lifecycle
processes.
The ISO/IEC 15504 Security Extension details the changes
that should be made in the software lifecycle processes for
the successful implementation of the related security con-
trols. The quality managers can use the ISO/IEC 15504 Secu-
rity Extension to observe all the actions to be performed on
the ISO/IEC 15504-5 processes in order to meet the security
requirements of the selected ISO/IEC 27002 applicable
control.
The validity of the ISO/IEC 15504 Security Extension has been
evaluated in industry. Naturalistic evaluation methods offer
the possibility of evaluating the extension by practitioners in
reality, not just in theory. The valuation of its application in
different software companies in our country is totally positive.
From the feedback we have received from quality de-
partments, it can be stated that ISO/IEC 15504 processes can
easily be adapted to consider an important number of the
security controls needed to establish an Information Security
Management System. Consequently, the ISO/IEC 15504 Security
Extension can be used to facilitate the implementation of ISO/
IEC 27001 in software companies which are currently, or will
be in the near future, involved in a software process
improvement programme according to ISO/IEC 15504. An in-
tegrated implementation of these two international standards
will impact, in themedium term, in the day to day operation of
the business, resulting in a reduction of workload and du-
plicities and in an optimization of the tasks related to the
implementation and maintenance of the recommended best
practices.
This study has its limitations. Firstly, it has to be noted
that, although some ISO/IEC 15504-5 processes can be easily
adapted to cover 93 different ISO/IEC 27002 security controls,
there is still 21 security controls that do not have any relation
to ISO/IEC 15504-5 processes, and therefore, they must be
implemented as indicated in the ISO/IEC 27002 standard.
Secondly, although the case studies were diverse, they were
similar in terms of their market domain. Selecting cases from
various industries may have provided stronger support for the
definition of specific recommendations included in the secu-
rity extension.
Further work is expected to be performed in order to
improve the developed ISO/IEC 15504 Security Extension by
considering the lessons learned from its application in more
software development companies. To date, the extension has
been refined based on the evaluation suggesting additional
clarifications on the terms used by the standards that in-
tegrates. Moreover, the process reference model will be
updated to align to the last version of ISO/IEC 15504-5. As a
result of this new iteration, we will propose a refined ISO/IEC
15504 Security Extension.
The authors plan to continue the research to understand
the benefits and feasibility of widen the scope of the provided
ISO/IEC 15504 Security Extension in order to align it with COBIT 5
(ISACA, 2012). Themain goal of this next iteration is to analyse
the relations among the software lifecycle processes of the
ISO/IEC 15504-5 standard, the information security manage-
ment requirements of the ISO/IEC 27001 standard and the best
practices for the governance andmanagement of enterprise IT
defined by COBIT. As the last two frameworks follow a process
approach and are also based on the Plan-Do-Check-Act (PDCA)
cycle, we intuitively think that the creation of synergies be-
tween the management systems they define and the inte-
gration of their organizational policies and operational
controls is very viable.
Finally, we have initiated the development of a software
tool to support the application of the ISO/IEC 15504 Security
Extension in software development companies.
Acknowledgements
This research has been supported by CICYT-TIN2010-20057-
C03-03 “Simulaci�on aplicada a la gesti�on de equipos, proc-
esos y servicios”, Sim4Gest.
Appendix 1. Mapping between the ISO/IEC 27002
security controls and ISO/IEC 15504-5 base
practices
From the analysis of the rows in Table 5, this appendix shows
all the relations detected between the controls in each of the
fourteen clauses of ISO/IEC 27002 and the base practices of
ISO/IEC 15504-5. In case a control is related to all the base
practices of a process, the table only shows the process name.
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
5 Information security policies
5.1 Management direction for information security
5.1.1 Policies for information security MAN.1.BP1, BP3,
BP4-BP5
RIN.4.BP2
5.1.2 Review of the policies for information
security
MAN.1 Level 2
6 Organization of information security
6.1 Internal organization
6.1.1 Information security roles and
responsibilities
MAN.1
MAN.2 Level 2 (GP 2.1.4)
RIN.1
6.1.2 Segregation of duties RIN.4.BP2
6.1.3 Contact with authorities
RIN.4.BP1-BP2
6.1.4 Contact with special interest groups RIN.4.BP1-BP2
6.1.5 Information security in project
management
MAN.3
6.2 Mobile devices and teleworking
6.2.1 Mobile device policy
RIN.4.BP1-BP2,BP4
6.2.2 Teleworking RIN.4.BP1-BP2,BP4
7 Human resource security
7.1 Prior to employment
7.1.1 Screening RIN.1
7.1.2 Terms and conditions of employment RIN.1
7.2 During employment
7.2.1 Management responsibilities MAN.1
RIN.1.BP2
7.2.2 Information security awareness,
education and training
RIN.1.BP4
RIN.2.BP1-BP7
7.2.3 Disciplinary process e
7.3 Termination or change of employment
7.3.1 Termination or change of employment
responsibilities
e
8 Asset management
8.1 Responsibility for assets
8.1.1 Inventory of assets e
8.1.2 Ownership of assets RIN.4.BP2
8.1.3 Acceptable use of assets RIN.2.BP2,BP5
RIN.4.BP1
8.1.4 Return of assets RIN.4.BP2
8.2 Information classification
8.2.1 Classification of information e
8.2.2 Labelling of information e
8.2.3 Handling of assets RIN.4.BP2
SUP.8.BP10
8.3 Media handling
8.3.1 Management of removable media RIN.4.BP1-BP2
8.3.2 Disposal of media e
8.3.3 Physical media transfer SPL.2.BP8
11 Physical and environmental security
11.1 Secure areas
11.1.1 Physical security perimeter e
11.1.2 Physical entry controls e
11.1.3 Securing offices, rooms and facilities e
11.1.4 Protecting against external and
environmental threats
e
11.1.5 Working in secure areas e
11.1.6 Delivery and loading areas e
11.2 Equipment
11.2.1 Equipment siting and protection RIN.4
11.2.2 Supporting utilities RIN.4
11.2.3 Cabling security RIN.4
11.2.4 Equipment maintenance RIN.4.BP6
11.2.5 Removal of assets RIN.4
11.2.6 Security of equipment and assets off-
premises
RIN.4.BP1-BP2
11.2.7 Secure disposal or re-use of
equipment
RIN.4.BP2
11.2.8 Unattended user equipment
RIN.2.BP5
11.2.9 Clear desk and clear screen policy RIN.4.BP2
9 Access control
9.1 Business requirements of access control
9.1.1 Access control policy RIN.4.BP1-BP2,BP4,BP6
9.1.2 Access to networks and network
services
RIN.4.BP2
9.2 User access management
9.2.1 User registration and de-registration
RIN.1.BP10
9.2.2 User access provisioning RIN.1.BP10
9.2.3 Management of privileged access
rights
RIN.1.BP10
9.2.4 Management of secret authentication
information of users
RIN.1.BP10
9.2.5 Review of user access rights RIN.1.BP10
9.2.6 Removal or adjustment of access rights RIN.4.BP2
9.3 User responsibilities
9.3.1 Use of secret authentication
information
RIN.2.BP5
9.4 System and application access control
9.4.1 Information access restriction RIN.4.BP1-BP2,BP4
9.4.2 Secure log-on procedures e
9.4.3 Password management system e
9.4.4 Use of privileged utility programs e
9.4.5 Access control to program source code SUP.8
10 Cryptography
10.1 Cryptographic controls
10.1.1 Policy on the use of cryptographic
controls
e
10.1.2 Key management e
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 4 31
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
12 Operations security
12.1 Operational procedures and responsibilities
12.1.1 Documented operating procedures SUP.7
12.1.2 Change management
SUP.10
12.1.3 Capacity management e
12.1.4 Separation of development, testing
and operational environments
ENG.7
ENG.8
ENG.9
ENG.10
12.2 Protection from malware
12.2.1 Controls against malware RIN.4.BP2
12.3 Backup
12.3.1 Information backup SUP.8.BP10
RIN.4.BP2
12.4 Logging and monitoring
12.4.1 Event logging RIN.4.BP2,BP4
12.4.2 Protection of log information e
12.4.3 Administrator and operator logs e
12.4.4 Clock synchronisation e
12.5 Control of operational software
12.5.1 Installation of software on
operational systems
ENG.11
12.6 Technical vulnerability management
12.6.1Management of technical
vulnerabilities
MAN.5
12.6.2 Restrictions on software installation RIN.1.BP10
12.7 Information systems audit considerations
12.7.1 Information systems audit controls SUP.5.BP1-BP4
13 Communications security
13.1 Network security management
13.1.1 Network controls RIN.4.BP4,BP6
13.1.2 Security of network services
ACQ.3.BP1
13.1.3 Segregation in networks RIN.4.BP2
13.2 Information transfer
13.2.1 Information transfer policies and
procedures
RIN.4.BP1-BP2,BP4
13.2.2 Agreements on information transfer ACQ.3.BP1,BP2
SPL.1.BP9-BP10
RIN.4.BP1-BP2
13.2.3 Electronic messaging RIN.4.BP2
13.2.4 Confidentiality or non-disclosure
agreements
RIN.1.BP1
14 System acquisition, development and maintenance
14.1 Security requirements of information systems
14.1.1 Information security requirements
analysis and specification
ENG.1.BP1-BP6
ENG.2.BP1-BP6
ENG.3.BP1-BP7
ENG.4.BP1-BP6
14.1.2 Securing application services on
public networks
ENG.1.BP1-BP6
ENG.2.BP1-BP6
RIN.4.BP2
14.1.3 Protecting application services
transactions
ENG.1.BP1-BP6
ENG.2.BP1-BP6
RIN.4.BP2
14.2 Security in development and support processes
14.2.1 Secure development policy
PIM.1
MAN.2
14.2.2 System change control procedures SUP.8
SUP.10
14.2.3 Technical review of applications after
operating platform changes
ENG.7
14.2.4 Restrictions on changes to software
packages
SUP.10
14.2.5 Secure system engineering principles PIM.1
14.2.6 Secure development environment RIN.4
14.2.7 Outsourced development ACQ.1
ACQ.2
ACQ.3
ACQ.4
ACQ.5
14.2.8 System security testing ENG.10
14.2.9 System acceptance testing ACQ.5.BP3
14.3 Test data
14.3.1 Protection of test data ENG.4.BP3
ENG.8
15 Supplier relationships
15.1 Information security in supplier relationships
15.1.1 Information security policy for
supplier relationships
ACQ.2.BP3
ACQ.3.BP1
RIN.4.BP2
15.1.2 Addressing security within supplier
agreements
ACQ.2.BP3
ACQ.3.BP1
RIN.4.BP2
15.1.3 Information and communication
technology supply chain
ACQ.2.BP3
ACQ.3.BP1
15.2 Supplier service delivery management
15.2.1 Monitoring and review of supplier
services
ACQ.4.BP3,BP4
15.2.2 Managing changes to supplier
services
ACQ.4.BP5
SUP.10.BP1-BP9
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 432
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
16 Information security incident management
16.1 Management of information security incidents and
improvements
16.1.1 Responsibilities and procedures SUP.9 Level 2
MAN.5 Level 2
16.1.2 Reporting information security events
SUP.9
MAN.5
RIN.3.BP4
16.1.3 Reporting information security
weaknesses
SUP.9
MAN.5
16.1.4 Assessment of and decision on
information security events
SUP.9
MAN.5
16.1.5 Response to information security
incidents
SUP.9
MAN.5
16.1.6 Learning from information security
incidents
SUP.9
MAN.5
RIN.3.BP4
16.1.7 Collection of evidence SUP.9
RIN.3.BP4
17 Information security aspects of business
continuity
management
17.1 Information security continuity
17.1.1 Planning information security
continuity
MAN.2
RIN.4
17.1.2 Implementing information security
continuity
PIM.1
17.1.3 Verify, review and evaluate
information security continuity
MAN.2
RIN.4
17.2 Redundancies
17.2.1 Availability of information processing
facilities
MAN.2
RIN.4
18 Compliance
18.1 Compliance with legal and contractual requirements
18.1.1 Identification of applicable legislation
and contractual requirements
ENG.1
ENG.2
ENG.4
18.1.2 Intellectual property rights
ACQ.3.BP1-BP3
ENG.1.BP3
SPL.1.BP9-BP10
PIM.1.BP3
18.1.3 Protection of records SUP.7.BP1,BP3,BP6-BP8
SUP.8.BP10
18.1.4 Privacy and protection of personally
identifiable information
ACQ.3.BP1-BP3
ENG.1.BP3
SPL.1.BP9-BP10
RIN.4.BP1-BP4
18.1.5 Regulation of cryptographic controls ACQ.3.BP1-BP3
ENG.1.BP3
SPL.1.BP9-BP10
18.2 Information security reviews
18.2.1 Independent review of information
security
SUP.5.BP1-BP3
18.2.2 Compliance with security policies and
standards
SUP.1.BP1-BP5
18.2.3 Technical compliance review SUP.2.BP3
SUP.3.BP3
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 4 33
r e f e r e n c e s
Amengual E, Mas A. Software process improvement in small
companies: an experience. In: 14th European Software Process
Improvement Conference; 2007. 11.11e8.
Amengual E, Mas A. A new method of ISO/IEC TR 15504 and ISO
9001:2000 simultaneous application on software SMEs. In: 3rd
International SPICE Conference on Process Assessment and
Improvement; 2003. p. 87e92.
Barafort B, Humbet J-P, Poggi S. Information security
management and ISO/IEC 15504: the link opportunity between
security and quality. In: International SPICE Conference on
Process Assessment and Improvement; 2006.
Bernard R. Information lifecycle security risk assessment: a tool
for closing security gaps. Comput Secur 2007;26:26e30.
Boynton BC. Identification of process improvement
methodologies with application in information security. In:
Proceedings of the 4th annual conference on Information
security curriculum development InfoSecCD; 2007.
Da Veiga A, Eloff JHP. A framework and assessment instrument
for information security culture. Comput Secur
2010;29:196e207.
Garz�as J, Pino FJ, Piattini M, Fern�andez CM. A maturity model for
the Spanish software industry based on ISO standards.
Comput Stand Interfaces November 2013;35(6):616e28.
Gerber M, von Solms R. Information security requirements e
interpreting the legal aspects. Comput Secur 2008;27:124e35.
Gregor S, Hevner AR. Positioning and presenting design science
research for maximum impact. MIS Q 2013;37(2):341e55.
Hevner AR, March ST, Park J, Ram S. Design science in
information systems research. MIS Q 2004;28(1):75e105.
ISACA. COBIT 5. Information Systems Audit and Control
Association; 2012.
ISO/IEC. ISO/IEC 12207:1995/Amd1:2002/Amd2:2004 information
technology e software life cycle processes. 2004.
ISO/IEC. ISO/IEC 15504-1:2004 information technology e process
assessment e part 1: concepts and vocabulary. 2004.
ISO/IEC. ISO/IEC 15504-2:2003/Cor1:2004 software engineering e
process assessment e part 2: performing an assessment. 2004.
ISO/IEC. ISO/IEC 15504-5:2006 information technology e software
process assessment e part 5: an exemplar process assessment
model. 2006.
ISO/IEC. ISO/IEC TS 15504-10:2011 information technology e
process assessment e part 10: safety extension. 2011.
ISO/IEC. ISO/IEC 27001:2013 information technology e security
techniques e information security management systems e
requirements. 2013.
ISO/IEC. ISO/IEC 27002:2013 information technology e security
techniques e code of practice for information security
controls. 2013.
ITmark. ITmark certification scheme for IT SMEs. http://it-
mark.eu.2013.
J€arvinen P. On research methods. Tampere: Juvenes Print; 2001.
Karabacak B, Sogukpinar I. A quantitative method for ISO 17799
gap analysis. Comput Secur 2006;25:413e9.
Knapp KJ, Morris RF, Marshall TE, Byrd TA. Information security
policy: an organizational-level process model. Comput Secur
2009;28:493e508.
Lai Y-P, Dai R-H. The implementation guidance for practicing
network isolation by referring to ISO-17799 standard. Comput
Stand Interfaces 2009;31:748e56.
Lepmets M, McBride T, Ras E. Goal alignment in process
improvement. J Syst Softw 2012;85:1440e52.
March ST, Smith GF. Design and natural science research on
information technology. Decis Support Syst 1995;15:251e66.
Mas A, Amengual E. La mejora de los procesos de software en las
peque~nas y medianas empresas (pyme). Un nuevo modelo y
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref1
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref1
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref1
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref1
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref2
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref2
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref2
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref2
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref2
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref3
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref3
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref3
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref3
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref4
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref4
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref4
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref5
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref5
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref5
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref5
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref6
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref6
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref6
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref6
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref7
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref7
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref7
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref7
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref7
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref7
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref8
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref8
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref8
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref9
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref9
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref9
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref10
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref10
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref10
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref11
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref11
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref12
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref12
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref12
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref13
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref13
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref13
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref13
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref14
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref14
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref14
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref15
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref15
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref15
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref15
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref15
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref16
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref16
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref16
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref17
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref17
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref17
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref17
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref17
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref18
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref18
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref18
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref18
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref18
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref44
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref44
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref19
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref19
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref19
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref20
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref20
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref20
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref20
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref21
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref21
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref21
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref21
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref22
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref22
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref22
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref23
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref23
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref23
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref24
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref24
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref24
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
c om p u t e r s & s e c u r i t y 4 8 ( 2 0 1 5 ) 1 9e3 434
su aplicaci�on en un caso real. Rev Esp Innov Calid Ing Software
(REICIS) December 2005;1(2):7e29.
Mas A, Amengual E. Amethod for the implementation of a quality
management system in software SMEs. In: 12th International
Conference on Software Quality Management. British
Computer Society; March 2004. p. 61e74.
Mas A, Amengual E, Mesquida AL. Application of ISO/IEC 15504 in
very small enterprises. Syst Softw Serv Process Improv
Commun Comput Inf Sci 2010;99:290e301.
Mas A, Flux�a B, Amengual E. Lessons learned from an ISO/IEC
15504 SPI programme in a company. J Softw Evol Process
2012;24(5):493e500.
Mellado D, Blanco C, S�anchez LE, Fern�andez-Medina E. A
systematic review of security requirements engineering.
Comput Stand Interfaces 2010a;32:153e65.
Mellado D, Fern�andez-Medina E, Piattini M. Security
requirements engineering framework for software product
lines. Inf Softw Technol 2010b;52:1094e117.
Mellado D, Fern�andez-Medina E, Piattini M. Towards security
requirements management for software product lines: a
security domain requirements engineering process. Comput
Stand Interfaces 2008;30:361e71.
Mesquida AL, Mas A, Amengual E, Calvo-Manzano JA. IT service
management process improvement based on ISO/IEC 15504: a
systematic review. Inf Softw Technol 2012;54(3):239e47.
Mesquida AL, Mas A, Amengual E. La madurez de los servicios TI.
Rev Esp Innov Calid Ing del Softw (REICIS) September
2009;5(2):77e87.
Oktaba H, Garcı́a F, Piattini M, Ruiz F, Pino FJ, Alquicira C.
Software process improvement: the competisoft project.
Computer Oct. 2007;40(10):21e8.
Pardo C, Pino FJ, Garcı́a F, Piattini M, Baldassarre MT. An ontology
for the harmonization of multiple standards and models.
Comput Stand Interfaces 2012;34:48e59.
SEI. CMMI® for development, CMMI-DEV version 1.3. Software
Engineering Institute; November 2010.
Tudor. ITSM process assessment supporting ITIL, public research
centre Henri Tudor. In: Barafort B, Betry V, Cortina S, Picard M,
St-Jean M, Renault A, et al., editors. Zaltbommel: Van Haren
Publishing; December 2009.
Valdevit T, Mayer N, Barafort B. Tailoring 27001 for SMEs: a guide
to implement an information security management system in
small settings. Softw Process Improv Commun Comput Inf Sci
2009;42:201e12.
Venable J, Pries-Heje J, Baskerville R. A comprehensive framework
for evaluation in design science research. Des Sci Res Inf Syst
Adv Theory Pract Lect Notes Comput Sci 2012;7286:423e38.
von Solms B, von Solms R. Incremental information security
certification. Comput Secur 2001;20:308e10.
Xiao-yan G, Yu-qing Y, Li-lei L. An information security maturity
evaluation mode. Procedia Eng 2011;24:335e9.
Zuccatoy A. Holistic security management framework applied in
electronic commerce. Comput Secur 2007;26:256e65.
Zvanut B, Bajec M. A tool for IT process construction. Inf Softw
Technol 2010;52:397e410.
Antoni Lluı́s Mesquida is an assistant lecturer of software engi-
neering and project management at the University of the Balearic
Islands. His research interests include software process improve-
ment, project management and service management. He has
participated in the QuaSAR project, a software process improve-
ment programme in small software companies in the Balearic
Islands. He received his PhD in Computer Science from the Uni-
versity of the Balearic Islands. He has served as program com-
mitteemember and industry chair of scientific conferences related
to software quality.
Antonia Mas is a university lecturer of software engineering and
project management at the University of the Balearic Islands. Her
research interests include software process improvement, project
management and service management. She has promoted and
coordinated the QuaSAR Project, a software process improvement
initiative in small software companies in the Balearic Islands. She
received her degree in Computer Science from UAB (Catalonia,
Spain) and her PhD in Computer Science from the University of
the Balearic Islands. She has served as program committee
member of scientific conferences and workshops related to soft-
ware quality. She is an ISO/IEC 15504 assessor.
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref24
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref24
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref24
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref24
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref25
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref25
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref25
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref25
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref25
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref26
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref26
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref26
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref26
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref27
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref27
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref27
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref27
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref27
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref28
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref28
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref28
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref28
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref28
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref28
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref29
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref29
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref29
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref29
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref29
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref30
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref30
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref30
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref30
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref30
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref30
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref31
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref31
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref31
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref31
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref32
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref32
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref32
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref32
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref33
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref33
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref33
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref33
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref34
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref34
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref34
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref34
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref35
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref35
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref35
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref36
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref36
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref36
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref36
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref37
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref37
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref37
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref37
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref37
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref38
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref38
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref38
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref38
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref39
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref39
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref39
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref40
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref40
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref40
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref41
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref41
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref41
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref42
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref42
http://refhub.elsevier.com/S0167-4048(14)00134-5/sref42
http://dx.doi.org/10.1016/j.cose.2014.09.003
http://dx.doi.org/10.1016/j.cose.2014.09.003
- Implementing information security best practices on software lifecycle processes: The ISO/IEC 15504 Security Extension
1. Introduction
2. Research method and approach
3. Development of the ISO/IEC 15504 Security Extension
3.1. Standards used
3.1.1. ISO/IEC 27000 series
3.1.2. ISO/IEC 15504
3.2. Analysis of the relations between ISO/IEC 27002 and ISO/IEC 15504-5
3.2.1. Types of correspondence between ISO/IEC 27002 and ISO/IEC 15504-5
3.2.2. Summary of the relations between ISO/IEC 27002 and ISO/IEC 15504-5
4. The ISO/IEC 15504 Security Extension
4.1. Application of the ISO/IEC 15504 Security Extension
5. Validation of the ISO/IEC 15504 Security Extension
5.1. Case study: validation of the ISO/IEC 15504 Security Extension in a company
5.2. Lessons learned from the validation of the ISO/IEC 15504 Security Extension
6. Conclusion and further work
Acknowledgements
Appendix 1. Mapping between the ISO/IEC 27002 security controls and ISO/IEC 15504-5 base practices
References
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
