Content uploaded by Jesus Andres Hincapie Londoño
Author content
All content in this area was uploaded by Jesus Andres Hincapie Londoño on Jan 27, 2021
Content may be subject to copyright.
Multi-model environment generation and tailoring model
for software process improvement
Gloria Piedad Gasca-Hurtado1, Jesús Andrés Hincapié Londoño1 and Mirna Muñoz2
1 Universidad de Medellín, Medellín, Carrera 87 N° 30 - 65, Colombia
2 CIMAT – Unidad Zacatecas, Zacatecas, Av. Universidad No. 222, 98068, México
{gpgasca, jehincapie}@udem.edu.co, mirna.munoz@cimat.mx
Abstract. Software development organizations take great risks when are faced
with process improvement projects and the inclusion of best practices. Such risks
include the selection of a standard, framework or model for the improvement
process. Some organizations decide to integrate best practices from different
sources to be non-dependent on a particular model, framework or standard. How-
ever, the integration of different models is an additional challenge since the com-
plexity of the implementation increases as best practices come from different na-
tures. Hence, we propose a model to generate and customize a multi-model envi-
ronment for software process improvement. We intend to reduce the complexity
of combining agile and traditional frameworks by generating a frameworks inte-
gration catalog, which, from heuristics, graphically represents the possible paths
to follow for the process improvement project. We use design-based science for
this research because of its focus on problem analysis in real-world environ-
ments. In this way, we can consolidate the model to customize and generate a
multi-model environment for the implementation of best practices of different
nature during an improvement process. We also define a proposal of organiza-
tional profiles, which will allow us to validate the model in a business case in
future work.
Keywords: Software Process Improvement, Multi-model environment, Soft-
ware Engineering.
1 Introduction
The implementation of process improvement proposals and best practices in soft-
ware development companies has a high and variable complexity that depends on the
type of standard, framework or model used. The integration of best practices from dif-
ferent sources is used to achieve concrete improvement that is independent of the
model, framework or standard. However, the complexity of the implementation in-
creases when the sources of such best practices have a different nature [1].
Therefore, we intend to define a methodology to generate multi-model catalogs of
best practices for the improvement of software processes that include agile and tradi-
tional practices. This proposal seeks to reduce the complexity of combining agile and
traditional frameworks in a multi-model environment [2–4], through the design of a
2
frameworks integration catalog, including a strategy for the design of the graphic rep-
resentation of the catalog with the use of heuristics.
We select Design-Based Science as the research methodology for this work, because
of its approach to the analysis of unsolved problems in a real-world environment. By
implementing the selected methodology, it is possible to consolidate all the components
that make up the model to generate and tailor a multi-model catalog for software pro-
cess improvement. Such components include the proposal of organizational profiles
that facilitate the multi-model environment personalization.
In the Configuration Engine Component, we present the structural model of the soft-
ware tool to graphically represent the environment. Such a tool is under development
and it will allow the use of technology to validate the model in a later stage. The rest of
the model components are described in this work.
This paper is structured as follows: part 2 presents a background of the topics related
to this work. Part 3 shows how the research methodology is applied to this work. Part
4 explains the model for defining a multi-model catalog and its four components. Fi-
nally, part 5 presents conclusions and future work.
2 Background
2.1 Software Process Improvement
The main goals of software process improvement (SPI) are to develop better-quality
software, increase customer satisfaction, and to increase returns on investment. SPI is
a strong approach used by software organizations to improve their competitive market
position [5]. SPI was developed to manage and improve the quality of software devel-
opment [6]. Through SPI it is possible to resolve issues related to ad-hoc software pro-
cesses because SPI aims to obtain optimal solutions considering the planning, develop-
ment, and production cycles, as well as to resolve organizational issues.
SPI can provide benefits for software development organizations. SPI is adequate
when organizations need to improve product quality, shorten the time-to-market, in-
crease productivity, reduce costs, and more. To realize these benefits, the effective im-
plementation of SPI requires time, careful scheduling, resources and knowledge man-
agement [5, 7, 8].
In conclusion, SPI is the sequence of activities that involves checking the current
development process, then planning to change it until achieving a specific goal, some-
times repeatedly and constantly [9]. This sequence is related to an awareness of self-
reflection and pursues a better process and result. Specifically, in the field of software
engineering, the SPI is an important area, taking into account that the software process
refers to a collection of activities, actions, and tasks performed while the product is
being built [10].
2.2 Agile and Traditional Methodologies
Agile Software development is just one of the methodologies used in software devel-
opment. Agile is a word used to describe a process model concept that is different from
3
the existing process model concepts [11]. Agile software development concepts were
coined by Kent Beck and her team by stating that Agile Software Development is a way
to build software by doing it and helping others to build it [12]. However, just like other
process models, Agile Software Development has its advantages and is not suitable for
all types of projects, products, people and situations. Agile Software Development en-
ables a process model that is tolerant of changes in the requirements so the response to
the changes can be done faster [13].
For its part, the traditional software development process is considered as a set of
activities, methods, practices, and transformations that people employ to develop and
maintain software and associated products (for example, project plans, project docu-
ments, design, code, test cases, user manual).
Authors like Pressman [9] consider the software process as the set of partially or-
dered activities that a project must follow to perform some task. This task should aim
to achieve a goal and is associated with the development of one or more products [14].
In general, when referring to traditional methodologies, it is essential to relate to the
System Development Life Cycle (SDLC). A definition associated with SDLC is one
that considers a whole process in building a system through several steps [15]. There
are several models of the SDLC, the model which is quite popular and widely used is
the waterfall. Some other models of SDLC, for example, are fountain, spiral, rapid,
prototyping, incremental, build and fix, and synchronize and stabilize. With the SDLC
cycle, the process of building the system is divided into several steps and on large sys-
tems, each step is done by different teams [16].
3 Design Science in Information System Research
Information Systems (IS) Research lies at the intersection of people, organizations, and
technology [17]. It relies on and contributes to cognitive science, organizational theory,
management sciences, and computer science. It is both an organizational and a technical
discipline that is concerned with the analysis, construction, deployment, use, evalua-
tion, evolution, and management of information system artifacts in organizational set-
tings [18, 19].
Within this setting, the design science research paradigm is proactive concerning
technology. It focuses on creating and evaluating innovative IT artifacts that enable
organizations to address important information-related tasks.
Nowadays, IS research must address the interplay among business strategy, IT strat-
egy, organizational infrastructure, and IS infrastructure. This interplay is typical in this
research project; thus, we select the Framework for IS Research as Figure 1 shows.
4 Model to Generate a Multi-Model Catalog
Considering the difficulties that organizations experience when trying to harmonize
different frameworks, models, and standards of SPI best practices, we propose a model
to create multi-model environments, generating a catalog of best practices.
This proposal intends to address the following difficulties:
4
Fig. 1. Framework for IS Research
the need to classify good practices and their associated activities [2];
the lack of criteria for the selection of tasks that generate value to the project and the
exclusion of those that do not generate value [3]; and
the need to divide activities and correlate them between different models or frame-
works that constitute a multi-model environment [4].
These difficulties mean that the implementation of a multi-model environment has a
complexity inherent in integrating best practices from different sources such as CMMI-
DEV, ISO 29110 and other standards; or of different natures such as SCRUM.
In this sense, the problem lies in the complexity of selecting and relating key ele-
ments of each of these sources, to generate a best practice model adapted to the needs
of the company. This makes organizations give up in their attempt to solve the problem
of implementing frameworks, standards or process improvement models under a multi-
model approach, which results in increased costs, low quality of the products devel-
oped, teams’ demotivation and processes inefficiency in general.
Studies have been developed where integration between agile and traditional frame-
works [20, 21] and some applications to the industry [4, 22] are proposed. Abstract
solutions models have also been found to achieve integration [2, 3, 23] and sets of best
practices from the union of both agile and traditional frameworks [24–26]. However,
these proposals focus on specific models and do not consider a generic strategy to inte-
grate any model. Furthermore, they do not include a tool to support the multi-model
environment definition.
A proposal that includes the integration between frameworks is the multi-model en-
vironment, an approach that allows harmonizing process improvement models [1].
However, the definition of a multi-model environment requires a detailed analysis
of the best practices of each model, which leads practitioners to face the complexity of
harmonizing them. This analysis allows identifying similarities and eliminating redun-
dancies to achieve greater benefits of harmonization [1].
Therefore, this paper presents a model for the construction of a catalog of best prac-
tices from a multi-model environment. This model is designed from components shown
5
in Figure 2. Next, each of these components is described.
Fig. 2. Model to build Multi-model Catalog Components
4.1 SPI Model Structure Component
This component represents the conceptual model of the issues related to our problem.
It describes the different entities, their attributes, roles, and relationships, as well as the
restrictions that govern the problem domain. The domain model for the SPI Model
Structure Component is the one shown in Figure 3, which is required for the automatic
generation of the multi-model environment.
Fig. 3. Domain model of the multi-model environment software tool
4.2 Notation and Heuristics Component
6
Set of heuristics conceived from four dimensions that allow defining the catalog of best
practices. To represent these heuristics, it was necessary to define a proper notation.
This notation is equivalent to a system of conventional signs that is adopted to express
the use of the dimensions established in the set of heuristics.
The set of heuristics were organized in a process representation structure in terms of
four dimensions. This structure is described in the Multi-model Catalog for Software
Projects Management including Agile and Traditional Practices [27]. Next, each of the
dimensions of the catalog is summarized.
Dimension 1 – Activity type.
This dimension allows cataloging activities in structural and behavioral and is de-
fined in terms of the following rules:
1. Define the level of detail for the comparison of practices between frameworks.
2. An activity is structural when it generates an artifact after its execution.
3. An activity is behavioral when it indicates recommendations to solve a specific sit-
uation but does not imply the generation of an artifact.
Dimension 2 – Activity flexibility.
It allows determining if an activity is optional, required or flexible. For its imple-
mentation, the following heuristics are defined:
1. An activity is optional when, in the opinion of an expert, according to the experience
in developed projects or using a metric of the size of the project, it does not generate
value for its development.
2. An activity is required when, according to an expert, to the experience in projects
developed or using a metric of the size of the project, it is key to the project success.
3. An activity is flexible when, according to an expert, to the experience in projects
developed or using a metric of the size of the project, it can be adapted to the needs
or conditions of the project without affecting its success.
Dimension 3 – Redundant activities.
It allows identifying activities focused on the same objective.
1. An activity is redundant when you can clearly identify other activities that are geared
towards achieving the same objective among the different frameworks being studied.
2. An activity is not redundant when no similarities are identified with other activities
among frameworks, nor are similar objectives that direct such activity identified.
Dimension 4 – Complementary activities
An activity is complementary when a dependency between the different activities of
the same framework is identified.
4.3 Configuration Engine Component
In this component, the configurations of multi-model environments are automatically
7
generated. This component is associated with the implementation of the heuristics de-
fined from the dimensions described in the Notation and Heuristic Component. For its
implementation, it is necessary to develop a regulated technological tool so that the
different configurations are automatically generated. An example of the implementa-
tion of heuristics is presented in [28].
4.4 Tailoring Profile Component
It facilitates the customization of automatically generated configurations, based on an
organizational diagnosis. This diagnosis is defined under the analysis of the maturity of
the organization and its ability to start a software process improvement initiative.
According to Petersen and Wohlin [29], the software development process should
be in harmony with the actual environment in which the software is developed and
delivered. This means that to have success in the establishment of a multimodel envi-
ronment, it is necessary to achieve the characterization of the organizational context as
complete and accurate as possible.
To achieve the characterization of the actual organizational environment, this pro-
posal selected a set of conceptual aspects proposed by Petersen and Wholin and by
Clark and O’Connor [30]. The set of the conceptual aspects are listed below:
1. Product: the actual type of products that the organization develops. Besides, the time
in which the organization delivers its products. The aspects covered in this element
are the type of systems and project time.
2. Process: identification of the actual practices that the organization performs. The
aspects covered in this element are tasks, work products and the methodology used
to develop the software.
3. Human resources: experience and training of the actual organization’s employees.
The aspects covered in this element are experience, roles, and staff turnover.
4. Organization: the actual structure of the organization. This element covers the cer-
tification obtained, the organization distribution, and the number of employees.
5. Knowledge: communication channels of the organization and how the knowledge is
shared and disseminated. The aspects covered in this element are the way to dis-
seminate organizational assets, the communication channels established within a
project and the way to share project assets.
Having characterized the organizational environment, it will be possible to establish
a multi-model environment tailored to the organizational culture and to provide the best
practices that could be implemented in an easy way within the organization.
4.5 Implementation Method Component
Next, each of the phases of the method that were listed in Figure 2 is detailed.
Phase 1. Parametrization.
The objective of this phase is to declare the values that characterize the models. In
this phase, the basic parameters of interaction with the different models are defined
8
based on the structure and its rules. Activities defined for this phase are as follows:
1. Provide information for the structure of the models.
2. Select software process improvement (SPI) models: the organization must define a
reference model that will facilitate the comparison of best practices. This reference
model will be the guide on which the application of the different heuristics is based.
3. Select the improvement process to be structured: this activity is related to the defi-
nition of the organization's improvement interest. It is the starting point for the exe-
cution of the process improvement initiative.
Phase 2. Design
The objective of this phase is to obtain the graphic representation of the different
alternatives that an organization can achieve to guide its improvement initiative. It has
a direct dependence on the parameterization values established in the parameterization
phase. The activities associated with this phase are:
1. Apply each of the heuristics defined in the Notation and Heuristic Component.
2. Identify the best practices that comprise the process selected in the parameterization
phase according to the defined notation.
3. Generate the graphical representation of the multi-model environment using the
graphical representation tool.
Phase 3. Configuration
The objective of this phase is to automatically generate all possible configurations
of the multi-model environment. Each configuration is defined based on a possible path
to follow, resulting from the application of the different heuristics described in the No-
tation and Heuristic Component, in order to implement a process improvement initia-
tive in an organization independent of a model, standard or framework.
Phase 4. Tailoring
The objective of this phase is to adapt the generated multi-model environment to the
organization profile. This profile is defined from a diagnosis where the organization’s
maturity and its ability to initiate an SPI initiative are analyzed. The interests of the
organization are considered, even from the parameterization phase, when the reference
model and the process are selected. However, it is at this stage that the customization
process is completed with activities such as:
1. Perform company diagnosis: select questions associated with the organization and
answer a survey. The results of this survey are analyzed to define the profile of the
organization according to the Tailoring Profile Component.
2. Generate recommendations according to the organization’s diagnosis and deliver the
multi-model environment and custom configurations.
5 Conclusions
In this research, we proposed a model to create multi-model environments to cope with
the difficulties of harmonizing different frameworks, models and standards of SPI. This
9
model comprises four components: SPI Model Structure, Notation and Heuristics, Con-
figuration Engine, Tailoring Profile, and Implementation Method.
The main contribution of this paper is the model structure to generate a multi-model
catalog, especially the SPI model Structure, Tailoring profiles, and Implementation
Method components since the other two were already designed in previous works.
These components and the model in21 general still lack proper validation, which will
be carried out as future work once the software tool is completely developed and we
can put the model to the test in a case study in a software development organization.
References
1. Marino L, Morley J (2009) Process improvement in a multi-model environment builds
resilient organizations. NEWS SEI, Softw. Eng. Inst.
2. Salinas CJT, Escalona MJ, Mejías M (2012) A scrum-based approach to CMMI maturity
level 2 in web development environments. In: Proceedings of the 14th International
Conference on Information Integration and Web-based Applications & Services - IIWAS
’12. ACM Press, New York, New York, USA, p 282
3. Monteiro P, Borges P, Machado RJ, Ribeiro P (2012) A reduced set of RUP roles to small
software development teams. In: 2012 International Conference on Software and System
Process, ICSSP 2012 - Proceedings. pp 190–199
4. Tuan N, Thang H (2013) Combining maturity with agility: lessons learnt from a case study.
In: Proceedings of the Fourth Symposium on Information and Communication Technology.
pp 267–274
5. Niazi M, Babar MA, Verner JM (2010) Software Process Improvement barriers: A cross-
cultural comparison. Inf Softw Technol 52:1204–1216.
6. Samalikova J, Kusters RJ, Trienekens JJM, Weijters AJMM (2014) Process mining support
for Capability Maturity Model Integration-based software process assessment, in principle
and in practice. J Softw Evol Process 26:714–728. https://doi.org/10.1002/smr.1645
7. Lars M (2003) Managing knowledge in a software organization. J Knowl Manag 7:63–80.
https://doi.org/10.1108/13673270310477298
8. Meehan B, Richardson I (2002) Identification of Software Process Knowledge Management.
Softw Process Improv Pract 7:47–55. https://doi.org/10.1002/spip.154
9. Pressman RS Software engineering : a practitioner’s approach
10. Conradi H, Fuggetta A (2002) Improving software process improvement. IEEE Softw 19:92–
99. https://doi.org/10.1109/MS.2002.1020295
11. Martin RC (2003) Agile Software Development: Principles, Patterns, and Practices. Prentice
Hall PTR, Upper Saddle River, NJ, USA
12. Dingsøyr T, Dyb T, Moe NB (2014) Agile Software Development Current Research and
Future Directions. Springer Berlin
13. Dhir S, Kumar D, Singh VB (2019) Success and Failure Factors that Impact on Project
Implementation Using Agile Software Development Methodology. Springer, Singapore, pp
647–654
14. Adi P (2015) Scrum Method Implementation in a Software Development Project
Management. Int J Adv Comput Sci Appl 6:. https://doi.org/10.14569/IJACSA.2015.060927
10
15. Langer AM (2012) Guide to software development : designing and managing the life cycle.
Springer
16. Gonçalves EF, Drumond GM, Méxas MP (2017) Evaluation of PMBOK and scrum practices
for software development in the vision of specialists. Indep J Manag Prod 8:569–582.
https://doi.org/10.14807/ijmp.v8i5.598
17. Silver MS, Markus ML, Beath CM (1995) The Information Technology Interaction Model:
A Foundation for the MBA Core Course. MIS Q 19:361. https://doi.org/10.2307/249600
18. Madnick SE (1993) The challenge--to be part of the solution instead of being the problem
19. Orlikowski WJ, Barley SR (2001) Technology and Institutions: What Can Research on
Information Technology and Research on Organizations Learn from Each Other? MIS Q
25:145. https://doi.org/10.2307/3250927
20. Špundak M (2014) Mixed Agile/Traditional Project Management Methodology – Reality or
Illusion? Procedia - Soc Behav Sci 119:939–948.
https://doi.org/10.1016/J.SBSPRO.2014.03.105
21. Hornstein HA (2015) The integration of project management and organizational change
management is now a necessity. Int J Proj Manag 33:291–298.
https://doi.org/10.1016/J.IJPROMAN.2014.08.005
22. Pinheiro PR, Machado TCS, Tamanini I (2013) Dealing the Selection of Project Management
through Hybrid Model of Verbal Decision Analysis. Procedia Comput Sci 17:332–339.
https://doi.org/10.1016/j.procs.2013.05.043
23. Buglione L, Luigi (2011) Light maturity models (LMM). In: Proceedings of the 12th
International Conference on Product Focused Software Development and Process
Improvement - Profes ’11. ACM Press, New York, New York, USA, p 57
24. Brown AW, Ambler S, Royce W (2013) Agility at scale: Economic governance, measured
improvement, and disciplined delivery. In: 2013 35th International Conference on Software
Engineering (ICSE). IEEE, pp 873–881
25. Ng P-W, Pan-Wei (2014) Theory based software engineering with the SEMAT kernel:
preliminary investigation and experiences. In: Proceedings of the 3rd SEMAT Workshop on
General Theories of Software Engineering - GTSE 2014. ACM Press, New York, New York,
USA, pp 13–20
26. Van Hilst M, Fernandez EB (2010) A pattern system of underlying theories for process
improvement. In: Proceedings of the 17th Conference on Pattern Languages of Programs -
PLOP ’10. ACM Press, New York, New York, USA, pp 1–24
27. Bustamante AF, Hincapié JA, Gasca-Hurtado GP (2016) Structure of a Multi-model Catalog
for Software Projects Management Including Agile and Traditional Practices. Springer,
Cham, pp 87–97
28. Hincapie JA, Gasca-Hurtado GP, Bustamante AF (2016) Multimodel catalogue heuristics for
software project managemet. In: 2016 11th Iberian Conference on Information Systems and
Technologies (CISTI). pp 1–6
29. Petersen K, Wohlin C (2009) Context in industrial software engineering research. In: 2009
3rd International Symposium on Empirical Software Engineering and Measurement. IEEE,
pp 401–404
30. Clarke P, O’Connor R V. (2012) The situational factors that affect the software development
process: Towards a comprehensive reference framework. Inf Softw Technol 54:433–447.
https://doi.org/10.1016/J.INFSOF.2011.12.003
