Memorias 2015 - LASES - Latin American Software Engineering

Transcripción

Proceedings of the Latin American Software Engineering Symposium, Año 2015
1
Proceedings of the Latin American Software Engineering Symposium - LASES
Bogotá DC - 2015
Copyright © 2015 Cidenet Sello Editorial
Except where otherwise noted, content in this publication is licensed under the Creative
Commons Attribution, NonCommercial, ShareAlike 3.0 Unported License, available at
http://creativecommons.org/licenses/by-sa/3.0 As for readers, this license allows users to
download, copy and build upon published chapters even for commercial purposes, as long
as the author and publisher are properly credited, which ensures maximum dissemination
and a wider impact of our publications.
Notice
Statements and opinions expressed in the papers are these of the individual contributors
and not necessarily those of the editors or publisher. No responsibility is accepted for the
accuracy of information contained in the published papers. The publisher assumes no
responsibility for any damage or injury to persons or property arising out of the use of any
materials, instructions, methods or ideas contained in the book.
A free online edition of this book is available at www.lases.cidenet.org
Edition, November 2015
ISSN 2500-5014
Latin American Software Engineering Symposium
lases.cidenet.org
[email protected]
Bogotá DC – Colombia
2
Scientific Committee
Organizing Committee
Shihong Huang, Ph.D.
Florida Atlantic University
Administrative and Financial Director
Wiliam Arévalo Camacho, M.Sc.
Corporación Centro de Investigación y
Desarrollo de Nuevas Tecnologías CIDENET.
Hanna Oktaba, Ph.D.
María Guadalupe Ibargüengoita, M.Sc.
Universidad Nacional Autónoma de México
Scientific Director
Carlos Mario Zapata Jaramillo, Ph.D.
Universidad Nacional de Colombia.
José Antonio Pow Sang Portillo, Ph.D.
Universidad Caólica del Perú
Jonás Montilva, Ph.D.
Universidad de los Andes Venezuela
Logistic Director
Gastón Mejía, Msc.
Universidad Central
Edison Spina, Ph.D.
Universidade de São Paulo
Edited by
Carlos Mario Zapata Jaramillo, Ph.D.
Universidad Nacional de Colombia.
Jovani Alberto Jimenez Builes, Ph.D.
Jairo Hernan Aponte Melo, Ph.D.
Universidad Nacional de Colombia
Design and Layout
Wiliam Arévalo Camacho, M.Sc.
Corporación Centro de Investigación y
Desarrollo de Nuevas Tecnologías CIDENET.
Francisco Gómez, PHD.
Amparo Olaya, Msc.
Gastón Mejía, Msc.
Universidad Central
3
Indice
Página
1
2
Título
Prefacio
Parte I: Métodos y prácticas
KUALI-BEH: Software project common concepts for authoring Software Engineering
practices
3
Analyzing the conceptual correspondence between Blue WATCH´s basics and SEMAT´s
essentials
Parte II: El núcleo de SEMAT y la calidad de software
9
16
Identificación de criterios para relacionar la Usabilidad con el alfa Sistema de Software
del núcleo de Semat.
La gestión de las pruebas de software representadas con SEMAT
Métricas de la norma ISO 9126: una representación basada en el núcleo de SEMAT
17
23
28
Representación en el núcleo de Semat de la Interoperabilidad para el Método de
Desarrollo de Software del IGAC
Parte III: Aspectos humanos en el núcleo de SEMAT
34
40
Representación en el núcleo de Semat de las competencias de Ingeniería Social
necesarias para mejorar la Seguridad Informática
41
Una extensión del núcleo de SEMAT para la representación de prácticas de enseñanza
de sistemas embebidos
47
Retos en la enseñanza del Núcleo SEMAT a estudiantes de ciclos propedéuticos de
Ingeniería de Sistemas en Colombia
Ethics: extending human aspects in Way-of-Working
Parte IV: Agilismo
53
59
64
Guía para la Integración de Métodos Formales de Ingeniería de Requerimientos en
Procesos de Desarrollo Ágil
Metodologías ágiles como estrategias de enseñanza de desarrollo de software
Incorporando SEMAT en un una metodología Ágil, para equipos distribuidos.
65
72
78
4
Prefacio
C.M. Zapata
Universidad Nacional de Colombia
W.A. Arévalo
Corporación CIDENET
Nuestro Simposio Latinoamericano de Ingeniería
de Software (LASES, por sus siglas en inglés)
alcanza en este 2015 su cuarto año de realización.
Durante varias ediciones, SEMAT se consolidó
como el hilo conductor de nuestro simposio, dado
que el núcleo de la Esencia, el nuevo estándar del
OMG, posibilita la expresión de cualquier tema de
ingeniería de software. En esta edición SEMAT y el
agilismo son los dos temas centrales y nos
permitirán develar temas de mucha actualidad
relativa a la realidad de la ingeniería de software
en nuestro medio y en el mundo.
Cuatro grandes tópicos caracterizan esta nueva
edición de LASES, todos ellos igualmente
importantes e interrelacionados, si bien se
exponen en el marco de la Teoría y Métodos de la
Ingeniería de Software. En la primera parte se
compendian trabajos relacionados con métodos y
prácticas, donde se incluyen la visión de los
métodos
KUALI-BEH
y
Blue
WATCH,
correspondientes a dos prestigiosos grupos de
investigación latinoamericanos. En la segunda
parte se abordan varios artículos que permiten
establecer la relación entre SEMAT y la calidad de
software; allí, las características de calidad, como
la usabilidad y la interoperabilidad, las métricas y
la gestión de pruebas se emplean como tema de
las representaciones en el núcleo de SEMAT. En la
tercera parte se tratan los aspectos humanos en el
núcleo de SEMAT, donde las competencias y la
enseñanza de diferentes temas complementan la
forma de trabajo en SEMAT. Finalmente, en la
cuarta parte se tratan los temas de agilismo, en
este caso dos artículos relacionados con los
procesos de desarrollo ágil y la incorporación del
agilismo en la enseñanza.
Como en las anteriores ediciones de LASES,
confiamos en que estos temas de actualidad se
combinen y magnifiquen con la presencia de
prestigiosos
representantes
de
SEMAT,
encabezados por Paul McMahon, uno de los
autores del libro de la Esencia de la Ingeniería de
Software donde se describe el núcleo de SEMAT, y
otros miembros connotados de la ingeniería de
software
que
nos
acompañarán
por
videoconferencia, como es el caso de Ken
Schwaber, padre de Scrum, Philippe Kruchten,
autor del libro inicial del Proceso Unificado
Racional y actualmente uno de los militantes del
agilismo, y Scott Ambler, uno de los signatarios del
Manifiesto Ágil. Bogotá recibe, entonces, esta
pléyade de investigadores latinoamericanos y
mundiales para hacer de esta nueva edición de
LASES 2015 una nueva oportunidad para recalcar
los fundamentos de nuestra disciplina, que a
pasos agigantados se está proyectando hacia una
real ingeniería, con los fundamentos teóricos
necesarios, pero sin descuidar la práctica
industrial que tendencias como el agilismo están
entregando a los diferentes practicantes de la
ingeniería de software. LASES es un espacio
dedicado a difundir esta realidad y a confrontar
los retos que nos entrega el futuro.
Proceedings of the Latin American Software Engineering Symposium, Año 2015, pp. 1 , ISSN 2500-5014
Métodos y prácticas
Proceedings of the Latin American Software Engineering Symposium, Año 2015, pp. 2, ISSN 2500-5014
KUALI-BEH: Software project common concepts for authoring
Software Engineering practices
M. Morales-Trujillo & H. Oktaba
KUALI-KAANS Research Group, National Autonomous University of Mexico, Mexico City, Mexico
Introduction
Overview
This paper presents a summary of a PhD thesis
named Identification and Formalization of
Software
Project
Common
Concepts
(Morales-Trujillo & Oktaba, 2015). This thesis is
the result of a research project developed as a
response to Software Engineering Method and
Theory (SEMAT) Call for Action (Jacobson et al.,
2009) and Object Management Group (OMG)
FACESEM Request for Proposals (OMG, 2011).
Both initiatives were launched in order to refound
Software Engineering, motivated in the need to
transform it and to build theories around it, to
understand it, and more importantly, generate
proven knowledge (Jacobson et al., 2012).
Motivation
Software Engineering is one of the most
knowledge intensive disciplines (Edwards, 2003;
Bjørnson & Dingsøyr, 2008). However, this field
contains proposals or theories that have no
theoretical rigorousness and have not been
adequately validated in practice. Theories are not
subject to serious academic discussion; they are
not evaluated or compared as regards traditional
criteria of theoretical quality (Johnson et al.,
2012).
Therefore, Software Engineering actual behavior is
currently controlled and guided by the practices
used in industry and technological innovations
(Wang, 2007), while its theory and foundations,
which are essential in supporting its practices, are
left aside (Johnson et al., 2012). The many
differences between individual software projects
make comparison difficult (Basili et al., 1986),
besides it is afflicted by a lack of credible
experimental evaluation and validation (Jacobson
et al., 2012).
These concerns in the discipline have motivated
the creation and putting forward of various
proposals (meta-models, frameworks, standards,
etc.) in order to concentrate and collect
knowledge and best practices.
Nevertheless, those efforts represent a top-down
approach, which means that when an organization
decides to apply any of those proposals, it results
in a new way of working, causing that the tacit
knowledge that the practitioners of the
organizations already acquired is ignored or
abandoned in favor of the new one.
At this point it is important to recognize that the
tacit knowledge constitutes a valuable asset for
the organization and it is not desirable to
disappear. Based on that, this research project
proposes a bottom-up approach that begins with
the identification of the practitioners’ tacit
Proceedings of the Latin American Software Engineering Symposium, Año 2015, pp. 3 – 8, ISSN 2500-5014
knowledge, mainly reflected in their actual ways
of working, with the purpose to transform it into
explicit knowledge.
Once the knowledge became explicit, more
complex processes can be applied on it, allowing
practitioners to share, compare and improve their
ways of working with the intention to consolidate
a set of practices applicable to their organization
based on their own knowledge.
Generalities
Hypothesis and research objective
The research hypothesis of this PhD thesis is: It is
possible to support and improve the
representation, adaptation, sharing, comparison
and execution of the practitioners’ ways of
working through a kernel of common concepts.
The objective of the research is therefore: To
define a kernel of common concepts/framework
that supports the expression of practitioners’ ways
of working carried out during software projects.
Proposed solution
This PhD thesis proposes KUALI-BEH: A bottom-up
framework for software engineering practitioners
working in small organizations.
With KUALI-BEH they can formulate, progress,
adapt and improve their ways of working in the
form of practices and methods.
Methodology
The research followed the phases of Identification,
Validation and Formalization. The identification
phase consisted in defining each of the common
concepts to be part of the kernel.
The validation process consisted of a collaborative
workshop, three case studies and a full
standardization cycle in the OMG context.
Finally, the formalization resided in the
transformation of the kernel into a set of axioms,
rules and notation.
Along the three phases the partial results were
presented at conferences and other forums in
order to obtain feedback.
KUALI-BEH Research Project
According to (Harrison et al., 1999) Software
Engineering needs strong foundations as a
scientific and engineering discipline; theoretical
and empirical research to support its foundations;
sufficiently mature validation to support its
advances (Belady & Lehman, 1976); and always
involve scaling up to practice (Wieringa, 2014).
Taking into account these premises and what is
beneficial for our research, we turned to the
methods of Technical-Action-Research (TAR)
(Wieringa & Morali, 2012) and Case Studies (CS)
(Runeson et al., 2012).
Applied research strategy
TAR is based on engineering cycles, which allowed
us to valuable feedback on KUALI-BEH, and
release improved versions for next cycles. Case
studies are used to validate a theory or method by
means of empirical tests, which means that
KUALI-BEH was introduced in the real context and
interacted with software engineers.
Our research strategy was an integration of TAR
and CS methods. TAR method was applied as a
framework in which the evaluation during
engineering cycles was carried out by applying the
CS method and is described in more detail in the
next subsections. The full description of the
method can be accessed at (Morales-Trujillo et al.,
2015a).
Identification
The goal was to identify a set of common
concepts that are involved in software projects,
and to organize them in order to express and
structure Software Engineering methods. This first
step is presented graphically in Figure 1.
The workshop provided feedback on several
aspects of KUALI-BEH: some definitions were
enhanced, additional operations were included
and rules of the framework were improved.
Family of case studies
Figure 1. Steps developed during the first step of
the research.
The state-of-the-art review, identification,
definition and modeling of common concepts
were developed under an iterative approach
together with a theoretical verification of the
results. Figure 2 shows the 20 common concepts
defined in KUALI-BEH.
The next step of validation included three case
studies developed in three different organizations.
We guided the research by the question: Is
KUALI-BEH suitable as regards defining
practitioners’ ways of working during software
projects?
And the following objectives were identified as
appropriate:
1.
2.
3.
To demonstrate the sufficiency of the KUALI-BEH
elements in describing practitioners’ ways of
working.
To measure the feasibility of using the concept of
Practice to express practitioners’ tacit practices.
To identify the value obtained by the organization
as a consequence of defining its own method
composed of its own practices.
CASE STUDY 1 took place at InfoBLOCK, a Mexican
organization dealing with hardware construction
and software development. 2 general managers
and 2 programmers were involved and the
following objectives were pursued by the
organization:
 To define the actual software development
process of the organization.
 To be aware of what is being done by the work
team at a particular moment during the
development process.
Figure 2. Mind map of the identified software
project common concepts.
Collaborative workshop
The result of the Identification Phase was the
artifact KUALI-BEH 1.0, which was subjected to
discussion during a collaborative workshop. The
workshop was attended by active practitioners
from industry and academy and consisted of 8
on-site and online sessions, during which the
participants were involved in Q&A runs, activities,
surveys and homework.
After its first immersion into a real context
KUALI-BEH 1.1 was adjusted according to the case
study results and evolved into KUALI-BEH 1.2.
This version of the artifact participated in CASE
STUDY 2 that took place at Entia, a Mexican IT
company with 20 employees. This organization
uses a game-centered workshop to elicit and
prioritize software product requirements, which
was undocumented. Their particular objective was
to document each step of the game-centered
workshop which allows the organization to carry
out the inception phase of its projects. During this
case study the artifact’s usefulness was
demonstrated; besides it operated inside a
context in which software development was not
the main purpose. The complete version is
presented in (Morales-Trujillo et al., 2014).
During CASE STUDY 3 we worked with KUALI-BEH
Extension at a Tech Institute, specifically at a
software development entity in a business
incubator program. Their objectives were: to
document their software development process;
and to train new work team members using the
defined process, which were fully achieved. The
extended version is found in (Arroyo-López et al.,
2015).
As a whole, the real context immersion proved
that our proposal is suitable for defining
practitioners’ ways of working, has real value for
practitioners and is easy to understand. The
integration of TAR and CS turned out to be a
valuable research method for the purposes of this
research: its iterative approach allowed to obtain
continuous
feedback,
it
benefited
the
organizations involved in this research, we applies
theories in practice and solve real problems by
solving real problems.
OMG standardization process
As mentioned in the Overview subsection, the
KUALI-BEH project was initiated as a response to
the FACESEM RFP. Therefore our research group
(KUALI-KAANS) had to become an OMG active
member and follow the standardization process of
the consortium.
Other organizations also responded to the
call-for-action, and their proposals were published
internally for OMG members. After OMG task
force assessed how well the submissions meet the
requirements stated in the RFP, only two
proposals continued participating, and were
invited to merge into one proposal.
For this task to be a success, the SEMAT Latin
America chapter was involved; it analyzed the
proposals, presented a mapping of common
concepts and suggested an integration strategy.
Later on, the OMG boards and committees voted
for adoption, thus KUALI-BEH became a normative
annex of the standard ESSENCE – Kernel and
Language for Software Engineering Methods
(OMG, 2014). The complete narration of this
experience can be found in (Morales-Trujillo et al.,
2015b).
Formalization
This phase of our research addresses theoretical
concerns and is mostly method engineers
oriented. We presented the knowledge in the
form of an ontology, an algebra based on
Situational Method Engineering and Description
Logics.
The Ontology helped us to clarify the knowledge
structure,
to
reduce
conceptual
and
terminological ambiguity, and to allow the sharing
of knowledge.
Theories behind the Situational Method
Engineering provided KUALI-BEH with axioms,
predicates and functions, which, in its turn, gives
means for theorizing and algebraic sustain.
As for Description Logics, it contributed to the
formal knowledge representation, allowed for
reasoning and inferring knowledge.
Related to the above presented, we find in this
thesis:
 KB-O: the language. A common representation
of knowledge as a set of concepts, attributes
and relationships of a domain in the form of
ontology
 KB-A: the algebra. A set of predicates,
functions and operations in order to represent
the common concepts, properties and
operations. And,
 KB-K: the knowledge. The knowledge
representation as a set of logical statements.
Research Contributions
As far as research contributions are concerned,
they fall into four categories. First, this work
contributes to the Theoretical Software
Engineering by having identified the universals of
software projects from Method Engineering,
Situational
Method
Engineering,
Process
Reference Models, Process Metamodels and
related Standards. Our research confirmed that
the knowledge collected in these corpus depends
on a top-down approach which needs to be
acquired by organizations, and does not allow the
organization practitioners to express their own
practices.
In contrast, the KUALI-BEH bottom-up approach
implies the expression of practitioners’ tacit
knowledge in order to build up the organization’s
way of working. It allows practitioners to express,
adapt and share their ways of working as a
collection of methods and practices. As a result it
contributes to the enrichment of Software
Engineering theory by collecting the practitioners’
knowledge.
Second, we contribute to the Practical Software
Engineering. After validating KUALI-BEH through a
collaborative workshop and three case studies, we
conclude that it is a valuable alternative for
practitioners and small organizations, since it
offers to make a first step to bridge the gap
between Software Engineering theory and
practice. KUALI-BEH permits small organizations to
create an organizational method repository
comprising their knowledge, and to gradually
introduce them to the adoption of standards and
reference models. KUALI-BEH enabled three
entities to undertake an authoring project that led
them to a software process improvement. In
consequence, with their ways of working
expressed, a deeper reasoning about it was
possible, allowing practitioners to adapt, share
and compare it in order to improve it. As a whole,
the combination of these factors derived in
valuable results for the organizations that applied
KUALI-BEH, becoming a solution within reach for
practitioners and effectively achieving the
organization’s needs in the industrial context.
Third, efforts related to Standardization should be
mentioned. We responded to the request as a
submitter by creating the KUALI-BEH proposal,
thus joining the standardization effort from the
beginning. Three years later, the active
contribution to the OMG standardization process
generated valuable lessons learned, which
concern the wide variety of IT standards and their
lack of aligned definitions, the importance and
necessity of standardization efforts despite their
not being appreciated by the academic
community, and the advantages and beneficial
results of industrial-academic synergy.
Finally, throughout the OMG standardization
process, KUALI-BEH is making an active
contribution to the identification of both the
theoretical and practical universal elements. Its
fusion with the ESSENCE proposal and its eventual
appearance as a useful and applicable standard
completed the standardization effort.
Fourth, we shall mention contributions to
Education in Software Engineering. The Software
Engineering undergraduate course for the
Bachelor’s degree in Computer Science at the
Science Faculty of the UNAM, has been
redesigned using the KUALI-BEH approach,
bringing Software Engineering theory and practice
closer to bachelor degree students.
The theoretical part of the course is presented
and supported with a set of practices that
expresses distinct ways of working in real life. The
practical part of the course is based on the
practice instance execution and method
enactment, following those defined in the
KUALI-BEH operational view and supported by the
boards defined as an alternative in managing the
project developed by the students.
Conclusions
Analyzing the additional research goals set for this
project, we find that:
 The universals of software projects were
identified by carrying out an in-depth study.
 A kernel of common concepts that facilitates
the transformation of practitioners’ tacit
knowledge into explicit knowledge was
established.
 A description of methods as a composition of
practices using the defined language was
achieved.
 A conceptual framework that supports
understanding between concepts, terms and
relations around software projects was
established.
 The framework was validated in real
organizations, and was applied by software
engineering practitioners to their everyday
efforts.
Therefore, we conclude that the main objective of
this research was fully achieved.
Future lines of research can be outlined as follows:
to enhance the robustness of KUALI-BEH, to
develop a set of KUALI-BEH profiles, to develop
and release a fully functional technological
environment, and to create a global infrastructure
of methods and practices.
References
Arroyo-López, E., Ríos-Silva, T., Morales-Trujillo, M.,
Rico-Martínez, A., Oktaba, H. (2015). Expresando
Nuestra Manera de Trabajo con KUALI-BEH: Lecciones
Aprendidas por Tic-Tac-S. In Proceedings of the
CONISOFT’15, pages 25–32.
Basili, V., Selby, R., and Hutchens, D. Experimentation in
software engineering. IEEE Trans. Softw. Eng.,
12(7):733–743, July 1986. ISSN 0098-5589.
Belady, L. and Lehman, M. (1976). A model of large program
development. IBM Syst. J., 15(3):225–252.
Bjørnson, F. O. and Dingsøyr, T. (2008). Knowledge
management in software engineering: A systematic
review of studied concepts, findings and research
methods used. Inform. Software Tech., 50(11):1055 –
1068.
Edwards, J. S. (2003). Managing software engineers and
their knowledge. In Managing software engineering
knowledge, pages 5–27. Springer.
Harrison, R., Badoo, N., Barry, E., Biffl, S., Parra, A., Winter,
B., and Wst, J. (1999). Directions and methodologies for
empirical software engineering research. Empirical
Software Engineering, 4(4):405–410.
Jacobson, I., Meyer, B., and Soley, R. (2009). The SEMAT
initiative: A call for action, December 2009.
Johnson, P., Ekstedt, M., and Jacobson, I. (2012). Where’s
the theory for software engineering? IEEE Softw.,
29(5):96.
KUALI-KAANS
Research
Group.
http://kualikaans.fciencias.unam.mx/
Morales-Trujillo, M. and Oktaba, H. (2015). Identification
and Formalization of Software Project Common Concepts.
PhD thesis, National Autonomous University of Mexico.
Morales-Trujillo, M., Oktaba, H., and González, J. (2014).
Improving software projects inception phase using
games: ActiveAction workshop. In Proceedings of the
ENASE’14, pages 180–187.
Morales-Trujillo, M., Oktaba, H., and Piattini, M. (2015a).
Using Technical-Action-Research to Validate a
Framework for Authoring Software Engineering Methods.
In Proceedings of the ICEIS'15, pages 15–27.
Morales-Trujillo, M., Oktaba, H., and Piattini, M. (2015b).
The making-of an OMG standard. Computer Standards &
Interfaces.42, November: 84–94.
OMG. Object Management Group. http://www.omg.org/
OMG. (2011). A foundation for the agile creation and
enactment of software engineering methods (FACESEM)
RFP. Technical report, Object Management Group,
Needham, MA, USA.
OMG. (2014). ESSENCE - Kernel and Language for Software
Engineering Methods. Technical report, Object
Management Group, Needham, MA, USA.
Runeson, P., Host, M., Rainer, A., and Regnell, B. (2012).
Case Study Research in Software Engineering: Guidelines
and Examples. Wiley.
SEMAT. Software Engineering Method and Theory.
http://www.semat.org/
Wang, Y. (2007). Software Engineering Foundations: A
Software Science Perspective. Auerbach Publications,
Boston, MA, USA, 1st edition.
Wieringa, R. (2014). Empirical research methods for
technology validation: Scaling up to practice. J. Syst.
Softw., 95:19–31.
Wieringa, R. and Moralı, A. (2012). Technical action research
as a validation method in information systems design
science. In Proceedings of the DESRIST’12, pages
220–238. Springer-Verlag.
Analyzing the conceptual correspondence between Blue WATCH´s
basics and SEMAT´s essentials
Judith Barrios A. & Jonás Montilva C.
University of Los Andes, Faculty of Engineering, School of Systems Engineering, Computer Science
Department, GIDyC, Mérida, Venezuela
Introduction
Software development is a complex process that
requires not only programming languages
knowledge and experience, support tool
capabilities and software product domain
understanding. It also demands work planning and
organization, in order to understand and develop
the customer requirements that the final software
product must satisfy. Consequently, software
developers require domain knowledge, tools
competences, guidelines and practices for
organizing, controlling, performing, validating and
visualizing the progress of the development work.
In the literature, we found a lot of methodological
proposals, methods, techniques, languages and
notations that aim to support a great variety of
these software development activities. Most of
these proposals are just adaptations and/or
extensions of the activities associated to the
traditional software life cycle. Generally, these
interrelated activities are grouped into phases and
arranged in order to meet particular project
characteristics, such as: software type, required
software functionalities and resources, time and
budget restrictions, management and technical
procedures, practices, skills, and team project
experience, as the most frequent criteria for
selecting and grouping these activities. However,
how the project will be finally executed depends
also on particular context situations which come
directly from client`s organization, current project
conditions (i.e., organizational domain and culture,
technological infrastructure, human and financial
resources, time to market, etc.), and from the
project leader`s domain experience and
knowledge.
With the intention of generalizing main concepts
involved in any software development project and
reduce the time and effort that the project leader
needs to define how to develop a particular
product, we defined a suite of methods called
WATCH, which is oriented to support software
development projects. WATCH is a set of method
variants that are defined over the same set of
common concepts and their particular extensions
(Barrios & Montilva, 2011a). This suite of methods
has been conceived for supporting Venezuelan
and Latin-American software industry, as well as
to help software engineering teaching at Spanish
spoken universities.
WATCH conceptual models are represented at
three levels of abstractions. The highest level of
abstraction
generalize
those
software
development concepts mostly involved in any
software development project, named core
concepts; medium abstraction level models are
specializations or extensions of those core
concepts according to software product domain,
organizational and work team size, context and
experience. At this level we characterize method
variants by representing basic concepts through
three complementary sub-models: product model,
process model and actor model. The lowest level
of abstraction is created by instantiating the
medium abstraction level sub-models to use a
method variant for developing a particular
software product. The more significant
contribution of these three levels representation
is the possibility of adapting, extending and
enacting software development process according
to software project context and domain.
The WATCH initial version was published by
Montilva and Barrios in 2003. A few years later, in
2009, an original initiative searching to define a
theory supporting software engineering work,
called SEMAT (Software Engineering Methods and
Theory), wrote a call for action and a vision
statement that aimed to tie experience and
research effort for reducing the gap existent
between the developers and academic software
communities (http://semat.org). The call for
action and the vision statements concerned the
main problems found in the exercise of software
engineering discipline by practitioners. Among the
most relevant of these statements are: immature
practices, many software development methods
and variants, lack of experimental evaluation and
validation, and the divergent courses of research
and practice in software engineering.
The first result of this initiative was a kernel of the
common concepts always involved in the software
development work. The concepts were grouped
into two set of essentials: “things we always work
with” and “things we always do” when developing
software systems. This core of fundamental
elements implicated in software development was
structured into three areas: customer area,
solution area and endeavor area. The kernel was
conceived as a common ground independent of
domain. It is based on a set of alphas (Abstract
Level Progress Health Attribute) and their states
for controlling the progress of the software
development work. The set of alphas can be
extended with new practices or work products;
the obsolete ones may be eliminated (OMG,
2013).
In both initiatives, the essential or basic elements
were abstracted from project implementation and
consulting experiences, as well as from adapted
and repeated ways of working followed for
developing different kinds of software products.
The purpose of this work is to model the existing
correspondence between these two set of
software development fundamental concepts: the
SEMAT kernel and the WATCH conceptual models.
Considering that both initiatives searched to
establish a small set of common elements
implicated in the process of developing a software
product, this article aims to highlight similarities
and differences among them. We observed that,
even when both approaches use different point of
view, specification languages and techniques for
representing fundamental concepts, there is a
closed conceptual relationship between WATCH
and SEMAT. As a result, we are able to corroborate
that the core of concepts of the WATCH suite of
methods is valid, applicable, and well founded.
The rest of the paper is structured as follows.
Section 2 introduces the WATCH meta-model and
the basic concepts of one of its variant: the
Blue_WATCH method. Section 3 presents briefly
the SEMAT initiative and its kernel or essential
concepts for software development. Section 4
contains the correspondence analysis between
WATCH basic concepts and SEMAT essentials
already described in section 2 and 3, respectively.
The analysis leads us to highlight similarities and
differences between these two set of fundamental
concepts, which are discussed in the concluding
section.
WATCH basic concepts
WATCH is a methodological framework supported
by a set of basic software development concepts
that can be assembled and extended to compose
specific methods (Barrios & Montilva, 2011a),
(Barrios & Montilva, 2013). A basic concept may
be ab common and invariant element that is
always involved in the process of building high
quality software products, an element that
represents a characteristic or state of the software
product being built or an extension of some other
core concept. As a consequence, a basic concept is
used by most software development methods,
frameworks and methodological propositions.
Therefore, its value and relevance in the process
Proceedings of the Latin American Software Engineering Symposium, Año 2015, pp. 10 -15, ISSN 2500-5014
of software product development has been
recognized; for instance, concepts like artifact,
activity, user or stakeholder are present in
well-known methods, such as RUP, SCRUM, XP
and many others. Generally, these basic elements
are tied to the software development cycle and
are related to common software engineering
techniques and practices for producing software
products. Furthermore, these elements were also
abstracted from the day to day software
development practice and successful software
project experiences.
In order to represent the most common elements
involved in the development process, we
identified what is done most of the time, what
sorts of practices are applied, under which
conditions and project types they are applied, and
what was the most frequent context of their
usage. A similar approach was implemented for
identifying common artifacts, intermediate and
final software products involved in the
development process.
We set these common elements as the core of the
WATCH meta-model which aims to serve as a
methodological framework for defining method
variants. Figure 1 shows the main concepts and
relationships that compose our meta-model. The
basic concepts are placed within two boundaries
according to their organizational or project
context of use.
and/or specializations of basic concepts for
handling some software project particularities
such as project type, team size and experience,
product characteristics or domain problems. In
(Barrios & Montilva, 2011a) and (Barrios et al.,
2011), we describe, in detail, the relation between
WATCH meta-model and its adaptations for
defining method variants.
Initially, the WATCH method suite was composed
by six variants; but just three of them are the
most used in Venezuelan context: the
Gray-WATCH (Montilva & Barrios, 2003), the
White-WATCH and the Blue-WATCH (Montilva et al,
2011). The later one is the balanced version of the
suite and contains, among others, practices
associated with the agile software development
approach.
For the purpose of this paper, we chose the
conceptual model of the Blue WATCH variant,
because it extends the initial basic meta-model
with agile concepts. This variant is divided into
three complementary sub-models according to
method engineering recommendations: product
model, process model and, actor model. Figures 2
and 3 show two of the three Blue-WATCH
conceptual models. For space reasons, the actor
model is not shown.
The product model classifies the software
development products in two categories:
intermediate and delivery products. The process
model is also divided in two categories: technical
and support process, according to the software
development value chain. The actor model is a
typical classifications of actors according to the
roles they play in a software development project.
The conceptual relationships between the three
models can be derived from Fig. 1.
Figure 1. The WATCH meta-model
WATCH is a method suite built over this set of
software development basic concepts. A method
variant is the result of instantiations, extensions
of concerns: (1) a set of basic elements, called
alphas, the essential things that developers always
produce or work with, (2) the activities spaces
that represent the essential things to do, and (3)
the key competences that are required to do
software engineering.
In order to express kernel areas of concern in a
representation comparable to WATCH conceptual
models, we elaborate the class diagrams of figures
4 and 5 that represent the alphas and the
activities spaces, respectively.
Figure 2. Blue-WATCH product model
Figure 4. The Kernel Alphas
Figure 3. Blue-WATCH process model
SEMAT Kernel of essentials
SEMAT is an initiative founded in 2009 by Ivar
Jacobson, Bertrand Meyer and Richard Soley.
Their idea was working towards a new and simple
relationship between software engineering
research and practice. SEMAT aims to support
processes for redefining software engineering
based on a solid theory, proven principles, and
best practices. A kernel of the essential elements
of software engineering is their first contribution
to the software development community. One of
its main intended uses is in helping practitioners
compare methods and make better decisions
about their practices (OMG, 2013).
At a glance, this kernel is composed by three areas
Figure 5. The Kernel Activity Spaces
As shown in figure 3, the kernel alphas are
arranged according to three levels of concern:
Customer, Solution and Endeavour. The area of
Customer defines alphas related to software
product customer and he/her organizational
context. It includes problems or opportunities,
exigencies and information about the SW system
to be elaborated. The Solution area groups the
alphas concerned with the SW product to be
elaborated. The Endeavour area concerns all
management elements needed for building the
software solution according to customer
requirements.
Figure 4 shows the core activities or “things to do”
organized by the three areas of concerns:
customer, solution and endeavor.
Comparing
WATCH
conceptual
models and SEMAT essentials
In order to make a more fair comparison, we
rearrange Blue_WATCH basic concepts into two
groups according to SEMAT “things to work with”
and “things to do”. Consequently, the analysis is
made between Blue_WATCH product and actors
models with SEMAT “things to work with” and,
Blue_WATCH technical process model with “things
to do” of SEMAT initiative.
Another perspective considered for the
comparison analysis is the separation of SEMAT
“things to do” into three areas: Customer Area,
Solution Area and, Endeavour Area. Therefore,
the Solution Area corresponds to the WATCH set
of technical processes; the Endeavour Area
corresponds to the Project Management process,
and Customer Area corresponds to some technical
and project management processes already
included in the technical and support WATCH
process models.
The diagram shown in figure 6 establishes the
correspondence between both groups of
conceptual models.
By analyzing the global models of WATCH and
SEMAT showed in figures 1 and 4, respectively, we
observe that there is almost a complete
correspondence among the fundamental concepts
defined for both approaches, except for the
concept of resources linked to a software
development project in WATCH, which it is not
explicitly considered in the SEMAT model. This
concept of resource implicated in a software
project is only considered by SEMAT kernel at a
more detailed view of “things to do”; but, just
under the perspective of humans and tools
required for performing software development
work.
With regard to the product model of Blue_WATCH,
we observe that the concepts of software product,
and its classification into technical and support
processes, are not present in the kernel, neither
the concept of intermediate product. The kernel
only considers the software system, which is a
final or delivery product of any software
development project. At the software project
management level or area, the kernel includes
explicitly the progress cards as a support element
for tracking progress of work according to changes
in alphas´ states.
In the analysis for the endeavor area, we noticed
that the kernel activities for preparation of work
suggest a work plan, but it is not included as an
essential element. Blue_WATCH models define a
project plan as a basic element to support the
progress of a software project. This is one the
most relevant differences between both
conceptual models.
Figure 6 provides a global view of Blue_WATCH
and SEMAT Kernel correspondence; i.e. the
general WATCH concepts of Product, Process,
Actor and resources with the “things to do” and
“things to work with” of the kernel. Besides, the
diagram of this figure makes explicit the
relationships between the technical and support
processes and the Customer, Solution and
Endeavour areas of concern.
WATCH models consider that an intermediate or
final software product must be produced by the
execution of technical, support or management
activities of a software project. The quality of a
product is linked to the quality of the process
performed to produce it; thus, in a software
development project, actors perform not only
technical processes but also managerial and
support processes, such as: Project Management,
Product Validation and Verification, Software
Configuration Management, Quality Assurance,
and Project Risk Management. These technical
and support processes are well detailed in
(Montilva et al., 2011).
In SEMAT kernel, the activity space has its
correspondence with Blue_WATCH process model
for some technical and support activities involved
in software development; but, in regard to the
support process, the kernel only includes some
project management activities into the alphas´
states at the solution area, as well as the activities
of the Endeavour area concerned with prepare,
coordinate and track the work.
group of activities. Other support activities
required to develop a high quality software
product like quality assurance, software
configuration management, validation and
verification are not explicitly included in the kernel.
Taking into account the high level motivation of
the kernel definition, we understand that these
elements may be added as extensions of the
concepts already included under the responsibility
of practitioners.
Considering the defined set of alphas, we observe
that Blue_WATCH product model does not
explicitly contain a state for tracking and, in
consequence
controlling
progress
of
a
development process; nor a similar concept to
assess the states of alphas or other software
products. However, Blue_WATCH process model
incorporate equivalent activities, and their
support products, in the project management
process included as one of the Support Processes
group (see figure 3).
Conclusions
Figure 6. SEMAT Kernel and WATCH Conceptual
Models correspondence at a high level of
abstraction
In this sense, we observe that SEMAT essentials
are mostly concentrated on the technical
elements of software product development rather
than the associated technical development
activities; except for the inclusion of some
management elements which are linked to the
project of software development at the endeavor
In this paper, we have presented a
correspondence analysis between Blue_WATCH
conceptual models and the essentials of the
SEMAT kernel. We focused the analysis on
comparing mostly Blue_WATCH product and
process models with kernel essentials. The
concept of actor is taken into account just from a
general point of view as the personal that is on
charge of developing software products by
executing software process´ activities.
As a result of the correspondence analysis, we are
able to confirm the validity and applicability of the
WATCH method suite for guiding software
development projects; i.e. taking into account that
the kernel proposed by SEMAT aims to support
creation, use and improvement of software
engineering methods, and confirming the fact that
most of WATCH basic concepts are, in some way,
considered by the kernel, we can corroborate the
validity and applicability of WATCH method suite
for supporting a software development project.
It is important to remind that Blue_WATCH is a
method variant that needs to be adapted for
being applied in a particular software project,
hence its level of detail is larger than that of the
SEMAT kernel.
Due to space restrictions, we did not present all
Blue_WATCH model elements. Our goal was to
evaluate if the basic concepts upon which we built
the method variant were included into the kernel
essentials. A comparison of other elements, such
as actor´s competencies, agile practices and
modeling languages were left for future work.
The kernel essentials are really fundamentals and
key for any software development work.
Nevertheless, we consider that the kernel of
essential might add some more elements “things
to work with” related to the area of endeavor
activities because the quality of a software
product is strong related to the activities that
support technical work.
Conference on Enterprise Information Systems. Proc. of
ICEIS´2003. Angers, France: 23-26, April.
Montilva, J., Montilva, W., & Barrios. J. 2011. Blue WATCH:
Un marco metodológico balanceado para el desarrollo
de software en pequeñas empresas. Ninth
Latin-American and Caribbean Conference, Engineering
for a Smart Planet, Innovation, Information Technology
and Computational Tools for Sustainable Development,
Proc of LACEEI 2011. Medellin, Colombia. Agosto.
OMG. 2013. Essence – Kernel and Language for Software
Engineering Methods. OMG Document Number
ptc/2013-06-08. Object Management Group.
Acknowledgements
This work is part of the results obtained from
Projects 2005000165 and 2012001090 sponsored
by the Venezuelan National Found of Science,
Innovation and Technology (FONACIT).
REFERENCES
Barrios, J. & Montilva, J. 2011a. Watch: a suite of methods
for facilitating software development process
adaptability. In Carlos M. Zapata, et al (eds), Software
Engineering: Methods, Modeling and Teaching: 55-68.
Medellin: Sello Editorial.
Barrios, J. & Montilva, J. 2011b. A balanced and adaptable
method for software development in very small
enterprises: the blue watch variant. In Carlos M. Zapata,
et al (eds), Software Engineering: Methods, Modeling
and Teaching: 39-54. Medellin: Sello Editorial.
Barrios, J. & Montilva, J. 2013. Integrating the
Methodological Frameworks WATCH and SCRUM. A
Method
Engineering
Approach.
Conferencia
Latinoamericana en Informática. Actas del CLEI 2013.
Caracas, Venezuela Octubre.
Barrios, J., Montilva, J. & Rivero, D. 2011. The WATCH
Method Suite in Practice: two complementary
perspectives of use. Actas de la Conferencia
Latinoamericana en Informática. CLEI 2011. Quito
Ecuador. Octubre.
Krutchen, Ph. 2000. The Rational Unified Process, Second
Edition. Addison-Wesley.
Montilva, J. & Barrios, J. 2003. A Component-Based Method
for Developing Web Applications. 5th International
Proceedings of the Latin American Software Engineering Symposium, Año 2015, pp.15 – 15, ISSN 20500-5014
El núcleo de SEMAT
y la Calidad de
Software
Identificación de criterios para relacionar la Usabilidad con el alfa
Sistema de Software del núcleo de SEMAT
W. Perdomo
Universidad de San Buenaventura, Medellín, Colombia
C. M. Zapata
Universidad Nacional, Medellín, Colombia
Resumen
Una de las áreas más importantes para Semat
(iniciativa para los métodos y teorías de la
ingeniería de software) es la calidad de software.
Algunos de los criterios que se evalúan dentro de
la norma ISO/IEC 9126 son las características y
subcaracterísticas de medición de la calidad
mediante métricas internas, externas y de calidad
en uso. En este artículo se realiza un contexto de
Semat y de la norma ISO/IEC 9126.
Adicionalmente, se muestra una revisión de
literatura disponible sobre modelos de medición
de la calidad en productos de software, con el fin
de identificar algunos criterios, para definir la
relación entre la característica de usabilidad de la
métrica externa de la norma, con el alfa sistema
de software y sus estados del núcleo de Semat.
PALABRAS CLAVE: ISO/IEC 9126, Semat, calidad de
software, métricas, alfas, estados.
Introducción
La medición del software es una herramienta que
permite el desarrollo de software de calidad para
todo su ciclo de vida. Para la medición del
software se utilizan métricas, que permiten
obtener un valor numérico de las características
de calidad de un producto de software [1].
Para representar, caracterizar y medir la calidad de
software existen la norma ISO/IEC 9126 como un
estándar internacional para la evaluación de la
calidad, que se divide en cuatro etapas: modelo
de calidad, métricas externas, métricas internas y
la calidad en el uso de métricas [2].
En cuanto a la ingeniería de software, en 2009
nace una nueva iniciativa para los métodos y
teoría de la Ingeniería de Software (Semat), la cual
se puso en marcha con el objetivo de refundar la
ingeniería de software como una disciplina
rigurosa que se base en una teoría sólida,
principios probados, y las mejores prácticas [3].
Semat sugiere que un método es una composición
de las prácticas que se describen en términos de
los elementos esenciales del núcleo. Además,
sugiere un lenguaje de dominio específico que se
utiliza en la definición de los elementos del núcleo
y su uso [4].
En este artículo se presenta una revisión de
literatura disponible sobre los modelos de
medición de la calidad en productos de software,
con el fin de identificar algunos criterios para
definir la relación entre la característica de
usabilidad de la métrica externa de la norma, con
el alfa sistema de software y sus estados del
núcleo de Semat.
Marco Conceptual
Modelos de evaluación de la calidad de
software
La revisión y las pruebas del software son
procesos orientados a la detección de defectos en
el producto. McCall [7] y Boehm [8],
Proceedings of the Latin American Software Engineering Symposium, Año 2015, pp. 17 –22, ISSN 2500-5014
descomponen el concepto de calidad en
propiedades más sencillas de medir y de evaluar.
El modelo de McCall se basa en la descomposición
del concepto de calidad en tres usos importantes
de un producto de software, desde el punto de
vista del usuario: operación, revisión y transición
del producto [7]. Cada propiedad se descompone
en una serie de factores a saber: facilidad de uso,
integridad, fiabilidad, corrección, flexibilidad,
facilidad de prueba, facilidad de mantenimiento,
transportabilidad, reusabilidad e interoperabilidad.
Este modelo fue el primero en proponer la
evaluación de la calidad del software por medio
de métodos automáticos y cuantitativos [8].
Otros modelos [9] proponen el paradigma GQM,
(objetivo-pregunta-métrica) para evaluar la
calidad de cada proyecto. En 1991, la Organización
Internacional de Estándares (ISO) en conjunto con
la Comisión Electrotécnica Internacional (IEC)
propusieron un estándar para la evaluación de la
calidad del software, denominado ISO/IEC 9126
[10]. El estándar ISO/IEC 9126 consta de cuatro
partes: modelo de calidad [11], métricas externas
[12], métricas internas [13] y métricas para la
calidad en uso [14]. Así, se propone un modelo de
calidad categorizando los atributos de software en
seis características (funcionalidad, fiabilidad,
usabilidad,
eficiencia,
mantenibilidad
y
portabilidad), las cuales se subdividen en
subcaracterísticas (véase la Fig. 1).
SEMAT
En 2009, nace una nueva iniciativa para los
métodos y teorías de la Ingeniería de Software
(Semat), la cual se puso en marcha con el objetivo
de refundar la ingeniería de software como una
disciplina rigurosa que se base en una teoría
sólida, principios probados y las mejores prácticas
[3].
Los espacios de actividad de la esencia del núcleo
de Semat se enfocan en tres áreas de interés, a
saber [5]:
 Esfuerzo: prepararse para hacer el trabajo,
coordinar actividades, apoyar el equipo, rastrear
el progreso y detener el trabajo.
 Solución: comprender los requisitos, darle
forma al sistema, implementar el sistema, probar
el sistema, desplegar el sistema y operar el
sistema.
 Cliente: explorar posibilidades, comprender
las necesidades del interesado, asegurar la
satisfacción del interesado y usar el sistema.
También, se identificaron siete elementos
necesarios del núcleo o "Alfas" [3], que son [5] [6]:
oportunidad, interesados, requisitos, sistema de
software, trabajo, equipo y forma de trabajo. Los
alfas se caracterizan por un simple conjunto de
estados que representan su progreso y salud. Esos
estados hacen que el núcleo sea accionable y lo
habilitan para guiar el comportamiento de los
equipos de desarrollo de software (véase la Fig.2).
Revisión de Literatura
Figura 1. Características de calidad ISO 9126.
Fuente: tomado de [11]
La norma ISO/IEC 9126 [15] se evalúa la calidad de
las aplicaciones B2B con un modelo personalizado
de acuerdo con las características especiales de
aplicaciones B2B. La personalización se realizó
mediante la extracción de los factores de calidad
de las aplicaciones Web y aplicaciones de
comercio electrónico, ponderando estos factores
desde los puntos de vista de los desarrolladores y
los usuarios finales.
En una empresa del sector hidrocarburífero [16]
se evalúa la calidad del software de producción,
para lo cual se determinan las métricas que
permiten medir la calidad de un producto de
software. Se parte de la comparación de
parámetros de calidad de un proyecto con
estimaciones realizadas mediante el uso de
estándares internacionales y datos que aportan la
experiencia en otros proyectos. El cumplimiento
de
las
diferentes
características
y
subcaracterísticas se puede apreciar en la Tabla 1.
Este análisis permite calcular la probabilidad de
certificación de la empresa en cuestión a la luz de
la norma.
Figura 2. Los alfas y sus estados en el núcleo de
Semat.
Tabla 1. Cumplimiento de características de
calidad.
SUB-CARACTERÍSTICA
Cumple
No Cumple
No Requerida
Total
Funcionalidad
Característica
3
1
1
5
Confiabilidad
3
0
1
4
Facilidad uso
3
1
1
5
Eficiencia
Facilidad
mantenimiento
2
3
1
6
3
1
1
5
Portabilidad
2
1
1
4
Totales
16
7
6
29
ello, sólo se evaluaron características que son
susceptibles de aplicar al modelo conceptual,
como funcionalidad, usabilidad y mantenibilidad.
Identificación de criterios para
relacionar la usabilidad con el alfa
sistema de software y sus estados
La métrica de usabilidad, mide el grado en que el
software se puede comprender, aprender, operar
y relacionar con las normas de usabilidad [12]. Los
usuarios prueban muchas métricas de usabilidad
externas, al intentar utilizar una función. Las
capacidades de los usuarios y las características
del sistema de acogida influyen en los resultados.
Esto no invalida las medidas, ya que el software
evaluado se ejecuta en condiciones especificadas
explícitamente con una muestra de usuarios que
son representativos de un grupo identificado.
Entre las características de la métrica, se tienen las
siguientes sub-características: comprensibilidad,
facilidad de aprendizaje, operabilidad y atracción.
Con lo anterior, y como resultado del análisis y la
relación entre la característica de la métrica y los
estados del alfa sistema de software, se tiene:
demostrable, usable, listo y operacional, se
muestra en la Figura 3 el esquema de relación de
la característica usabilidad con los estados del alfa.
Otros autores [17] utilizan la ISO/IEC 9126-3 para
evaluar los criterios de calidad del modelo
conceptual, dentro del ciclo de vida de las bases
de datos. Para esta evaluación se aplican métricas
internas y se identifican criterios que no se
evalúan, como, por ejemplo, la portabilidad,
debido a que es un criterio que requiere una
implementación física del modelo de datos; por
Figura 3. Esquema de relación usabilidad, estados
del alfa sistema de software. Fuente: elaboración
propia
En la Figura 3 se observa que existe una relación
directa de cuatro de los seis estados del alfa
sistema de software con cada una de las
subcaracterísticas de la característica usabilidad,
dejando por fuera de este esquema los estados
“con arquitectura seleccionada” y “retirado”, cada
uno relacionado con las características
funcionalidad y portabilidad respectivamente, que
es tema de otro estudio. El objetivo del esquema
de la Figura 3 es identificar los criterios de la
relación de estados del alfa sistema de software y
la característica de usabilidad, encaminados al
cumplimiento
efectivo
de
las
métricas
establecidas en la norma ISO/IEC 9126:2, sin
descuidar el significado de cada uno de los
estados del alfa. Como se observa en la Tabla 2, se
establecen las métricas externas que permiten
relacionar el estado del alfa con la característica y
sus subcaracterísticas.
Como se observa en la tabla, se identifican las
relaciones entre la característica de usabilidad, los
estados del alfa sistema de software y las métricas
de la norma ISO/IEC 9126:2, que se relacionan
directamente con cada una de las definiciones de
los estados del alfa y de la subcaracterística.
Algunas de las métricas se relacionan
directamente y las que no aplican (NA) se
especifican en la tabla.
Así, la subcaracterística de comprensibilidad se
articula con el estado del alfa demostrable y a éste
se le deben aplicar las métricas establecidas en la
norma, para validar la calidad del producto de
software en términos del uso previsto,
identificando si es adecuado y verificando la
forma en que se puede utilizar para tareas
particulares.
Tabla 2. Relación de métricas de la característica
usabilidad con los estados del alfa
Subcaracterísticas
Usabilidad
Estados del
Alfa Sistema
de Software
Usable
Integridad de la descripción
(arquitectura de software).
Demostración efectiva.
Función evidente.
Función comprensibilidad.
Entrada y salida comprensible.
NA
Listo
NA
Operacional
NA
Demostrable
NA
Facilidad de aprendizaje para
realizar una tarea en uso.
Demostrable
Comprensibilidad
Facilidad de aprender
Métricas externas por aplicar
Norma ISO/IEC 9126:2
Usable
Subcaracterísticas
Usabilidad
Estados del
Alfa Sistema
de Software
Listo
Operacional
Demostrable
Usable
Listo
Operabilidad
Operacional
Demostrable
Usable
Atracción
Listo
Operacional
Métricas externas por aplicar
Norma ISO/IEC 9126:2
Efectividad de la
documentación del usuario y / o
sistema de ayuda.
Facilidad de la función de
aprendizaje.
Ayuda y accesibilidad.
NA
Personalización.
La accesibilidad física.
NA
Coherencia operacional en uso.
La corrección de errores en uso.
Corrección de errores.
Disponibilidad de valor por
defecto en uso.
Comprensibilidad de mensajes
en uso.
Recuperabilidad de error
operativo en uso.
Tiempo entre operaciones del
error humano en uso.
Reducción del procedimiento
de operación.
NA
Personalización apariencia de
interfaz.
Interacción atractiva.
Personalización apariencia de
interfaz.
Fuente: elaboración propia
En el caso de la subcaracterística facilidad de
aprender, sólo se articula con los estados usable,
listo y operacional, teniendo en cuenta que su
propósito es el de evaluar cómo los usuarios a lo
largo de la utilización del producto tardan en
aprender a utilizar determinadas funciones, y la
eficacia que tienen los sistemas de ayuda y
documentación. La sub-característica operabilidad,
se relaciona directamente con los estados usable y
operacional, teniendo mayor articulación con éste
último debido a que, mediante la métrica, es
posible evaluar la capacidad de los usuarios para
operar y controlar el producto de software.
Finalmente, la sub-característica atraccción
muestra una fuerte relación con los estados
usable, listo y operacional, ya que se enfoca en la
capacidad de evaluar el aspecto del software,
influenciado por factores como el diseño y el color,
enmarcados en la métrica de personalización del
producto.
Conclusiones
Las mediciones de la calidad de software
constituyen una de las actividades más
importantes y criticas del ciclo de vida de
desarrollo del software, ya que garantizan la
calidad del producto e influyen directamente en el
costo de desarrollo y el éxito de su
implementación.
La relación identificada de cada una de las
sub-características de la usabilidad como
característica de las métricas externas de la norma
ISO/IEC 9126:2, con los estados del alfa sistema de
software, evidencia la necesidad de integrar los
conceptos y la funcionalidad de los estados del
alfa con las métricas definidas para evaluar los
productos de software.
En este artículo se hizo una revisión de literatura
acerca de la aplicación de las mediciones de la
norma ISO/IEC 9126, en el desarrollo de
productos de software y se logró evidenciar la no
existencia de este procedimiento en el núcleo
Semat como marco de trabajo de la ingeniería de
software.
Como trabajo futuro se plantea analizar las
características de funcionalidad y portabilidad
para relacionar los estados del alfa sistema de
software: con arquitectura seleccionada y retirado
respectivamente. Además, se pretende realizar un
caso de estudio para validar la relación propuesta
en el presente artículo y la efectiva medición de la
calidad en los estados del alfa.
Referencias
[1] Núñez, A, Pérez, H. G., Cuevas J. C. and
Soubervielle C. (2013). A Methodology for
Obtaining Universal Software Code Metrics.
Journal Procedia Technology, 7(1), pp.
336-343.
[2] Ordóñez M. J. and Haddad H. M. (2008). The
State of Metrics in Software Industry. Fifth
International Conference on Information
Technology: New Generations. Journal IEEE, pp.
453-458.
[3] Jacobson, I. (2012). Software Engineering
Approaches for Offshore and Outsourced
Development. Chapter: A Smarter Way: The
Software Engineering Method and Theory
Initiative (Semat) [e-book]. St. Petersburg,
Russia: Springer Link.
[4] Kajko-Mattsson, M. et al. (2012). Refounding
software engineering: The Semat initiative.
Journal IEEE, pp. 1649-1650.
[5] Jacobson, I., Ng. P-W., MacMahon, P. E.,
Spence, I., Lidman, S. y Zapata C. M. (2013). La
esencia de la ingeniería de software: El núcleo
de Semat. Revista Latinoamericana de
Ingeniería de Software, 3(1), pp. 71-78.
[6] Dwolatzky, B. (2012). Re-founding software
engineering practice - The SEMAT initiative.
4th Colloquium Software Engineering (SE).
Journal IEEE, pp. 1-3.
[7] McCall, J. A., Richards P. K. and Walters G. F.
(1977). Factors in software quality, vols. I, II y
III. NTIS; Roma, pp. 10-168.
[8] Boehm, B. W., Brown, J. R. and Lipow, M.
(1976). Quantitative evaluation of software
quality. 2nd. international conference on
Software engineering (ICSE), USA. Journal IEEE,
pp. 592-605.
[9] Basili, V. R. and Rombach, H. D. (1988). The
TAME
project:
towards
improvement−orientated
software
enviroments. Journal IEEE Transactions on
Software Engineering, 14(6), pp. 758-773.
[10] Grady, R. B. and Caswell, D. I. (1987). Software
metrics establishing a Company-Wide program.
Nueva Jersey. Prentice Hall.
[11] ISO/IEC. (2002a). Software engineering Product quality - Part 1: Quality model,
Canadá, International Technical Report ISO/IEC
9126-1, joint Technical Committee ISO/IEC
JTC1, p. 25.
[12] ISO/IEC. (2002b). Software engineering Product quality - Part 2: External metrics,
JTC1, p. 28.
[13] ISO/IEC. (2002c). Software engineering Product quality - Part 3: Internal metrics,
JTC1, p. 73.
[14] ISO/IEC. (2002d). Software engineering Product quality - Part 4: Quality in use metrics,
9126-4, Joint Technical Committee ISO/IEC
JTC1, p. 64.
[15] Behkamal, B., Kahani, M. and Akbari, M. K.
(2009). Customizing ISO 9126 quality model
for evaluation of B2B applications. Journal
Information and software technology, 51(3),
pp. 599-609.
[16] Cochea, S. J. (2009). Métricas de calidad de
los sistemas de información, aplicación en la
certificación de calidad de un sistema de una
empresa del sector hidrocarburífero. M.S. tesis,
Escuela Superior Politécnica del Litoral,
Guayaquil, Ecuador.
[17] González, M. F. y González, J. S. (2013).
Aplicación del estándar ISO/IEC 9126-3 en el
modelo de datos conceptual entidad-relación.
Revista Facultad de Ingeniería, UPTC, 22(35),
pp. 113-125.
LA GESTIÓN DE LAS PRUEBAS DE SOFTWARE REPRESENTADAS CON SEMAT
F.A. Vargas, J.C. Giraldo & D.E. Soto
Tecnologico de Antioquia
Introducción
La ingeniería de software busca la estandarización
y normalización de los procesos y una base común
de elementos que se puedan constituir en un
núcleo, que facilite a los analistas utilizarlo en
diferentes fases del ciclo de vida, como un
conjunto de métodos y buenas prácticas que
garanticen la calidad del producto de software. En
este artículo se representa el proceso de gestión
de pruebas de software por medio de SEMAT.
El artículo se estructura de la siguiente forma: en
la sesión
2 se presenta los conceptos más
relevantes en cuanto a SEMAT y gestión de
pruebas de software; en la sesión 3 se describe
la gestión de pruebas con SEMAT por medio de
una representación gráfica; en la sesión 4 las
conclusiones y por último las referencias.
Marco teórico
SEMAT (Software Engineering Method
and Theory)
Se concibe como una iniciativa que pretende
refundar la ingeniería de software mediante la
definición de una teoría sólida, principios
probados y mejores prácticas. SEMAT pretende
definir un núcleo que permita describir, usando un
lenguaje, las prácticas del desarrollo de software,
de tal forma que se puedan aplicar, evaluar y
medir. SEMAT direcciona su trabajo en tres
grandes áreas: Cliente, Solución y Esfuerzo. La
primera pretende el conocimiento del contexto y
las necesidades del mismo. La Segunda está
enfocada en la solución de la pieza de software y
la tercera en la conformación del equipo de
trabajo para cumplir el objetivo propuesto
(Jacobson, Meyer, Soley, 2010). En la Tabla 1 se
describen los elementos de SEMAT que se
emplean en la propuesta (Jacobson, McMahon,
Spence, & Lidman, 2013).
Pruebas de software
La literatura existente en el área provee una gran
variedad de definiciones de pruebas de software,
de las cuales se referencia las siguientes:
La prueba se define como: “la actividad en que un
sistema o un componente se ejecuta bajo
condiciones controladas, los resultados son
registrados y la evaluación es realizada sobre
algún aspecto del sistema o componente” (ISO /
IEC / IEEE, 2010).
Graham, Van Veenendaal, & Evans (2008)
plantean que en la norma ISTQB el proceso de
pruebas se define como la planificación de
pruebas y control, análisis y diseño,
implementación y ejecución. Además, la
evaluación de los criterios de salida y
presentación de informes, y por último el cierre
de prueba de software.
La norma ISO/IEC 29119 es consistente con la
norma ISO/IEC 122207 (estándar para los
procesos de ciclo de vida del software de la
organización ISO). Esta estandariza la forma como
se planifica, diseña, ejecuta y mantienen las
pruebas, unifica estándares anteriores y aplicables
a diferentes tipos de sistemas de software.
Tabla 1. Elementos de SEMAT (Adaptado de
Zapata, Castro & Vargas, 2014).
Elemento
Simbolo
Información
Alfa
Espacio
de
Actividad
Actividad
Productos
de Trabajo
Práctica
Elemento que identifica
cada una de las cosas que
el equipo debe de
gestionar, producir y
desarrollar para el logro
de un proyecto de
software
Elemento del núcleo que
permite describir las
tareas que cualquier
equipo debe llevar a cabo
durante el desarrollo de
un proyecto de software
describe como realizar un
proceso dentro de un
proyecto de software
representa un artefacto
de relevancia para el
equipo de ingeniería de
software.
Elemento necesario del
núcleo de Semat para
expresar la guía de
trabajo con un objetivo
específico.
En consecuencia las pruebas de software, se
consideran como un proceso paralelo al proceso
de desarrollo que permite evaluar desde
diferentes
aspectos
y
momentos
el
comportamiento de un sistema o componente.
Infiriendo elementos relevantes en el proceso
como: alcance, criterios, gestión y estrategia,
entre otros. (Tuya, 2009).
La norma define un modelo de tres capas para
realizar el proceso de pruebas: los procesos
organizacionales, los procesos de gestión y los
procesos dinámicos, los cuales interactúan con los
conceptos: política, estrategia, gestión y ejecución;
para lograr una interacción de la Estrategia
organizacional, la
gestión del proceso y el
proceso
técnico de la pruebas (Kasurinen,
2010).
Los procesos de pruebas de la organización
establecen las políticas de prueba, que están
relacionadas con el alcance, los objetivos, y los
principios gobernantes de la organización.
Igualmente definen las estrategias de pruebas,
que tienen que ver con los procesos, responsables,
productos, técnicas y herramientas. Estas acciones
generan un flujo de datos que alimenta el proceso
de gestión de pruebas (Ver figura 1). En la Tabla 2
se especifican los componentes de la gestión de
pruebas, de acuerdo a la norma.
Figura 1. Modelo de procesos de pruebas de
Software Fuente: Los autores (Adaptado de
Estándar Internacional para pruebas de Software
ISO/IEC/IEEE 29119).
A continuación se describen los procesos de
gestión de las pruebas y pruebas dinámicas, y en
la tabla 2 se especifican las actividades, subactividades, producto de trabajo, y roles de estos
procesos.
Procesos de gestión de pruebas
Implican la Planificación, control y seguimiento.
En la planificacion (plan de procesos) se entiende
el contexto, es decir el alcance de la gestion de
pruebas, se organiza el plan de pruebas a traves
de un cronograma, se identifican y analizan los
riesgos potenciales, se debe identificar como
mitigar los riesgo, luego se diseña la estrategia de
pruebas, para esto se determina el personal y
actividades calendario, posteriormente se registra
el plan de pruebas (borrador), luego se llega a un
consenso, y por ultimo se comunica.
A partir
del plan de pruebas, se hace gestion a pruebas
estaticas, pruebas de sistema, pruebas de
usabilidad, pruebas de aceptacion. Se preparan
las metricas, y posteriormente se le hace control y
seguimiento, logrando un monitoreo permanente.
Esto se hace siguiendo protocolos o directrices de
control, en caso de presentarse inconsistencias, se
hacen actualizaciones al plan de pruebas
(realimentación).
En otro caso se generan
resultados y finalizan los procesos de gestión.
Finalmente se presenta un informe con el
estado de las pruebas (directrices de control). Ver
figura 1.
Procesos de pruebas dinámicas
Desde la gestión de pruebas se alimenta la etapa
para
procesos
de
Pruebas
Dinámicas,
concretamente con las métricas obtenidas. Las
pruebas
dinamicas,
exigen
diseño
e
implementacion, esto implica un flujo que indica
requisitos del contexto de pruebas, luego se da el
mantenimiento del entorno de pruebas, se genera
informe del entorno, y se ejecutan las pruebas.
Si se presentan incidencias se pueden repetir las
pruebas, de lo contrario termina el proceso. Este
proceso proporciona un flujo de datos relacionado
con el control, métricas y directrices para las
pruebas de Software.
Este flujo obtenido
realimenta el proceso de Gestión de Pruebas,
concretamente los niveles de planificación y
finalización. Ver figura 1.
Diseño e
Implementación
Gestión del
Entorno
Pruebas
dinámicas
Ejecución
Reporte de
Incidencias
gestión métricas
Especificación de
pruebas
Requisitos del
entorno de
pruebas
Informe de
entorno
Informe de
resultados con
pruebas
ejecutadas
pruebas
Coordinador
de pruebas
Plan de Desarrollo
de pruebas
Todos los
Roles
Diseñador de
pruebas
Probador
Propuesta
Se representan los procesos de gestión de
pruebas y de pruebas dinámicas, teniendo en
cuenta los productos de trabajo, roles, y fases
donde se ejecutan cada uno de ellos.
Figura 2. Espacios de actividad y actividades
asociadas a la fase inicio del proceso planear la
gestión de pruebas
Tabla 2. Componentes de la Gestión de Pruebas
de Software
Fuente: Los autores (Adaptado de Estándar
Internacional para pruebas de Software
ISO/IEC/IEEE 29119).
Actividad
Sub-Actividad
Planificación
Gestión
de las
pruebas
Control y
seguimiento
Finalización
Producto de
Trabajo
Plan de Pruebas
(Cronograma)
Informe de
monitoreo, e
inconsistencias
Informe final de
Rol
Diseñador de
pruebas
Probador
Diseñador de
Figura 3. Espacios de actividad y actividades
asociadas a la fase Ejecutar del proceso de
pruebas.
Figura 4. Productos de trabajo, alfas, y roles
asociado a la fase inicio del proceso ejecutar las
pruebas.
Conclusiones
Figura 4. Productos de trabajo, alfas, y roles
asociado a la fase inicio del proceso de planear las
pruebas.
Como una forma de validar que SEMAT se puede
constituir como una base comun para los
procesos de igeniería de software. El articulo
presenta los siguientes aportes:
Representación de la gestión de las pruebas de
software, utilizando elementos del nucleo de
SEMAT, lo que permite visualizar como estos
soportan y pueden representar esta fase de la
ingeniería de software.
Un conjunto de actividades y entregables propios
del proceso de pruebas de software que puede
ser representados por SEMAT, sin perder su
significado ni su funcion dentro de las pruebas de
software. Garantizando por parte del Analista la
calidad en los proyectos de software .
Referencias
International Organization for Standardization,
“ISO/IEC/IEEE 24765:2010 - Systems and software
engineering -- Vocabulary,” ISO/IEC/IEEE, 24765,
Dec. 2010.
ISO/IEC, ISO/IEC 29119, Software Testing Standard,
2008
Jacobson, I., Meyer, B., & Soley, R. (2010).
Software Engineering Method and Theory–A
Vision Statement. Semat Organization.
Jacobson, I., Ng, P. W., McMahon, P. E., Spence, I.,
& Lidman, S. (2013). The essence of software
Engineering: applying the SEMAT kernel.
Addison-Wesley.
Kasurinen, J. (2010, April). Elaborating software
test processes and strategies. In Software Testing,
Verification and Validation (ICST), 2010 Third
International Conference on (pp. 355-358). IEEE.
Tuya, J. (2009). El futuro estándar ISO/IEC
29119-Software Testing. REICIS. Revista Española
de Innovación, Calidad e Ingeniería del Software,
5(4), 33-35.
Zapata, C. M., Castro, L., & Vargas, F. A. (2014).
GBRAM from a SEMAT Perspective. METHODS,
MODELING, AND TEACHING, VOL. 3, 21.
Métricas de la norma ISO 9126: una representación basada en el
núcleo de SEMAT
Y.Y. Arenas, S. Carmona & C.M. Zapata
Universidad Nacional de Colombia, Medellín, Colombia
Resumen
La norma ISO 9126 es un estándar que
proporciona métricas de calidad de un producto
de software divididas principalmente en tres
partes: internas, externas y calidad en uso.[1]
Estas métricas se representan de distintas
maneras con el fin de expresarlas en un lenguaje
comprensible para un campo específico de la
ingeniería de software. Estas representaciones se
basan en lenguajes que no se centran en una
teoría consolidada de la ingeniería de software [2].
Un lenguaje común para este tipo de
representaciones debería tomar en consideración
los elementos básicos de la ingeniería de software
para permitir que la representación se pueda ligar
con otros elementos de la ingeniería de software.
Por ello, en este artículo se propone una
representación de las métricas de calidad de la
norma ISO 9126 tomando como base el núcleo de
SEMAT, que define esos elementos comunes.
Introducción
Uno de los retos actuales de los investigadores de
SEMAT consiste en representar una gran cantidad
de métodos, prácticas y actividades a una teoría
general, con una terminología común. Este reto es
de largo plazo, pero se basa en uno de los logros
actuales, como el reciente estándar “Esencia”, que
incluye un núcleo de elementos base para esta
representación. Las métricas de software no se
encuentran, al menos en principio, entre ese
grupo de elementos que se pueden representar
con el núcleo de SEMAT. Por ello, en este artículo
se propone el uso del núcleo de SEMAT para la
representación de las métricas de calidad de la
ISO 9126.
Aunque las métricas de calidad se vienen
trabajando de distintas maneras en terminologías
diversas como un lenguaje orientado a objetos,
diagramas o con fórmulas matemáticas
expresadas en términos y variables, en este
artículo se pretende la representación en un
lenguaje común, que permita involucrar estas
métricas dentro de un contexto general de un
esfuerzo de ingeniería de software. De esta forma,
se puede visualizar la forma de interacción de
estas métricas con otros elementos como
productos de trabajo, roles, estados de avance de
proyecto y fases de desarrollo, para así determinar
de forma clara y concisa qué son y cómo se
involucran en la disciplina las métricas de calidad.
Se tomaron en consideración múltiples aspectos
para poder encontrar una representación
adecuada. Por ejemplo, la ausencia de un símbolo
para la métrica en el núcleo de SEMAT y las
diferentes relaciones con los otros elementos,
además de los lineamientos previamente
establecidos para el núcleo de la esencia de
SEMAT, fueron aspectos iniciales que marcaron la
evolución de la representación. Se consideraron,
también, otros aspectos, como la sintaxis a la hora
de expresar elementos y conexiones, la
separación de intereses que se plantea como
ventaja principal del núcleo de SEMAT, el uso de
tarjetas de presentación de patrones y el lenguaje
textual que acompaña la especificación. Con base
en estos elementos, se logró la especificación de
las métricas de calidad en el núcleo de SEMAT al
interior de
un contexto completo de la
ingeniería de software, con sentido en sí mismo y
con una correcta conexión con otros elementos
que ya se manejan en la esencia.
Marco Teórico
Existe un nuevo estándar con el objetivo de
refundar una teoría de la ingeniería de software y
poder hacer de ella una verdadera disciplina, bajo
el argumento de que actualmente se estaba
obstaculizando con prácticas inmaduras que
incluían, entre otras, una gran variedad de
métodos en los que influían las modas del
momento. Este estándar, denominado “Esencia”,
se basa en un núcleo de elementos básicos y en
un lenguaje común que ayuda a centralizar los
conceptos que se incluyen en cualquier esfuerzo
de ingeniería de software [2].
Una consecuencia inicial del estándar es el
surgimiento de representaciones, especialmente
de métodos y prácticas de la ingeniería de
software, que toman como base el núcleo de la
esencia, definiendo una terminología común que
se basa en conceptos como alfas, estados y
productos
de
trabajo.
Se
busca
la
conceptualización de métodos específicos de la
ingeniería de software, pero tomando como base
las distintas prácticas que se incluían en ellos,
como la educción de requisitos o el desarrollo
dirigido por prácticas, por ejemplo.
Si bien el estándar de la esencia define un
conjunto de elementos básicos que hacen parte
de la totalidad de esfuerzos en ingeniería de
software, tales como los alfas, los productos de
trabajo, los espacios de actividad y las actividades,
también existen otros elementos que, aún siendo
comunes a muchos esfuerzos, aún no tienen una
representación definida. Las métricas de calidad
de software se incluyen en este grupo de
elementos.
Las métricas de calidad son indicadores para
medir las subcaracterísticas de un producto de
software, las cuales se ligan con características de
calidad (funcionalidad, confiabilidad, usabilidad,
mantenibilidad, portabilidad y eficiencia). Éstas, a
su vez, sirven para definir el modelo de calidad
con que una organización puede medir la calidad
de un producto de software.
La International Organization for Standarization
realizó un estándar internacional para la
evaluación de calidad del software, la norma
ISO-9126 que se divide en cuatro partes entre las
que se encuentran las métricas externas, internas
y de calidad en uso.
Antecedentes
Cuando se involucran métricas de calidad para
productos de software, ya sean o no de la norma
ISO 9126, se utilizan distintas notaciones para
representarlas, En esta Sección se examinan
algunas de ellas.
La notación en diagramas de flujo [3] se usa para
determinar los pasos necesarios para llegar hasta
la medida y su posterior interpretación.
Los lenguajes o estructuras textuales orientadas a
objetos [4] se emplean para hacer un intento por
describir las métricas de una manera cómoda y
accesible para personas con conocimientos de
estos lenguajes.
Usualmente, lo que se emplea es la notación
textual como se describen en la norma, esto es de
manera matemática y algebraica. Con base en esta
definición se pueden realizar operaciones para
obtener un valor numérico de la métrica [5].
Todas estas representaciones se usan de forma
específica para el fin que persiguen, de modo que
no existe una forma de correlacionarlas entre ellas
ni con los elementos que subyacen a cualquier
esfuerzo de ingeniería de software. La ausencia de
un terreno común genera como inconveniente la
dificultad de compartir la representación de las
métricas con otros elementos como las prácticas y
los métodos de desarrollo de software. Las
métricas de software no aparecen como uno de
los elementos fundamentales que se definen en el
núcleo de la esencia de SEMAT, aun cuando no es
posible encontrar un esfuerzo de desarrollo de
software en el cual no se mida la calidad del
sistema de software como tal. En efecto,
inicialmente se definieron elementos un poco más
específicos de la disciplina como “Las cosas con las
que se trabaja” o “Las cosas que se hacen” en
cualquier esfuerzo de ingeniería de software (y
que corresponden, respectivamente, a los alfas y
los espacios de actividad. Así, se pueden
representar con un lenguaje tanto textual como
gráfico cosas que son comunes para todas las
prácticas correspondientes a los esfuerzos de
ingeniería de software. El principal argumento
para la definición de estos elementos
fundamentales se basa en que, a pesar de la gran
cantidad de métodos, metodologías y prácticas, al
final todos buscan lo mismo y de alguna manera,
siguiendo los mismos lineamientos que se
interpretan de una manera general. Otros
conceptos como los estados de los alfas, las listas
de verificación, los productos de trabajo, las
actividades, los recursos y los patrones surgieron
de la necesidad de expresar diferentes elementos
de las prácticas y métodos. Sin embargo, la
pregunta de investigación que guía este artículo es
¿cómo expresar una métrica de calidad con base
en la definición que se incluye en la norma ISO
9126? ¿Esas métricas son de uso común en todos
los esfuerzos de ingeniería de software? [2].
SPEM (Software & Systems Process Engineering
Meta-Model) se usa para definir procesos de
desarrollo de sistemas de software con todos sus
componentes, buscando ser lo más minimalista
posible sin perder sentido sobre sí mismo. En
SPEM 2.0 [6] se expresan las métricas con un
símbolo gráfico que se muestra en la Figura 1.
Figura 1: Definición de métrica en SPEM
Fuente: Spem 2.0
Representación en el núcleo de
SEMAT de las métricas de la iso 9126
Para la elaboración de esta representación se
consideraron seis métricas de calidad obtenidas
de las normas ISO 9126, cada una representando
una de las características ofrecidas por ellos. Por
razones de espacio, para la presentación de los
resultados en este artículo se toma como caso de
estudio la métrica “Adecuación Funcional” que se
puede obtener en las normas previamente
descritas en la sección de Métricas externas, como
se muestra en la Figura 2. Esta métrica se basa en
una relación entre la cantidad de funciones del
software en las cuales se encontraron problemas
durante un periodo de prueba y la cantidad total
de funciones probadas.
Figura 2: Especificación de la métrica Adecuación Funcional, Fuente: Normas ISO 9126 [7]
Teniendo en cuenta que no existía para la métrica
un símbolo específico en el núcleo de la esencia,
se consideraron dos posibilidades: la creación de
un nuevo elemento en la sintaxis de SEMAT que
representara la métrica de calidad o la generación
de un nuevo patrón, cuya definición se ajusta de
una manera cercana a lo que que se requería. Se
optó por la creación de un nuevo tipo de patrón
llamado Metric.
Siendo un patrón, con una sintaxis y semántica
definida en el núcleo de la esencia, es necesario
establecer con qué elemento se podría ligar y
mediante cuál relación. Siendo el producto de
trabajo el documento donde reposa cierta
información relevante en el proceso de desarrollo
del software y que puede variar entre un código
fuente, un diagrama de clases, una especificación
de casos de uso, etc., y debido a que las métricas
de calidad realizan operaciones sobre lo que
reposa en diferentes productos de trabajo
(reporte de evaluación para el caso de estudio de
este artículo), se decidió unir el patrón metric con
el producto de trabajo bajo la relación “medir”
(measures en inglés) como se aprecia en la Figura
3.
Una vez definido el símbolo, con su sintaxis y su
semántica, hay que proporcionar un contexto
entendible por sí mismo para obtener mas
información no solo de la métrica sino del entorno
en el que se involucra, incluyendo su fase en el
desarrollo, las actividades a las que pertenece y
los alfas que involucra. De esta manera, se expresa
una métrica en un lenguaje que busca unificar
toda la disciplina de la ingeniería de software y se
enmarca en un contexto completo que da a
entender todos los factores, elementos y actores
involucrados en esta actividad de aplicación de
métricas de calidad. En la Figura 3 se aprecia el
alfa al cual la métrica pertenece, que para este
caso de estudio es el sistema de software.
También, se puede observar el producto de
trabajo que mide la métrica, denominado reporte
de evaluación. Se puede observar que también
hay
dos
patrones
que
representan
independientemente un rol (analista de calidad),
quien sería el que trabaja sobre el producto de
trabajo y la métrica.
La Figura 4 contiene el entorno de la métrica con
respecto a los espacios de actividad y la actividad
donde se enmarca el producto de trabajo al cual
se le aplica la métrica estudiada. El espacio de
actividad corresponde “probar el sistema” y la
actividad es “probar las funciones del sistema”
con una fase que se denomina “prueba funcional”.
Figura 3: Vista de alfas y productos de trabajo
Figura 4: Vista Patrones y espacios de actividad
En tarjeta del patrón se especifica la métrica con
respecto a la manera en que se debe aplicar y los
atributos del producto de trabajo sobre los cuales
trabajaría, para la obtención de un resultado que
daría un indicio de qué tan adecuado
funcionalmente está el sistema de software. Esta
tarjeta de presentación se usa ya para representar
la instancia específica de la métrica elegida, tal
como se muestra en la Figura 5, mientras que las
figuras anteriores contenían un visión un poco
más general de lo que estaba pasando en la
métrica y su contexto.
La modificación que sufrió esta especificación
respecto de la que reposa en la norma es la
manera de expresar la fórmula, ya que se debe
expresar de una manera más aproximada a la
estandarización que se busca. Por ello, se elige el
álgebra relacional para describir las operaciones
que se necesitan y, de esta manera, se involucra
en la definición textual del lenguaje, como se
muestra seguidamente:
Textual Specification
type Metric: It is a measure of the degree to which
a system, component, or process possesses a given
attribute.
pattern <Metric> FunctionalAdequation: Number
of functions that are suitable for performing the
specified tasks comparing to the number of
function evaluated.
{with EvaluationReport as measures;}
Figura 5: Tarjeta del patrón
En el lenguaje textual, aunque se definió todo el
contexto del entorno general, lo que compete a
las métricas es lo siguiente: se tuvo que crear un
nuevo tipo de entrada denominada “Metric” la
cual se asigna a un patrón que representa la
métrica de calidad. Finalmente a este patrón se le
asignó una relación hacia un Producto de Trabajo
ya que es este el que contiene la información
necesaria para obtener la medición.
Conclusiones y Trabajo Futuro
En este artículo se propuso una representación de
algunos indicadores de calidad de las métricas de
la norma ISO 9126 con el núcleo de la esencia de
SEMAT, obteniendo como resultado un patrón
denominado “métrica”. Este patrón tiene
características propias que permiten manejar un
producto de trabajo y sus características para
obtener un resultado de calidad del sistema de
software. La representación propuesta se puede
combinar con los diferentes elementos del núcleo
de la esencia, de forma tal que se puede
incorporar en el contexto de una práctica de
software.
Como trabajo futuro, se espera la definición de
otras relaciones de este patrón con los diferentes
elementos del núcleo de la esencia, para
complementar su semántica.
Referencias
[1]
Iso, “Information technology — Software product
quality,” Iso/Iec Fdis 9126-1, vol. 2000, pp. 1–26,
2000.
[2]
Omg, “Essence – Kernel and Language for Software
Engineering Methods,” no. August, p. 207, 2012.
[3]
M. D. De Andrade Alves, D. D. Fernandes, D. Á.
Montini, S. R. M. Pelegrino, P. M. Tasinaffo, and L. A.
V. Dias, “A methodology for assessment database
according to ISO 9126,” ITNG2010 - 7th Int. Conf. Inf.
Technol. New Gener., no. i, pp. 1137–1142, 2010.
[4]
Y. Fitrisia, “Implementation of ISO 9126-1 Quality
Model for Asset Inventory Information System by
Utilizing Object Oriented Metrics,” no. November, pp.
229–234, 2014.
[5]
A. Abran and R. E. Al-Qutaish, “ISO 9126: Analysis of
Quality Models and Measures,” Softw. Metrics Softw.
Metrol., pp. 205–228, 2010.
[6]
Omg, “Software & Systems Process Engineering
Meta-Model Specification V2.0,” no. April, p. 236,
2008.
[7]
S. Engineering, “N2419R,” no. 40, 2002.
Representación en el núcleo de Semat de la Interoperabilidad para
el Método de Desarrollo de Software del IGAC
C.E. Durango V., D.M. Torres R. y C.M. Zapata J.
Resumen
Los Sistemas de Información Geográfica (SIG) se
orientan a la solución de problemas en diversas
áreas del conocimiento, por medio de ubicaciones
geográficas. La interoperabilidad en SIG implica la
interacción a nivel funcional de las aplicaciones
para intercambiar información. Un método para el
desarrollo de aplicaciones SIG es el Método de
Desarrollo de Software IGAC (MDS-IGAC) que
cuenta con elementos para especificar los
requisitos no funcionales, entre los que se
encuentra
la
interacción.
Existe
una
representación Semat (Teoría y Método de la
Ingeniería de Software) del MDS-IGAC, que
identifica los productos de trabajo del método.
Estos productos de trabajo carecen de una
caracterización de la interoperabilidad en SIG,
respecto de los requisitos no funcionales. En este
artículo se propone una representación de los
requisitos no funcionales asociados con una nueva
práctica para mejorar la especificación de la
interoperabilidad en SIG, utilizando el núcleo de
Semat. Mediante esta solución, los analistas
identificarán los elementos que apoyan la
interoperabilidad en proyectos SIG.
Palabras clave. Sistemas de Información
geográfica, Interoperabilidad, Semat, Método de
Desarrollo
Introducción
Los Sistemas de Información Geográfica (SIG)
actúan en diversas áreas de conocimiento y
permiten la interdisciplinariedad de profesionales
para resolver problemas, agregando la ubicación
geográfica para analizar la información (Blišťan et
al. 2015).
La interoperabilidad en los SIG se relaciona con la
capacidad de comunicar los programas para
transferir datos. Su implementación requiere el
estudio del dominio de los SIG en la fase de
análisis, identificando tipos y modelos de datos y
herramientas que los apoyan (Zapata et al. 2012).
El Método de Desarrollo de Software IGAC
(MDS-IGAC) define requisitos no funcionales
basados en funcionalidad, usabilidad, fiabilidad y
desempeño. Para lograrlo, se utiliza el documento
de “Especificación de Requisitos”. El MDS-IGAC
cuenta con elementos para especificar los
requisitos no funcionales, entre los que se
encuentra la interacción (IGAC 2015).
Durango & Zapata (2015) representan con Semat
el MDS-IGAC. Los autores identifican los
elementos principales del MDS-IGAC asociados
con los elementos Semat en las fases de análisis y
viabilidad. La representación se concentra en
representar la práctica gestión de requisitos de
RUP asociando las fases, las actividades, los
artefactos y roles del MDS-IGAC con los espacios
de actividad, los productos de trabajo y roles de
Semat (Durango & Zapata, 2015). Sin embargo, la
práctica gestión de requisitos no abarca la
definición de interoperabilidad en los requisitos
no funcionales en los SIG.
En modelos como el de requisitos para atributos
de calidad (Brito et al. 2002), los requisitos
funcionales son propiedades deseables en el
sistema de software tratados como atributos de
calidad. El modelo propone un producto de
trabajo que sirve para especificar los atributos de
calidad. Sin embargo, este producto de trabajo no
hace parte de alguna práctica definida para la
especificación de los requisitos no funcionales y
no es específico de los SIG. Por esta razón,
requisitos como la interoperabilidad carecen de
una caracterización en los SIG.
Por lo anterior, en este artículo se propone una
representación de los requisitos no funcionales
asociados con una nueva práctica para mejorar la
especificación de la interoperabilidad en los SIG,
utilizando el núcleo de Semat. Mediante esta
solución, los analistas pueden identificar los
elementos que apoyan la interoperabilidad en los
proyectos SIG.
Marco Teórico
Sistemas de Información Geográfica
Son aplicaciones que contienen atributos
asociados con coordenadas geográficas. Los SIG
permiten estructurar la información en capas
geográficas para representar diferentes variables.
Además, mejoran la toma de decisiones y generan
nuevas oportunidades en las organizaciones para
ampliar el conocimiento específico por medio del
conocimiento geográfico (Blišťan et al. 2015).
una API; identificación de la estructura de las
fuentes de datos; identificación de las operaciones
soportadas; y finalmente, operación paso a paso
(Zapata et al. 2012).
SEMAT (Teoría y Método de la Ingeniería
de Software)
Semat propone una teoría solida con principios
probados y mejores prácticas para la ingeniería de
software. Semat posee un núcleo cuyos
elementos gráficos describen las características de
los esfuerzos de desarrollo de software (Véase la
Tabla 1, Zapata et al. 2014).
Tabla 1. Elementos del núcleo de Semat (Durango
& Zapata, 2015)
Elemento
Alfa
Interoperabilidad en SIG
La interoperabilidad es la capacidad de un sistema
de interactuar con otros sistemas específicos
(ISO-IEC 9126 2001). En el contexto de los SIG, los
requisitos de interoperabilidad se incrementan
debido a la necesidad de estos sistemas de
intercambiar datos y servicios provenientes de
diferentes instituciones a nivel local y mundial
(Laurini et al. 2002). A nivel de los datos, la
necesidad de interoperabilidad se refiere la
capacidad de almacenar y procesar grandes
cantidades de información heterogénea (Visser et
al. 2002, Zapata et al. 2012). Por otra parte, a
nivel de servicios esta necesidad se refiere al
proceso de ejecutar colectivamente las tareas de
visualización, análisis y manipulación de la
información geográfica (Sahin & Gumusay 2008).
Zapata et al. (2012) proponen un método para
integrar la interoperabilidad en los SIG desde la
fase de análisis. Este método contiene siete pasos
para identificar los elementos propios de los SIG
que interactúan: definición de la situación actual
de interoperabilidad; identificación de las fuentes
de datos soportadas; definición de formatos
aceptados; intercambio de datos por medio de
Actividad
Descripción
Describe las cosas que el equipo debe
administrar, producir y usar en el
proceso de desarrollo, mantenimiento y
soporte.
Define uno o más tipos de producto de
trabajo y uno o más tipos de tarea,
además de dar orientación sobre cómo
utilizarlos en el contexto de una práctica.
Práctica
Es un grupo de elementos necesarios del
núcleo de Semat para expresar la guía de
trabajo con un objetivo específico.
Patrón
Organiza los elementos del lenguaje en
estructuras significativas arbitrarias (e.g.,
fases y roles).
Es un artefacto de valor y relevancia para
el esfuerzo de la ingeniería de software.
Un producto de trabajo puede ser un
documento, una parte de software, una
prueba de software o la preparación de
un curso.
Producto de
trabajo
Antecedentes
El MDS-IGAC, paralelamente a los métodos de
desarrollo tradicionales, contiene un conjunto de
etapas de desarrollo de los SIG. El método
contiene un documento de especificación de
requisitos con productos de trabajo para
especificar los requisitos no funcionales, que son:
seguridad, conformidad, confiabilidad, usabilidad,
desempeño,
mantenibilidad,
integración,
integridad, visualización, operación, interacción,
lenguajes de programación, plataformas de
integración y portabilidad (IGAC, 2015). Sin
embargo, el método no contiene buenas prácticas
asociadas con la gestión de los requisitos no
funcionales, ni una caracterización de la
interoperabilidad.
Durango & Zapata (2015) proponen una
representación basada Rational Unified Process
(RUP) y en el núcleo de Semat del MDS-IGAC para
encontrar las especificaciones propias de los
métodos de desarrollo de SIG. La representación
propuesta asocia cinco de las seis buenas
prácticas de RUP e identifica los productos de
trabajo, actividades y recursos del método del
MDS-IGAC en comparación con el método
tradicional RUP (Durango & Zapata, 2015). Sin
embargo, aún se requiere la caracterización de los
requisitos no funcionales, específicamente con la
interoperabilidad en los SIG.
Brito et al. (2002) proponen un modelo para
identificar y especificar requisitos de atributos de
calidad, los cuales son propiedades que afectan el
sistema de software, comparables con los
requisitos no funcionales, los cuales son
transversales
y
afectan
simultáneamente
diferentes requisitos funcionales. El modelo
contiene la representación de los atributos de
calidad de acuerdo con un formato que contiene
elementos característicos que se integran en el
proceso de desarrollo en etapas tempranas (Brito
et al. 2002). A pesar de que los autores proponen
un formato para manejar los atributos de calidad
como la interoperabilidad, estos no se aplican
para el dominio de los SIG.
Solución
En el MDS-IGAC, igual que en los métodos de
desarrollo convencionales, los requisitos no
funcionales no se abordan mediante prácticas
definidas. Por esta razón, la trazabilidad de estos
requisitos se puede comprometer a lo largo del
ciclo de vida del SIG. Específicamente, no se tiene
una caracterización de la interoperabilidad
(referida como interacción en el MSD-IGAC), que
permita incluir en el proceso de desarrollo los
elementos esenciales que determinan la solución
de este aspecto del software. Por lo anterior, se
propone dividir la actual práctica “Gestión de
Requisitos” en dos nuevas prácticas “Gestión de
Requisitos Funcionales” y “Gestión de Requisitos
No Funcionales” (Véase la Fig. 1) para mejorar el
desarrollo de SIG y complementar las practicas
existentes.
Figura 1. Mejora de prácticas asociadas con el
MDS-IGAC
La propuesta se aplica a la práctica “Gestión de
Requisitos No Funcionales” específicamente para
el requisito de calidad Interoperabilidad. La
práctica “Gestión de Requisitos no Funcionales”
describe
la
educción,
organización,
documentación y mantenimiento de los requisitos
no funcionales, entendidos como propiedades
que afectan los SIG. La interoperabilidad en SIG es
un requisito no funcional transversal al proceso de
desarrollo, ya que está presente en la
especificación de los requisitos funcionales. Por
esta razón, es necesario identificar, especificar e
integrar la interoperabilidad como un requisito no
funcional en los SIG en etapas tempranas, así
como poder rastrear su evolución a lo largo de
ciclo de vida del SIG.
Las actividades que abarca la práctica de “Gestión
de Requisitos No Funcionales” se asocian,
esencialmente, con los espacios de actividad
“Comprender las Necesidades del interesado”,
“Comprender los requisitos” y “Darle forma al
Sistema” (Véase la Fig. 2). Estas actividades
sintetizan los procesos que siguen a la
recopilación de la información necesaria para
documentar los requisitos no funcionales
mediante el formato propuesto.
Figura 3. Producto de Trabajo de la Gestión de
Requisitos No Funcionales
En el formato propuesto (véase la Tabla 2) se
fusionan campos originales del formato MSD-IGAC
con otros del formato de Brito et al. (2002).
Algunos de estos campos son: Nombre,
Indeseable/Deseable, Descripción y Crítico. A su
vez, se introducen nuevos campos para completar
la especificación de requisitos no funcionales,
permitiendo la integración con los requisitos
funcionales y la validación y verificación durante el
proceso de desarrollo. Estos son: Descomposición,
Contribución y Requisitos funcionales.
Figura 2. Espacios de actividad y actividades de
Práctica Gestión de Requisitos No Funcionales
El MDS-IGAC cuenta con un formato para registrar
los requisitos no funcionales. En éste se consigna
información como: tipo de requisito, descripción
del requisito, criterios de aceptación y nombre,
entre otros. Al formato le falta detallar
características importantes de los requisitos no
funcionales como la interoperabilidad. Por lo
anterior, se propone una plantilla que permita
unificar los elementos del formato de requisitos
no funcionales del MDS-IGAC con los elementos
que proponen Brito et al. (2002) para identificar y
documentar los requisitos no funcionales. El
formato se propone como producto de trabajo del
alfa Requisitos (Véase la Fig. 3). El rol relacionado
con este artefacto es el Analista Funcional, debido
a que en la actual práctica del MSD-IGAC es quien
se encarga de recolectar la información en el
formato original.
Tabla 2. Propuesta de Plantilla de Requisitos no
Funcionales
El campo Descomposición describe el requisito no
funcional en términos de metas más pequeñas
(submetas), que: se pueden alcanzar, permiten
evaluar el estado de satisfacción y juntas
constituyen el objetivo original del requisito no
funcional. En el caso particular de la
interoperabilidad de los SIG, tres metas permiten
lograr el objetivo de interacción de los sistemas,
las cuales corresponden a la interoperabilidad en
los niveles: sintáctico, semántico y funcional. En el
nivel sintáctico las submetas abarcan los
esquemas de datos, es decir, la adopción de
estándares de bases de datos y datos geográficos.
En el nivel semántico las submetas se relacionan
con la interpretación de los modelos de
información. Por último, el nivel funcional de la
interoperabilidad contiene submetas orientadas al
intercambio de los datos mediante herramientas,
interfaces y protocolos. En la Figura 4 se presenta
una
versión
informal
del
grafo
de
interdependencias de submetas, conocido como
Softgoal Interdependency Graph, donde se
representan las submetas propuestas, como
resultado de una recopilación de las normas
internacionales, para lograr el objetivo de
interoperabilidad de los SIG.
Figura 4. Variación del Softgoal Interdependency
Graph para la interoperabilidad de SIG
Por otra parte, el campo Contribución aporta
información de aceptación, restricción o beneficio
del uso del requisito no funcional o sus submetas
con otro requisito no funcional. A su vez, el campo
Requisitos Funcionales proporciona un listado de
los requisitos que se integran con el requisito no
funcional en alguna de las tres relaciones:
sobreposición, superposición o encapsulación.
La interoperabilidad en SIG es una propiedad que
necesita un tratamiento específico, por ser un
requisito no funcional transversal a los requisitos
funcionales. Mediante la práctica y el formato
propuesto se completa el método MDS-IGAC con
la
información
necesaria
para
integrar
propiedades como la interoperabilidad, además
de soportar la toma de decisiones y rastrear la
satisfacción de dichas propiedades durante el
proceso de desarrollo.
Como trabajo futuro se propone integrar recursos
como las normas y los estándares internacionales
a la representación en el núcleo de Semat de las
prácticas. También, se pretende lograr una
caracterización más amplia de la interoperabilidad
en SIG para mejorar el grafo de interdependencias.
Por último es necesario conocer el resultado de
aplicar la práctica mediante un caso de estudio.
Referencias
Blišťan P., Ľudovít K., & Milana K. 2015. The Importance of
Geographic Information Systems Education at
Universities in the Process of Building a European
Knowledge-Based Society. Procedia - Social and
Behavioral
Sciences
191:2458–62.
Retrieved
(http://linkinghub.elsevier.com/retrieve/pii/S187704281
502618X).
Brito I., Moreira A. & Araújo J. 2002. A requirements model
for quality attributes. Aspect-Oriented Requirements
Engineering and Architecture Design, Germany.
Durango C. & Zapata C. En prensa. Una representación
basada en Semat y RUP para el Método de Desarrollo
SIG del Instituto Geográfico Agustín Codazzi. Revista
Ingenierías USBmed.
IGAC. 2015. Metodología de Desarrollo de Software IGAC.
Retrieved
July
24,
2015
(http://geoservice.igac.gov.co/mds/igac/).
ISO/IEEE 9126. 2001. Software Product Evaluation - Quality
Characteristics and Guidelines for their Use.
Laurini, R., Yetongnon, K. & Benslimane, D. 2002. GIS
interoperability,
from
problems
to
solutions. Encyclopedia of Life Support Systems.
Sahin K. & Gumusay, M. 2008. Service oriented architecture
(SOA) based web services for geographic information
systems. In XXIst ISPRS Congress. Beijing (pp. 625-630).
Visser, U., Stuckenschmidt, H. & Schlieder, C. 2002.
Interoperability
in
GIS-enabling
technologies.
In Proceedings of the fifth AGILE Conference on
Geographic Information Science (p. 291).
Zapata C., Arango R. & Jiménez L. 2014. Mejoramiento de la
Consistencia entre la Sintaxis Textual y Gráfica del
Lenguaje de Semat.” Prolibits (49):83–89.
Zapata C., Toro F. & Marín M. 2012. Definición de un Método
Basado en Patrones de Análisis para la Interoperabilidad
entre Sistemas de Información Geográfica. Revista
Escuela de Ingeniería de Antioquia (18):179–94.
Aspectos humanos en
el núcleo de SEMAT
Representación en el núcleo de Semat de las competencias de
Ingeniería Social necesarias para mejorar la Seguridad Informática
C. E. Durango V., M. J. Amariles C., J. C. Giraldo M., C. M. Zapata R., C. Díaz S.
Universidad de San Buenaventura, Medellín, Colombia
C. M. Zapata J.
Resumen
Las políticas de acceso a la información
disminuyen la interacción entre personas e
incrementan el uso de herramientas de
comunicación virtuales. La Ingeniería Social es el
acto de manipular personas, por medio del
engaño, para obtener “información de acceso”. La
seguridad informática se enfoca en proteger la
infraestructura
organizacional,
utilizando
estándares, protocolos y herramientas, entre
otros. Las competencias del atacante de ingeniería
social se desarrollan alrededor de los rasgos de
personalidad y del manejo de tecnologías. Semat
(Teoría y Método de la Ingeniería de Software)
incluye un núcleo de elementos aceptados y
comprobados de las buenas prácticas del
desarrollo de software, entre ellos las
competencias de los miembros del equipo de
pruebas de software. En este artículo se
representan las competencias del atacante de
Ingeniería Social utilizando el núcleo de Semat,
con el fin de mejorar las pruebas de seguridad
informática, evitar el acceso no autorizado a la
información y prevenir los ataques.
Palabras Clave. Ingeniería social, seguridad en la
informática, atacante, Semat, competencia.
Introducción
Las políticas de acceso y de uso de tecnologías
ayudan a promover el intercambio de información
y disminuir la interacción entre las personas
(CEPAL 2015). La información de las
organizaciones es vulnerable a individuos que
influyen sobre los usuarios y recursos de las
organizaciones.
La ingeniería social es la ciencia de interacción
social para persuadir a individuos u organizaciones
para obtener acceso a información no autorizada.
Para lograrlo, el atacante manipula a su víctima
utilizando recursos tecnológicos y psicológicos
(Krombholz et al. 2014, Samani 2015). La
seguridad informática es una disciplina que
identifica eventos inesperados que comprometan
los activos de las organizaciones. Para lograrlo,
cuenta con estrategias como estándares,
protocolos y herramientas, entre otros. Un ataque
informático consiste en aprovechar una
vulnerabilidad del software, hardware o de las
personas (atacante y víctima) que forman parte de
un ambiente informático (Cano 2004).
Una competencia organizacional es una
característica subyacente (rasgos de personalidad)
de un individuo que anticipa su comportamiento y
desempeño relacionado con un estándar de
efectividad de un trabajo o situación
(comportamientos observables, Alles 2005). Los
comportamientos observables del atacante de
ingeniería social se relacionan con el manejo de
tecnologías.
Semat (Teoría y Método de la Ingeniería de
Software) es una iniciativa que permite
representar, gráfica y textualmente, prácticas
comunes de métodos existentes mediante
elementos de su núcleo. Este núcleo incluye un
grupo de elementos esenciales universales para
todo esfuerzo de desarrollo de software (Zapata et
al. 2014, Jacobson et al., 2013). Las competencias
de Semat representan las habilidades claves que
se requieren para el desarrollo de software. Semat
define competencias de los miembros del equipo
de software (OMG 2014).
Las competencias del atacante que utiliza técnicas
de ingeniería social se desarrollan alrededor de
dos factores: humano (habilidad psicológica para
obtener información) y tecnológico (habilidad de
engañar al usuario haciéndole creer que está
interactuando con un sistema de información
“real”, Gulati 2003). Las pruebas de seguridad
informática se basan en el análisis de las
vulnerabilidades de los sistemas de información,
pero no tienen en cuenta las habilidades
psicológicas del atacante de ingeniería social para
extraer información a los usuarios. Por lo anterior,
es importante relacionar estas competencias del
atacante con las competencias organizaciones y
representarlas en el núcleo de Semat, para ayudar
a los equipo de pruebas de software a caracterizar
los atacantes, con el fin de evitar el acceso o
violación a la información en las organizaciones y
mejorar la seguridad informática.
Marco Teórico
ataques de ingeniería social son múltiples e
incluyen, principalmente, aspectos físicos, sociales
y técnicos (Krombholz et al. 2014).
Seguridad Informática
La Seguridad Informática considera un conjunto
de medidas que impiden la ejecución de
operaciones no autorizadas sobre un sistema o
red informática. Los efectos de esta inclusión
pueden conllevar daños a la información,
compromiso a su confidencialidad, autenticidad o
integridad, disminución del rendimiento de los
equipos o bloqueo del acceso de usuarios
autorizados al sistema (Smith 2013).
Competencias en Semat
Las competencias en Semat representan las
habilidades clave que se requieren para el
desarrollo de software. Semat define seis
competencias: representación del interesado,
análisis, desarrollo, pruebas, liderazgo y gestión,
agrupada en tres áreas de interés, que se centran
en aspectos específicos de la ingeniería de
software: clientes (verde), solución (amarillo) y
esfuerzo (azul, véase la Fig. 1, Zapata et al. 2014).
Ingeniería Social
Según la Comisión Económica para América Latina
y el Caribe (CEPAL), las tecnologías digitales
potencializan la mayoría de las actividades de la
sociedad, aumentando su importancia e impacto
en patrones de crecimiento económico, inclusión
social y sostenibilidad ambiental. Las políticas de
acceso y de uso de tecnologías ayudan a
incrementar el uso de herramientas tecnológicas
como Skype, correo electrónico y Lync, entre otros
(CEPAL 2015). La información de las
organizaciones es vulnerable a individuos que
influyen sobre los usuarios y recursos de las
organizaciones.
La ingeniería social es el arte de conseguir que
usuarios de sistemas informáticos pongan en
peligro la información de acceso. Los atacantes se
dirigen a usuarios (víctimas) manipulándolos para
que divulguen información confidencial. Los
Figura 1. Competencias del núcleo de Semat (Zapata et al. 2014)
Para participar en un equipo de desarrollo de
software, se requiere tener competencias en
diferentes áreas. Los miembros de los equipos de
trabajo requieren competencias específicas según
la tarea a realizar y competencias genéricas para
comprender las actividades de los otros miembros.
Una competencia que se propone en Semat es
“Pruebas”. Esta competencia se define como la
habilidad para verificar requisitos y la calidad del
software desarrollado (Jacobson et al. 2014).
Competencia Organizacional
Spencer y Spencer (1993) definen competencia
como “una característica subyacente de un
individuo que se relaciona causalmente con un
estándar de efectividad y/o rendimiento superior
en un trabajo o situación”. Los autores introducen
el modelo del iceberg (véase la Fig. 2). El modelo
plantea que el conocimiento y las habilidades de
las personas son competencias fáciles de observar
(visibles) y se desarrollan con capacitaciones,
mientras que las competencias relativas a las
motivaciones están escondidas (no visibles), se
relacionan con la personalidad y son difíciles de
evaluar (Spencer & Spencer 1993).
Antecedentes
Uebelacker y Quiel (2014) realizan una revisión de
literatura para identificar los rasgos de
personalidad que influyen en ataques de
ingeniería social, basándose en los principios de
Cialdini (reciprocidad, escasez, autoridad,
compromiso y coherencia, prueba social o
consenso, y simpatía) para categorizarlos. Para
ello, relacionan los rasgos de personalidad, según
el modelo de cinco factores (Big 5) y los principios
de influencia de Cialdini. Posteriormente,
construyen un enfoque denominado Marco de
Personalidad de ingeniería social con sus
respectivas denominaciones (véase la Fig. 3,
Uebelacker & Quiel 2014). El modelo relaciona
rasgos de personalidad de víctimas del atacante
de ingeniería social, pero falta identificar las
competencias del atacante para relacionarlas con
las competencias de un equipo de pruebas de
software.
Figura 2. Modelo del iceberg (Spencer & Spencer 1993)
Las competencias se pueden clasificar en
genéricas y específicas. Las competencias
genéricas se refieren a aquellos atributos o rasgos
distintivos que requiere un trabajador excepcional
en un puesto determinado, incluyendo
conocimientos, habilidades o actitudes necesarios
para desempeñar una tarea concreta. Las
competencias específicas son comportamientos
observables y habituales que posibilitan el éxito
de una persona en su función específica
(Casanova 2004). Para identificar estas últimas se
requiere aplicar pruebas psicotécnicas como la
prueba 16PF- 5. Esta prueba es producto de un
proceso investigativo que utiliza análisis factorial
para identificar dimensiones básicas o factores
para medir los rasgos de personalidad.
Figura 3. Marco de Personalidad de Ingeniería Social (Uebelacker &
Quiel 2014). Traducción de los autores
Krombholz et al. (2014) proponen una taxonomía
de los escenarios y características de los ataques
de ingeniería social enmarcada en tres categorías:
tipo (socio-técnico, técnico, físico y social),
operador (software y humano) y canal (correo
electrónico, mensaje instantáneo, teléfono, redes
sociales y nube, entre otros). La categoría
operador-humano se relaciona con la habilidad
psicológica para influenciar y persuadir a sus
víctimas para extraer información de acceso,
mientras que las otras categorías se relacionan
con habilidades tecnológicas (Krombholz et al.
2014). La taxonomía se basa en habilidades
tecnológicas, pero falta incluir las habilidades
psicológicas del atacante.
Competencias del atacante de
ingeniería social representadas en el
núcleo de SEMAT
El perfil de competencias del atacante de
ingeniería social se identifica con los rasgos de
personalidad, las destrezas y los conocimientos
(véase la Fig. 2). Los rasgos de personalidad se
identifican con la prueba 16PF-5 en un grupo de
personas dedicadas a actividades de ingeniería
social. Esta prueba reconoce los rasgos de
personalidad con terminología actual y entendible,
mediante adjetivos y descripciones de las
polaridades bajas (valores de 1 a 4), medias (valor
5) y altas (valores de 6 a 10). Los valores
acompañados del signo más (+) significan que se
espera que la persona obtenga dicho puntaje o
más, hasta llegar al máximo esperado. La persona
con perfil de atacante de ingeniería social tiene
alta tendencia en esos rasgos (véase la Tabla 1).
Para identificar las destrezas y conocimientos
Arráiz (2000) plantea competencias esenciales,
con niveles adecuados de conocimientos,
habilidades y conductas observables para un
desempeño aceptable y superior. Las destrezas y
conocimientos del atacante se relacionan a partir
de habilidades técnicas (phishing, pretexting,
baiting y quid pro quo, entre otros) y medios para
adquirir la información de su víctima (por ejemplo,
correo electrónico, face-to-face, teléfono y página
web, entre otros). Según lo anterior, en la Tabla 2
y la Figura 4 se identifican los descriptores propios
para las competencias genéricas y en la Tabla 3 y
la Figura 5 se identifican las competencias
específicas del atacante.
Tabla 1. Puntaje esperado para los 16 rasgos
primarios de personalidad de un atacante de
ingeniería social
Reservado
5
Abierto
Pensamiento concreto
6
Pensamiento abstracto
Inestabilidad emocional
8
Estabilidad emocional
Sumiso
9
Dominante
Prudente
4
Impulsivo
Despreocupado
2
Escrupuloso
Tímido
2
Espontáneo
Racional
4
Emocional
Confiado
7
Suspicaz
Práctico
4
Soñador
Sencillo
8+
Astuto
Seguro
4
Inseguro
Tradicionalista
7+
Innovador
Dependiente del grupo
3
Autosuficiente
Desinhibido
8+
Controlado
Tranquilo
8+
Tensionado
Baja ansiedad
8
Alta ansiedad
Introversión
5
Extraversión
Bajo control social
7+
Alto control social
Dependencia
8
Independencia
Apertura al cambio
7+
Mentalidad dura
Tabla 2. Competencias genéricas con descriptores del atacante de
ingeniería social
Nombre
Descriptores
Dominio
Manejo de redes, entrenamiento técnico y
tecnológico
tecnológico, conocimiento tecnológico, dominio
de software y búsquedas en redes
Trabajo
Formación de equipos y relación interpersonal
corporativo
Negociación
Dominio del negocio, adaptabilidad y liderazgo
Comunicación
Comunicación efectiva y asertiva, oratoria y
Estratégica
redacción
Pensamiento
Adaptabilidad, innovación, retrospección y
sistémico
procesamiento paralelo
Flexibilidad
Proactividad, adaptabilidad, apertura y
creatividad
Tabla 3. Competencias específicas con sus descriptores del
atacante de ingeniería social
Nombre
Descriptores
Solución de
Iniciativa, proactividad y toma de decisiones
Problemas
Seguimiento y
Acompañamiento, profundización, validación,
control
evaluación y mejoramiento
Capacidad de
Persuasión, convencimiento, empatía,
influenciar
credibilidad y confianza
Capacidad de
Agilidad, oposición, exigencia y procesamiento
respuesta
paralelo
encuentran en personas que se enfocan en
tareas específicas que necesitan un esfuerzo
de ingeniería de software particular, como
verificar los requisitos y la calidad del software
desarrollado.
Figura 4. Representación de las competencias genéricas del
atacante de ingeniería social en el núcleo de Semat
Figura 5. Representación de las competencias específicas del
atacante de ingeniería social en el núcleo de Semat
El uso del núcleo de Semat apoya la normalización
de la ingeniería de software. Un campo poco
explorado de Semat es la definición de
competencias que pueden hacer parte del núcleo.
En la representación en el núcleo de Semat de las
competencias del atacante de ingeniería social se
observa lo siguiente:
 Las organizaciones y los equipos de trabajo de
ingeniería de software poco conocen de la
definición de competencia organizacional y su
relación con los esfuerzos de ingeniería de
software.
 Para Semat una competencia se basa en la
caracterización de un rol en lugar de relacionar
las habilidades de la persona.
 Las competencias genéricas, en general, se
encuentran en personas que forman un
equipo de trabajo de desarrollo de software.
 Las competencias específicas, en general, se
Como conclusión general, se observa que la
representación de las competencias del atacante
de ingeniería social en el núcleo de Semat ayudará
a organizaciones y equipos de desarrollo de
software
a
seleccionar
personas
con
conocimientos, habilidades y rasgos de
personalidad con alto desempeño para mejorar
las pruebas de seguridad informática y evitar
accesos a la información.
Como línea de trabajo futuro, se plantea la
identificación de las prácticas correspondientes a
los atacantes de ingeniería social, de forma tal que
se puedan representar sus actividades, productos
de trabajo, patrones y recursos en términos de los
alfas y los espacios de actividad característicos de
la ingeniería de software. Estas prácticas, siendo
negativas, se podrían estudiar cuidadosamente
para mejorar las vulnerabilidades que puedan
presentar los esfuerzos de ingeniería de software
ante fallos de tipo humano en el acceso a la
información.
Referencias
Alles, M., 2005. Diccionario de comportamientos:
gestión por competencias, Argentina:
Ediciones Granica S.A.
Arráiz, J.I., 2000. Retribución y competencias:
¿Cómo garantizar su éxito? Capital Humano,
133, pp.6–8.
Cano, J.J., 2004. Inseguridad informática: un
concepto dual en seguridad informática.
Revista de Ingeniería, (19), pp.40–44.
Casanova, F., 2004. Desarrollo local, tejidos
productivos
y
formación.Abordajes
Alternativos para la Formación y el Trabajo
de los Jóvenes, Montevideo.
CEPAL, 2015. La nueva revolución digital, Santiago,
Chile.
Gulati, R., 2003. The threat of Social Engineering
and your defense against it, Knoxville,
Tennessee.
Jacobson, I. et al., 2014. La esencia de la
Ingeniería de Software: Aplicando el núcleo
de Semat Nueva Libr., Buenos Aires,
Argentina.
Jacobson, I., Ng, P. & Mcmahon, P.E., 2013. La
Esencia de la Ingeniería de Software: El
Núcleo de Semat. Revista Latinoamericana
de Ingeniería de Software, 1(3), pp.71–78.
Krombholz, K. et al., 2014. Advanced social
engineering attacks. Journal of Information
Security and Applications, pp.1–10.
OMG, 2014. Kernel and Language for Software
Engineering Methods (Essence) Version 1.0,
Available
at:
http://www.omg.org/spec/Essence/1.0/.
Samani, R., 2015. Hacking the Human Operating
System: The role of social engineering within
cybersecurity, Santa Clara, CE.
Smith, R., 2013. Elementary Information Security
Jones & Ba., United States of America.
Spencer, L.M. & Spencer, S.M., 1993. Competence
at work John Wiley., New York.
Uebelacker, S. & Quiel, S., 2014. The Social
Engineering Personality Framework. In 4th
workshop on Socio-Technical aspects in
security and trust. pp. 1–14.
Zapata, C.M., Giraldo, G.L. & Jiménez, L.D., 2014.
Ontological Representation of the Graphical
Language of Semat. IEEE, pp.1–6.
Una extensión del núcleo de SEMAT para la representación de
prácticas de enseñanza de sistemas embebidos
R.D. Sánchez, A.A. Barón & M.C. Gómez.
Grupos de Investigación en Lenguajes Computacionales, Universidad Nacional de Colombia, Medellín,
Colombia.
Introducción
En la actualidad existe una creciente demanda de
productos que contienen sistemas embebidos
(Ordóñez, 2005), lo cual
se traduce en un
incremento en la demanda de ingenieros que
implementen este tipo de sistemas con altos
estándares de calidad. Estos ingenieros deben
contar con conocimientos técnicos y habilidades
blandas como negociación, trabajo en equipo y
comunicación efectiva. Sin embargo, las
instituciones de educación superior han orientado
la enseñanza de sistemas embebidos a partir de la
presentación de contenidos y no del desarrollo de
competencias (Chenard, Zilic, & Prokic, 2008).
Tradicionalmente, la implementación de sistemas
embebidos se ha enseñado mediante dos
estrategias de enseñanza- aprendizaje: a) clases
magistrales y b) prácticas de laboratorio
(Prikladnicki et al., 2013). En las clases magistrales
el docente es el encargado de presentar a los
alumnos los conceptos fundamentales de una
temática. En el caso de las prácticas de laboratorio
se realiza una simulación de un proyecto con los
conceptos adquiridos. Sin embargo, ninguna de
las dos estrategias garantiza el desarrollo de las
competencias requeridas por los ingenieros de
tipo técnico y social (habilidades blandas).
El presente es un trabajo en progreso donde se
propone una metodología de extensión del núcleo
de Semat a otros dominios disciplinares (Object
Managment Group, 2014). Los autores plantean
una extensión para representar prácticas de
enseñanza de sistemas embebidos (PESE) que
faciliten el seguimiento al desarrollo de
competencias. Se identificaron nuevos alfas,
estados, un espacio de actividad y productos de
trabajo. La propuesta parte del trabajo presentado
en (Zapata-Jaramillo, 2014), donde se determina
que el núcleo de Semat cumple con la definición
de una teoría contando con constructos y
proposiciones.
Marco Teórico
Sistemas Embebidos
La tecnología de los sistemas embebidos (SE) se
encuentra extendida en industrias como la de
automóviles,
dispositivos
móviles,
de
automatización industrial, equipos de redes y
electrodomésticos. (Mitsui, Kambe, & Koizumi,
2009; Ordóñez, 2012). Un sistema embebido es un
computador con propósito particular constituido
por software y hardware. Los ingenieros los
diseñan con los recursos computacionales
estrictos a las funcionalidades de su propósito,
teniendo restricciones como el tiempo de
respuesta, memoria y número de entradas y
salidas. Su diseño involucra diferentes niveles de
abstracción y enfoques de desarrollo: a) a nivel de
sistema, b) a nivel de componentes software y
hardware, y c) a nivel de integración de software y
hardware (Mitsui et al., 2009).
Concepto de Práctica
El concepto de práctica es común en el contexto
de la ingeniería de software pero los autores le
asocian diferentes definiciones y estructuras
(Barón & Anaya, 2012) (Garcia, Martin, Urbanoi, &
De Amescua, 2012) (Passos, Cruzes, Dyba, &
Mendonca, 2012).Para efectos del presente
trabajo se referencia el concepto de práctica
presentado por el OMG (Object Management
Group) en el estándar Kernel and Language for
Software Engineering Methods (Essence). La
práctica se define como una aproximación
repetible para realizar un propósito específico.
Una práctica provee una manera sistemática y
verificable de abordar un aspecto particular de un
trabajo. La práctica tiene un objetivo claro
expresado en términos de los resultados que
permite su aplicación. Proporciona una guía para
ayudar y orientar a los profesionales en lo que se
debe hacer para lograr el objetivo, para asegurar
que el objetivo se entiende y para verificar que se
logra (Object Managment Group, 2014).
Estrategias de Enseñanza
Las estrategias de enseñanza hacen referencia a
todos los recursos y procedimientos utilizados por
el docente para generar aprendizaje significativo
en sus estudiantes (Férez, 2005). Este aprendizaje
significativo se logra en la medida que se siga un
proceso sistemático de planeación, diseño,
implementación y evaluación de las actividades de
enseñanza que componen una estrategia de
enseñanza.
Las estrategias de enseñanza deben ser diseñadas
de tal manera que estimulen a los estudiantes a
observar, analizar, sintetizar, formular hipótesis,
resolver problemas, es decir, a descubrir
conocimiento por sí mismos. De esta manera, el
estudiante se convierte en el actor principal de su
proceso de aprendizaje y el docente es sólo un
guía o facilitador de dicho proceso.
Antecedentes
Existen diferentes propuestas para abordar un
curso de sistemas embebidos a nivel universitario.
En la presente sección se describen algunas de las
más relevantes respecto a la utilización de
prácticas de enseñanza diferentes a las
tradicionales como son la clase magistral o las
prácticas de laboratorio.
Chedard y otros proponen una metodología de
enseñanza de sistemas embebidos basada en un
proceso de aprendizaje colaborativo, orientado
por
proyectos
y
centrado
en
el
estudiante(Chedard, et al, 2008). Bareno (2011)
presenta un programa que consta de tres cursos
donde se usa exclusivamente plataformas de
software y hardware libre para el desarrollo de
sistemas embebidos. Mitsui y otros proponen un
conjunto de experimentos para enseñar la
implementación
de
sistemas
embebidos
diferenciando competencias relacionadas con: a)
diseño de sistemas, b) diseño de software y c)
diseño de hardware modular (Mitsui et al., 2009).
De manera similar Rover y otros presentan un
conjunto de cursos de sistemas embebidos donde
se incorporan nuevas tecnologías, objetivos de
aprendizaje,
laboratorios
de
aprendizaje,
repositorio de lecciones aprendidas y un modelo
de enseñanza basado en la taxonomía de Bloom
(Rover et al.,2008). Jaimeson (2010) diseña un
curso de sistemas embebidos fundamentado en el
aprendizaje basado en proyectos que se apoya en
Arduino
como
plataforma
abierta
de
implementación de estos sistemas. Fan y otros
describen varias prácticas de enseñanza de
sistemas embebidos como formación de grupos
de interés y aplicación de concursos para
promover el aprendizaje (Fan et al, 2013).
Nooshabadi y Garside plantean un proyecto para
diseñar un curso de sistemas embebidos
modernos con el propósito proveer un ambiente
de aprendizaje que replique las prácticas
industriales de implementación de sistemas
embebidos (Nooshabadi & Garside, 2006).
Una vez revisadas estas propuestas se elaboró un
esquema preconceptual para cada una, con el
objetivo de identificar los constructos y
proposiciones más importantes de las diferentes
prácticas de enseñanza de sistemas embebidos.
En la figura 1 se presenta el esquema
preconceptual para la propuesta de los autores
Nooshabadi y Garside (2006).
realizados mediante la revisión sistemática de
literatura y la representación de las propuestas de
los artículos con esquemas preconceptuales (EP)
(Zapata-Jaramillo, Gelbukh, & Arango-Isaza, 2006).
c) proveer una explicación para justificar la teoría,
realizado
mediante
la
homologación
terminológica de los conceptos de los EP. El cuarto
paso d) determinar el alcance de la teoría, se
aborda al definir unos criterios para la extensión
del núcleo de Semat. Por último, e) probar la
teoría mediante estudios empíricos, se plantea
mediante la aplicación empírica del modelo de
extensión propuesto.
Identificación y explicación de constructos y
proposiciones.
Figura 1. Esquema preconceptual que sintetiza la
propuesta de enseñanza de sistemas embebidos
de Nooshabadi y Garside (2006)
Propuesta
Metodología
La “finalidad esencial de un artículo científico es
comunicar los resultados de investigaciones, ideas
y debates de una manera clara, concisa y
fidedigna” (Martinson, 1983). Los artículos son el
medio de divulgación a la comunidad científica de
la descripción de un dominio disciplinar
(Artiles-Visbal, 1995). De acuerdo a esto los
autores proponen dos premisas: a) existe un
conjunto de constructos y proposiciones
esenciales y comunes a todas las PESE; b) estos
constructos y proposiciones pueden ser
descubiertos en un subconjunto finito de artículos
disponibles en la literatura.
El presente trabajo sigue la metodología
presentada por Sjøberg, Dybå, Anda y Hannay
(2008) a saber: a) definir los constructos de la
teoría, b) definir las proposiciones de la teoría,
Se realizó una búsqueda sistemática de la
bibliografía haciendo uso del metabuscador de
Google Scholar. La cadena de búsqueda usada fue:
((teach or teaching) AND "embedded system"). La
búsqueda arroja 5140 resultados. El criterio de
inclusión utilizado fue la pertinencia a
investigaciones de enseñanza de sistemas
embebidos que contienen como mínimo: a)
conceptos, b) acciones, c) competencias, d)
enfoques y/o propuesta de enseñanza y e)
recursos de enseñanza. Por tratarse de un
ejercicio piloto sólo se revisaron los primeros 100
artículos resultado de la búsqueda, por tanto, el
criterio de exclusión consistió en aparecer en la
posición 101 en adelante. Los autores leyeron
veintiocho artículos que cumplieron con los
criterios. De estos artículos se escogieron doce
para ser analizados y representados mediante EP.
A partir de los conceptos de los EP se estableció la
homologación terminológica.
Alcance del modelo de extensión propuesto
A partir de la homologación terminológica
surgieron los constructos y proposiciones mínimos
aplicando los siguientes criterios: a) extensión al
núcleo de Semat, tomándolo como medio de
representación de las PESE al agregarle
extensiones necesarias para la representación del
nuevo dominio. b) Ortogonalidad de los
constructos, estableciendo si un concepto
corresponde a un constructo representado como
un Alfa (Ortogonal) o un sub-alfa (no ortogonal). Si
el constructo siempre está presente y es
independiente a los alfas del núcleo, se dice que
es ortogonal, si no se identifica como un sub alfa o
producto de trabajo. De forma similar se definen
las extensiones de los espacios de actividad. c)
Generalidad, las extensiones al núcleo propuestas
(constructos, proposiciones y definiciones) son
comunes a cualquier PESE y deben ser las mínimas
con las cuales se puede representar cualquier
PESE. d) Establecimiento de estados y listas de
verificación de los alfas, se logran por analogía con
los estados existentes en el núcleo de Semat y del
análisis de los EP.
estudio al "sistema embebido" y delimita el
"trabajo" de enseñanza-aprendizaje. A su vez, el
"equipo" se involucra en el ambiente te de
aprendizaje. En cuanto a los espacios de actividad
se agrega uno denominado “realizar actividades
de aprendizaje”, en el área de interés “esfuerzo”.
El resto de espacios de actividad del núcleo de
Semat cubren las necesidades de las PESE.
Además se identificaron los productos de trabajo
y los estados y las listas de verificación de los alfas
propuestos. En la figura 2 se muestra las
relaciones de los alfas con la extensión propuesta,
y en la figura 3 el alfa de “sistema embebido” sus
sub-alfas, con el espacio de actividad propuesto.
Aplicación empírica del modelo de extensión
El enfoque de validación escogido es la
verificación pragmática a través de la
representación exitosa de PESE diferentes a las
utilizadas para generar la extensión. La validación
se deja planteada y consiste en el uso de núcleo y
la extensión para representar un conjunto de
PESE.
Resultados
La presente propuesta es un trabajo en progreso.
En este apartado presentamos los resultados
parciales en el contexto del núcleo de Semat
como medio de representación de las PESE. Así,
de las áreas de interés del núcleo esta propuesta
utiliza “solución” y “esfuerzo” en el proceso
enseñanza-aprendizaje. En PESE el área de
“cliente” se utiliza cuando los estudiantes
desarrollan proyectos o laboratorios de SE.
Para la propuesta se plantea una excepción al
núcleo: El alfa sistema software se establece como
un constructo perteneciente a uno más general
denominado sistema embebido; que además
contiene a otro constructo denominado sistema
hardware. El alfa sistema embebido remplaza a
sistema software en cuanto a sus relaciones con
los demás alfas. Además, se propone un nuevo
alfa denominado ambiente de aprendizaje. El
ambiente de aprendizaje tiene como objeto de
Figura 2. Alfas del núcleo con las extensiones
propuestas.
Figura 3. Sub Alfa sistema embebido y espacio de
actividad propuesto.
Las prácticas son compuestas como se plantea en
el estándar del núcleo de Semat haciendo uso de
las extensiones planteadas para abordar el
dominio de enseñanza de sistemas embebidos.
Definición de la estructura de la práctica
A partir del análisis de propuestas de enseñanza
de sistemas embebidos, se identifican los
elementos comunes y diferenciales para producir
una definición que concilia los diferentes enfoques.
Esta definición es presentada en la figura 4.
Conclusiones
En este trabajo se pone a consideración de la
comunidad académica una metodología para
extender el núcleo de Semat. Se logró un
prototipo de extensión del núcleo, a partir de un
conjunto limitado de fuentes bibliográficas del
universo de prácticas disponibles para la
enseñanza de sistemas embebidos. En el ejercicio
se identifica que los constructos y proposiciones
del núcleo de Semat son lo suficientemente
generales y permiten la representación del nuevo
dominio con la adición de unas pocas extensiones.
Además, los nuevos constructos y proposiciones
de la extensión propuesta se encuentran en el
resto de los veintiocho artículos analizados. Como
trabajo futuro se plantea la validación empírica de
la extensión mediante la representación de
nuevas prácticas de enseñanza disponibles en la
literatura.
Figura 4. Esquema preconceptual de la práctica de
enseñanza de sistemas embebidos
REFERENCIAS
Artiles-Visbal, L. 1995. El artículo científico. Revista cubana
de Medicina General Integral 11(4): 387–394. Retrieved
from
http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S0
864-21251995000400015
Bareno, C. 2011. Teching/Learning Methods for Embedded
Systems Using Copyleft Hardware. Latin America
Transactions 9(4): 503-509.
Barón, A. & Anaya, R. 2012. Pegaso: Una propuesta para la
gestión de activos de software. Tesis de maestría.
Universidad Eafit, Medellín, Colombia.
Chenard, J. Zilic, Z. & Prokic, M. 2008. A laboratory setup
and teaching methodology for wireless and mobile
embedded systems. IEEE Transactions on Education 51(3):
378-384.
Fan, S. Liu, J. & Zhao, Y. 2013. Investigate on the Teaching
Method for the Course “Embedded System”. Creative
Education 3(07).
Férez, P.E.G.2005. Un acercamiento al trabajo colaborativo.
Revista Iberoamericana de Educación, 35(2).
García Guzmán, J. Martin, D. Urbano, J. & Amescua, A. 2013.
Práctical experiences in modelling software engineering
practices: The project patterns approach. Software
Quality
Journal
21(2):
325–354.
doi:10.1007/s11219-012-9177-8.
Jamieson, P. 2010. Arduino for teaching embedded systems:
are computer scientists and engineering educators
missing the boat. Proc. FECS: 289-294.
Kundert, K. & Chang, H. 2010. Model-based functional
verification. In Design Automation Conference (DAC),
2010 47th ACM/IEEE, IEEE.
Martinson, A. 1983. Guía para la redacción de artículos
científicos destinados a la publicación. Paris: UNESCO.
Retrieved
from
http://unesdoc.unesco.org/images/0005/000557/05577
8SB.pdf.
Mitsui, H. Kambe, H. & Koizumi, H. 2009. Use of Student
Experiments for Teaching Embedded Software
Development Including HW/SW Co-Design. IEEE
Transactions on Education 52(3): 436-443.
Nooshabadi, S. & Garside, J. 2006. Modernization of
teaching in embedded systems design-an international
collaborative
project.
IEEE
Transactions
on
Education 49(2): 254-262.
Object Managment Group. 2014. Kernel and Language for
Software Engineering Methods (Essence). Retrieved from
http://wwon w.omg.org/spec/Essence/1.0.
Ordóñez, S. 2005. Empresas y cadenas de valor en la
industria electrónica en México. Economía UNAM 2(5):
90–111.
Ordóñez, S. 2012. Nuevos determinantes del desarrollo y el
sector
electrónico-informático
y
de
las
telecomunicaciones en México. Comercio Exterior 62(4):
37–55.
Retrieved
from
http://revistas.bancomext.gob.mx/rce/sp/index_rev.jsp?i
d Revista=142.
Passos, C. Cruzes, D. S. Dyba, T. & Mendonca, M. 2012.
Challenges of applying ethnography to study software
practices. Proceedings of the 2012 ACM-IEEE
International Symposium on Empirical Software
Engineering & Measurement.
Prikladnicki, R. Dittrich, Y. Sharp, H. Souza, C. D. Cataldo, M.
& Hoda, R. 2013. Cooperative and human aspects of
software engineering: CHASE 2013. SIGSOFT Softw. Eng.
Notes 38(5): 34–37.
Rover, D.T. Mercado, R. Zhang, Z. Shelley, M.C. & Helvick, D.S.
2008. Reflections on teaching and learning in an
advanced undergraduate course in embedded systems.
IEEE Transactions on Education 51(3): 400-412.
Sjøberg, D. I. Dybå, T. Anda, B. C. & Hannay, J. E. 2008.
Building theories in software engineering. In Guide to
advanced empirical software engineering: 312–336.
Retrieved
from
http://link.springer.com/chapter/10.1007/978-1-84800-0
44-5_12.
Zapata-Jaramillo, C. 2014. An executable pre-conceptual
schema for a software engineering general theory.
Centro Editorial de la Facultad de Minas (ed). In Software
Engineering: Methods, Modeling: 3–7.
Zapata-Jaramillo, C., Gelbukh, A., & Arango-Isaza, F. 2006.
Pre-conceptual
schema:
A
conceptual-graph-like
knowledge representation for re-quirements elicitation.
In MICAI 2006: Advances in Artificial Intelligence (pp.
27–37).
Springer.
Retrieved
from
http://link.springer.com/chapter/10.1007/11925231_3
Retos en la enseñanza del Núcleo SEMAT a estudiantes de ciclos
propedéuticos de Ingeniería de Sistemas en Colombia
M.E. González & M.A. Becerra
Institución Universitaria Salazar y Herrera, Medellín, Colombia
http://www.iush.edu.co/
manera temprana fuertes amenazas a la validez.
Introducción
El Núcleo SEMAT en la educación
Ciclos propedéuticos en Colombia
Una de las mejores explicaciones del Núcleo
SEMAT (Software Engineering Methods and
Theory) como la Esencia de la Ingeniería de
Software, se encuentra concreta y concisa en el
trabajo de
(Jacobson, y otros, 2013), allí se
explica cómo el Núcleo será el consolidado de las
mejores prácticas de la Ingeniería de Software,
con soportes teóricos sólidos que argumenten la
elección y puesta en práctica de cada actividad, rol,
artefacto, y demás elementos involucrados en el
desarrollo de software de calidad, y las
consecuentes ventajas de su aplicación.
Al respecto (Ng & Huang, 2013), muestran como
una de las ventajas de SEMAT es servir de puente
entre la industria, la educación y la investigación,
ya que permite exponer a los estudiantes
universitarios los conceptos que el docente
considere más importantes de diversos métodos y
enfoques de desarrollo de software, todo esto
bajo la premisa de que SEMAT permite visualizar
la pletórica diversidad de la Ingeniería de Software,
sin perder de vista uno de sus objetivos
principales, el cual es optimizar el desarrollo
eficiente de software de calidad; en este mismo
sentido, se encuentran los análisis desarrollados
por (Ibargüengoitia & Oktaba, 2014) los cuales
indican que la aplicación de la Esencia en
ambientes educativos en Instituciones de
Educación Superior (IES) permite detectar de
“Los ciclos son unidades interdependientes,
complementarias y secuenciales, un ciclo
propedéutico se puede definir como una fase de
la educación que le permite al estudiante
desarrollarse en su formación profesional
siguiendo sus intereses y capacidades”, (Colombia,
2009)
De acuerdo con (Pérez Gama, Pérez Gutiérrez, &
Hoyos Gómez, 2011) en años anteriores en
Colombia, se consideraba a las carreras técnicas y
tecnológicas como ciclos cerrados y concluyentes,
que no ofrecían a sus egresados la posibilidad de
moverse hacia niveles profesionales; esto llevó a
dichos programas a una situación discriminada,
por considerarse de menor expectativa
profesional.
Luego el gobierno decretó a través del Ministerio
de Educación Nacional (MEN) el concepto de
Ciclos Propedéuticos para las áreas de ingenierías,
la tecnología de la información y la administración
a través de la ley 749 de 2002, con diversas
argumentaciones como ampliar la cobertura
educativa, o que los estudiantes sólo requieren
SABER y SABER HACER; sin embargo, se han
observado algunas afectaciones negativas a la
calidad de la educación superior, producidas por la
implementación de dichos ciclos. Estas falencias
se evidencia aún antes de que los estudiantes
culminen las carreras profesionales, en el caso
puntual de este trabajo, para la carrera de
Ingeniería de Sistemas; cuando en la misma aula
de clase confluyen estudiantes que tienen
titulaciones previas en Técnicas o Tecnologías
afines con informática, y estudiantes que no
tienen ese tipo de formaciones preliminares.
Tipificación de estudiantes
Es usual que bajo el modelo de ciclos
propedéuticos, confluyan en las aulas de clase de
educación superior, estudiantes con formación
previa en carreras técnicas o tecnológicas
relacionadas
con
sistemas
informáticos,
estudiantes que laboran en áreas tecnológicas de
algunas compañías, y estudiantes cuya única
formación previa es el bachillerato; bajo esta
circunstancia se identifican dos perfiles
estudiantiles: los que hacen uso del ciclo
propedéutico propiamente dicho, y los
estudiantes “regulares” sin titulaciones previas en
áreas informáticas.
Posibles situaciones problemáticas con
estudiantes titulados
Usualmente se trata de estudiantes que laboran, y
asisten a clases únicamente en horarios extremos,
lo que implica que al llegar al aula de clase
usualmente se encuentran apurados por salir si es
en el horario de la mañana, o extenuados física y
mentalmente si es en el horario de la noche;
adicionalmente sus intereses prioritarios no
siempre son adquirir nuevos conocimientos
teóricos, si no , nuevos conocimientos prácticos
que puedan ser evidenciados con prontitud en sus
lugares de trabajo para aspirar a un ascenso o a
una mejora salarial; para este grupo de
estudiantes el núcleo SEMAT resulta interesante
para su utilización, toda vez que les ahorra tiempo
en el momento de aplicar las metodologías con las
que – muchas veces – lidian a diario, sin embargo,
se muestran mucho más interesados en la
utilización del núcleo que en la construcción del
mismo.
Estudiantes sin titulaciones tecnológicas
previas
Este grupo de estudiantes muestra prácticamente
el mismo interés por las informaciones teóricas y
por las especificaciones prácticas y aplicativas.
Este comportamiento generalizado, puede
implicar que se consideren los más apropiados
para ayudar a la construcción de los cimientos
teóricos del Núcleo, toda vez que aunque no
tienen mucha experiencia en la aplicación de
metodologías (algunas veces ninguna experiencia),
cuentan con el tiempo y el interés necesarios para
apoyar grupos de investigación o semilleros que
se puedan agrupar en torno a la temática de
interés; cosa que no ocurre con los “estudiantes
de medio tiempo” del primer grupo.
Calidad de la educación
Según se desprende de la información
proporcionada por (Pérez Gama, Pérez Gutiérrez,
& Hoyos Gómez, 2011) una de las ventajas de la
educación por ciclos propedéuticos es que “El
grado intermedio enriquece el logro profesional y
la experiencia.”, sin embargo es precisamente esa
experiencia la que es necesario aprender a
manejar en el aula de clase, para evitar caer en
uno de los dos extremos evidentes; de un lado la
idea de que la fundamentación teórica es más
importante que la práctica, confluyendo esto a
ensanchar la brecha existente entre la industria y
la academia, toda vez que la industria requiere
personal para el hacer, no sólo para el saber; de
otro lado, se corre el riesgo de caer en la
impartición de formación técnica en programas
universitarios, con carencias evidentes de
fundamentación teórica, y por lo tanto sin
soportes sólidos que permitan a los egresados
proponer mejoras u optimizaciones a procesos
existentes, sin caer en el empirismo.
Los dos grupos de estudiantes previamente
clasificados, son disímiles entre sí; y
especialmente con aquellos que presentan
dificultades de horario laboral, se dificulta
implementar grupos de investigación o semilleros
que aporten al crecimiento de la calidad
académica que requieren las evaluaciones de
estado, al tiempo que los estudiantes
pertenecientes al segundo grupo identificado,
son quienes usualmente requieren ser
“entrenados y re-educados” en las empresas al
momento de su contratación, son estos últimos
quienes generan las quejas de los empresarios
frente al tema de que los conocimientos
impartidos desde la academia no siempre son
útiles en el mundo empresarial real.
¿Por qué interesa enseñar el núcleo?
Existen varias razones para querer incorporar el
Núcleo en los planes de estudio de la educación
superior, dos de ellas son:
En primera instancia, porque el Núcleo promete
consolidar en sí mismo las mejores prácticas de la
ingeniería de software tal y como se conoce hasta
ahora, esto implica múltiples ventajas para todo lo
relacionado con la industria y la academia del
software, por ejemplo disminución de costos,
aumento de ganancias económicas, optimización
de procesos, aumento de calidad en productos
finales, etc.
En segundo lugar porque los egresados son
quienes finalmente irán a las empresas a aplicar
aquello que hayan aprendido en sus programas
universitarios, no es descabellado entonces
procurar que desde su formación académica
reciban los conocimientos que luego desplegarán
en el mundo industrial.
Interés académico
El software pasó a ser un elemento de uso diario
para todas las personas en diversos entornos, ya
no es de uso exclusivo para quienes están
inmersos de alguna manera en el mundo
tecnológico, muchos usuarios se consideran
expertos en temas informáticos, pero el mundo
informático es tan amplio, que es necesario definir
claramente sus componentes y sus características,
particularmente las del componente software.
Al respecto, la figura 1 muestra la transversalidad
del software en tres áreas computacionales,
Ingeniería de la Computación (IC), Ciencias de la
Computación (CC), y como era de esperarse, de la
propia Ingeniería de Software (ISw).
Figura 1. Transversalidad del Software (Tomada
de (Holguín Ontiveros & Valbuena Antolinez,
2013)).
Uno de los apartes de la conclusión de (Holguín
Ontiveros & Valbuena Antolinez, 2013) hace
alusión a la importancia de la “continua revisión
de los estados del arte sobre la disciplina y el
núcleo epistemológico de la misma”, refiriéndose
a la tecnología. Este aporte es significativamente
valioso para los entornos académicos, teniendo en
cuenta que las características de quienes se
desenvuelven en los programas relacionados con
la informática suelen ser personas ávidas de
conocimientos de punta, bien sea para apropiarse
de ellos a través del estudio (investigadores,
docentes y estudiantes), o a través de la búsqueda
de
souciones
y
aplicaciones
prácticas
(principalemnte en el caso de los empresarios);
pero este interés no puede ni debe desembocar
en prácticas empíricas, las cuales no cuenten con
soportes teóricos.
Ante la realidad de que en el sistema académico
Colombiano actual y gracias a la implementación
de los ciclos propedéuticos, un gran porcentaje de
la población estudiantil es población trabajadora,
cuya prioridad no es investigar ni leer textos
extensos, es perentorio buscar la mejor forma de
hacer llegar a esos estudiantes el conocimiento
eficaz del Núcleo de la ingeniería de software
SEMAT, sin perder de vista la fundamentación
teórica del mismo.
Interés industrial
Las empresas de base tecnológica requieren
profesionales íntegros que además de los
conocimientos técnicos posean habilidades
transversales tales como las comunicativas, de
relaciones interpersonales, etc. Las IES
usualmente se preocupan de mantener planes de
estudio vigentes acorde con las necesidades
expresadas por lo que el medio les demanda,
entendiendo el medio como Empresas, la
sociedad e incluso otras IES, toda vez que es
posible que sus egresados deseen continuar
realizando estudios posgraduales.
A pesar de lo anterior, algunos empresarios
manifiestan su disgusto con el desempeño inicial
de los recién graduados que vinculan a sus
empresas, y argumentan que la formación que
éstos han recibido probablemente sea insuficiente
o, incluso, incorrecta, toda vez que los
conocimientos que llevan no cumplen las
expectativas de lo que la empresa requiere. Para
el caso de los profesionales y las empresas
relacionadas con la Ingeniería de Software, no se
presenta una excepción a este comportamiento;
de hecho, uno de los trabajos que han versado
sobre las problemáticas que derivan de la brecha
que separa la teoría de la Ingeniería de Software,
como se enseña en las IES, de la realidad
requerida por las industrias, es el de (Alsmadi &
Abul-Huda, 2011); allí manifiestan que uno de los
mayores inconvenientes surge del hecho de que
los estudiosos de la enseñanza de la Ingeniería de
Software se centran en el ámbito académico,
ignorando las necesidades manifestadas por las
industrias frente a este tema. Teniendo en cuenta
el segundo ítem de este trabajo, probablemente
se logre dar una luz de explicación a este
fenómeno.
Se encuentra también el artículo de (Wohlin, 2013)
en el cual expone los 10 desafíos más importantes
para lograr una asociación exitosa entre la
industria y la academia, más allá de las
conclusiones que permiten evidenciar que la
relación industria – academia debe ser vista como
una inversión para ambas partes, queda la
inquietud de la motivación para este tipo de
trabajos, lo que lleva a pensar que existen
incontables necesidades en la industria que no
han logrado ser cubiertas completamente por la
academia, y es a partir de esta reflexión que se
comienzan a buscar alternativas de solución a la
situación encontrada. Prueba del interés de las IES
por mejorar la manera en la cual se imparte la
Ingeniería de Software, es el trabajo realizado por
(Marques, Quispe, & Ochoa, 2014), el cual realiza
una búsqueda de los métodos pedagógicos
utilizados en la actualidad, y concluye que las
propuestas de enseñanza de la Ingeniería de
Software involucran un gran número de
experiencias prácticas y funcionales que incluyen
estudios de caso y desarrollo de juegos entre otras
actividades.
Otros intereses
El trabajo de (Perez Gama & Quizza Tomich, 2012)
indica que la acreditación internacional de
programas ingenieriles debe ser una prioridad si
se quiere aumentar la competitividad de las
universidades y de los países latinoamericanos,
todo ello debe ir soportado en procesos que
garanticen calidad, por ejemplo, optimización de
planes de estudio, capacitación a docentes sobre
tecnologías de punta y sobre metodologías de
trabajo para abordar nuevos elementos como el
Núcleo SEMAT.
alternativas de solución
Para afrontar la situación problemática de la
brecha industria-academia, existen múltiples
propuestas de solución tales como el esquema
CDIO (Concebir Diseñar Implementar Operar) que
se presenta como “Una Nueva Visión para la
Educación en Ingeniería” ((FCFM), s.f.), el cual
pretende que los estudiantes de cualquier
programa de ingeniería reciban conocimientos
con sólidas bases teóricas que puedan ser
aplicables en la industria; se ocupa de indagar
acerca de los conocimientos que las industrias
requieren de los egresados, también de las
mejores estrategias para lograr que los
estudiantes efectivamente adquieran dichos
conocimientos.
Para el caso de Latinoamérica existen propuestas
de solución como la de (Holguin & Valbuena, 2013)
quienes presentan una idea que busca llevar a las
aulas de clase un extracto de los procesos
empresariales relacionados con las buenas
prácticas de la Ingeniería de Software, el proyecto
incluye obviamente acompañamiento pedagógico,
aplicación de metodologías activas y métodos
evaluativos que permitan evidenciar el alcance de
los conocimientos y competencias mínimas
requeridas por los estudiantes.
Conclusión
Se requieren estrategias pedagógicas que
permitan acercar de manera óptima y relevante
los elementos del Núcleo a los estudiantes de
programas universitarios informáticos tales como
Tecnología Informática, Tecnología en Sistemas,
Ingeniería de Sistemas, etc. Con el fin de que todo
el potencial del Núcleo pueda ser desarrollado,
comprendido y utilizado por aquellos que luego lo
replicarán en las empresas, o sea los futuros
egresados y profesionales del país.
Para el abordaje del tema del Núcleo con los
estudiantes con títulos previos se recomienda
determinar los elementos de las metodologías con
los cuales ellos están en mayor interacción en su
día a día laboral, ya que para ellos más fácil
identificar las prácticas de dichas metodologías, y
sus componentes más generales; así que les
resultará más fácil hacer las representaciones en
el núcleo.
Para los estudiantes que no tienen títulos previos,
el trabajo con ellos puede ser más provechoso
desde el punto de vista de la teoría, tanto del
núcleo como de las metodologías.
Finalmente, y teniendo en cuenta que se trata de
grupos estudiantiles que comparten los mismos
espacios académicos, se recomienda la creación
de espacios de discusión en los cuales todos
puedan compartir las experiencias de sus
investigaciones.
Referencias
(FCFM), F. d. (s.f.). CDIO. Obtenido de
http://www.cdio.cl/cdio-a-new-vision-for-e
ngineering-education
Alsmadi, I., & Abul-Huda, B. (2011). Improving
understandability in teaching of software
engineering and connectivity with the
industry. Global Engineering Education
Conference (EDUCON) (pp. 20 - 25).
Amman: IEEE.
Colombia, M. d. (20 de Julio de 2009). Información
destacada Ministerio de Educación.
Obtenido
de
http://www.mineducacion.gov.co/1621/ar
ticle-196476.html
Holguín Ontiveros, E. P., & Valbuena Antolinez, S.
(2013).
Design,
Construction
and
Imp,ementation
of
a
Professional
Education
Program
of
Software
Engineering. Latin American Computing
Conference. IEEE.
Jacobson, I., Zapata, C., Ng, P.-W., McMahon, P.,
Spence, I., & Lidman, S. (2013). La esencia
de la ingeniería de Software: El núcleo de
Semat. Revista latinoamericana de
ingeniería de software, 71-78.
Marques, M. R., Quispe, A., & Ochoa, S. F. (2014).
A systematic mapping study on practical
approaches
to
teaching
software
engineering. Frontiers in Education
Conference (FIE) (pp. 1 - 8). Madrid: IEEE.
Perez Gama, A., & Quizza Tomich, M. (2012). The
international
accreditation
of
the
engineering by propaedeutical cycles: An
imperative
for
Colombia.
Global
Engineering
Education
Conference
(EDUCON) (pp. 1-10). Marrakech: IEEE.
Pérez Gama, A., Mena Mena, A., Hoyos, G., &
Pérez Guitérrez, B. (2010). A Knowledge
Based Analytical Model of Propaedeutic
Cycles for Higher Education: Linking with
Media Education in Colombia. The Future
of Global Learning Engineering Education
(pp. 281 - 286). Madrid: IEEE.
Pérez Gama, A., Pérez Gutiérrez, B. A., & Hoyos
Gómez, G. (2011). Knowledge for society,
the social inclusion towards the high
educational competitiveness. IEEE Global
Engineering
Education
Conference
(EDUCON) – "Learning Environments and
Ecosystems in Engineering Education" (pp.
1139 - 1145). Amman: IEEE.
Wohlin, C. (2013). Empirical software engineering
research with industry: Top 10 challenges.
Conducting Empirical Studies in Industry
(CESI) (pp. 43 - 46). San Francisco, CA: IEEE.
Wohlin, C. (2013). Empirical Software Engineering
Research with Industry: Top 10 Challenges.
CESI (pp. 43-46). San Francisco, CA, USA:
IEEE.
Ethics: extending human aspects in Way-of-Working
M.J. Simonette & E. Spina
Escola Politécnica – Universidade de São Paulo, São Paulo, Brazil.
M.E. Magalhães
CEST – Universidade de São Paulo, São Paulo, Brazil.
one challenge that are always present in all
software endeavors: To give more value to people
and the interaction between them, than on
process and tools.
Introduction
A software world
Software development has become as activity
present in many organizations. Several
organizations have their own software
development teams and have their processes,
activities, services, and products being offered,
and executed, through software systems. A glance
toward the future indicates that almost all
business will be on software systems. This
suggests that organizations will be software
companies, whether they are aware of it or not.
The competence of organizations to produce, to
subscribe, and to use a software system is, and
will be, an essential factor of their success, of their
competitive strategy. As argued by Marc
Andreesen: “Software is eating the world”
(Andreessen 2001).
Challenges of software world
How to deliver software with process that have
productivity, predictability, and quality? How to
answer the demand for software systems that are
reliable and that are essential to differentiate who
demand
them
from
others
competing
organizations? How to produce and maintain
software systems in face of various regulatory
requirements of the market? How is it possible
to answer in an innovative and fast way? These
are only a few examples of a long list of challenges
present in software endeavor. However, there is
Software Engineering
A system of human activities
Unlike others engineering disciplines, there is not
a science that establishes the principles and laws
of software engineering (Lehman, 1989, 1991,
Jacobson et. al. 2012, 2013). The development of
the first version of a software, and the evolution
of an existing one, is not a process governed by
laws of nature. Lehman (1980) argues that the
first implementation of a software and the
changes that occur in this software do not occur
spontaneously; people do this work by the
interpretation of requirements, specifications,
code, and documentation. Lehman continues by
stating that people who perform this work do so
because the users, consumers, customers,
legislation, administrative guidelines, failures in
current systems or even by inspiring to change or
to do something that they think that is better. The
human judgment and reasoning have a decisive
role in the execution of the software development
process.
The main actors
Different software systems have different
objectives. Therefore, there are different kinds of
software’s (Pressman, 2010, Somerville, 2011).
Software engineers deal with this diversity and
they have the natural vocation to create and
maintain software systems that bring value to
humanity.
Software systems development methods and
process have received much attention from
scientific community and from software industry
(Boehm & Turner, 2003, Bourque & Fairley, 2014;
SEI – Carnegie Mellon University, 2013; Agile
Alliance, 2013; SEMAT, 2015; Scrum.org, 2015).
Nevertheless, few methods consider human
aspects as desires, values, emotions and free will
of people that work in the software process.
People are the main actors of the software system
life cycle, both individually and collectively.
concern: (i) Work has relationship with
Requirements – Opportunity – Software System;
(ii) Team has relationship with Software System –
Stakeholder; (iii) Way-of-Working does not have
relationship with alphas of other dimensions
rather than Endeavor.
Although the alpha Way-of-Working does not
have relations with others areas of the Kernel, it is
an essential link between Team and Work.
Individuals and the interactions among
them
People are present during all the phases of the
software endeavor, since the identification of an
opportunity until its retirement. In this lifecycle,
there are stakeholders and development team.
These two groups of people need to interact with
each other, and among their own teams, to
promote the understanding of the needs and
problems requirements.
As argued by Weinberg (2011): “No matter what
the problem is, it's always a people problem.”
Figure 1. Alphas of the Endeavor area of concern
and their relationship with other Kernel alphas.
Relationship challenges
Individuals who manage and practice software
engineering must consider professional and
ethical issues in their decisions to commit their
team as a whole to the highest ethical and
professional conduct. Ethical decisions, decisions
that are deemed correct, encourage cooperation
not only among team members, but also between
the development team and stakeholders.
Despite the apparent simplicity of the relations
between the alphas shown in Figure 1, there are
some challenges in these relations: (i) The
cooperation among Team members; (ii) The
cooperation among Team members and
stakeholders; (iii) The awareness of the individuals
who manage and practice engineering in respect
to the software engineering Code of Ethics.
The attention to the promotion of cooperation
and the awareness of the software engineering
Code of Ethics is essential for the software team,
in order to accomplish works that are concerned
with the health, safety and welfare of the people
that take part of the software endeavor.
Essence endeavor dimension
Software engineering code of ethics
Ethics
Endeavor alphas and its relationships
Figure 1 highlights the relationships of the Essence
Kernel alphas that belong to the Endeavor area of
Software Engineering Code of Ethics and
Professional Practice (Version 5.2) is the standard
for teaching and practicing software engineering
that was jointly approved by the ACM (Association
for Computing Machinery) and IEEE Computer
Society (more information about the Code of
Ethics
is
available
at:
http://www.acm.org/about/se-code).
The preamble of the Software Engineering Code
of Ethics and Professional Practice (Version 5.2)
states that: “The Code contains eight Principles
related to the behavior of and decisions made by
professional software engineers, including
practitioners, educators, managers, supervisors
and policy makers, as well as trainees and
students of the profession. The Principles identify
the ethically responsible relationships in which
individuals, groups, and organizations participate
and the primary obligations within these
relationships. The Clauses of each Principle are
illustrations of some of the obligations included in
these relationships. These obligations are founded
in the software engineer’s humanity, in special
care owed to people affected by the work of
software engineers, and the unique elements of
the practice of software engineering. The Code
prescribes these as obligations of anyone claiming
to be or aspiring to be a software engineer”.
The eight Principles of the Code, in their short
version, are:
1. PUBLIC - Software engineers shall act
consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers
shall act in a manner that is in the best interests of
their client and employer consistent with the
public interest.
3. PRODUCT - Software engineers shall ensure
that their products and related modifications
meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain
integrity and independence in their professional
judgment.
5. MANAGEMENT - Software engineering
managers and leaders shall subscribe to and
promote an ethical approach to the management
of software development and maintenance.
6. PROFESSION - Software engineers shall advance
the integrity and reputation of the profession
consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair
to and supportive of their colleagues.
8. SELF - Software engineers shall participate in
lifelong learning regarding the practice of their
profession and shall promote an ethical approach
to the practice of the profession.
Software engineering code of ethics
and essence kernel
The Essence Kernel can be scaled to address
ethical issues, providing guidance beyond what
the Kernel provides, conducting software
engineers to carrying out their professional duties,
maintaining the highest possible standards of
conduct. This additional guidance comes in forms
of supplements to the checklists of each state of
the Way-of-Working alpha.
Ethics: there is no absolute right answer
A strong characteristic of the Endeavor area of
concern is the presence of people; it is in this
context that the relationship among team
members occurs. The dissemination of the
software engineering Code of Ethics to team
members is not a matter of aligning the Code to
the established principles, and constraints, which
shape the workflow and define the first state of
the Way-of-Working alpha. This occurs because
each member of the team has their own values,
moral, and formulation of personal ethical
standards. These personal elements have
influence over decision-making processes and
over the interrelationship among individuals. As a
team, it is necessary to develop a shared
understanding of the ethical standards among
team individuals. This understanding allows the
team to develop confidence on the expected
behavior of both the individuals themselves and
as team members, and the team as a group.
Ethical issues are very important elements of
software engineer career, and are present in
lifecycle of software systems from lust-to-dust. As
these ethical issues cause team members to deal
with values, it is necessary to explain and support
the ethics in decision-making throughout the
software lifecycle.
Checklist supplement
The short version of the eight principles of
software engineering Code of Ethics summarizes
aspirations at a high level of abstraction.
Nevertheless, the short form is useful to develop
items of a checklist, which allow team members to
identify if they have problems in adhere to ethical
principles in addition with the tailored set of
practices and tools used by the team to guide and
support their work.
In order to develop a shared vision of the software
engineering ethical principles, and work with it
towards a
common
interpretation
and
implementation of the software engineering Code
of Ethics, the authors supplemented the checklist
of the Way-of-Working alpha states with
additional guidance about ethical principles of
software engineering.
Each of the principles expresses a strong assertion
or intention. Wherefore, the best way to identify
team adherence to these principles is by a double
negation of the principle. As an example, the
principle: “1. PUBLIC - Software engineers shall act
consistently with the public interest”, can be
represented in a checklist as: “team members are
not acting in an inconsistent way with the public
interest.”
Table 1 presents the items that supplement the
checklist of each state.
Table 1. Supplement Checklist for way-of-working
alpha states.
State
Supplement Checklist
Principles Team members adhere to the
Establish Principles of Software Engineering
ed
Code of Ethics
Team members agree that the
Foundati
usable way of work selected
on
adhere to the Principles of
Establish
Software Engineering Code of
ed
Ethics.
In Use
In Place
Working
Well
Retired
 Team members are not acting in
an inconsistent way with the
public interest.
 Team members are not acting in a
manner that is not in the best
interests of their client and
employer.
 Team members ensure that their
products and products
modifications are not meeting
poor standards or bad patterns.
 Team members are not taking
decisions influenced by others
professionals or
other interests regardless of any
personal advantages.
 Team managers and leaders are
not performing or promoting
anti-ethic approach to the
management of software
development or maintenance in
any aspect technical, professional,
behavioral or in staff related
aspects.
 Team members by act or by
omission are not denigrating the
profession.
 Team members are not being
unfair, non-respectful or
non-supportive relating any
colleagues, professionals or any
staff members.
 Team members are not by act or
omission avoiding or disregarding
opportunities to pursue lifelong
learning regarding the practice of
the profession or to reinforce
ethical approaches to the practice
of the profession.
Supplement equal to In Use.*
Supplement equal to In Use.*
Team members have assured that
the ethical decisions are recorded
for future reference.
* Ethics concern must be present through all the
execution states.
Conclusion and Future Work
The way of working affects all team members, and
every team member can contribute to it (Jacobson
et. al. 2013). Ethical issues are present in
endeavor dimension, and must be consider as the
team evolves their way of working alongside their
understanding of their mission and their working
environment.
When team members talk about ethical Principles
at each Way-of-Working alpha states, they
deepens the knowledge and debate about the
actions and decisions present in their way of work.
The Principles identify the ethically responsible
relationships in which individuals, groups, and
organizations participate, and the primary
obligations within these relationships. The clauses
of each Principle are illustrations of some of the
obligations included in these relationships. These
obligations are founded in the software engineers
humanity, in special care owed to people affected
by the work
Acknowledgement
The authors would like to thank Full Professor Luiz
Barco, Senior invited professor at Computer
Engineering Department (PCS) of Escola
Politécnica from Universidade de São Paulo, for
the numerous hours spent with us discussing
ethics and humanism in technological innovation
processes.
This paper was supported in part by Universidade
de São Paulo Society and Technology Study Center
(or, CEST – Centro de Estudos Sociedade e
Tecnologia, in Portuguese).
Engineering Body of Knowledge, Version 3.0, IEEE
Computer Society. Available at: www.swebok.org.
Brooks, F.P. 1987. No silver bullet: Essences and accidents of
software engineering. IEEE Computer, vol. 20, no. 4,
pp.10-19. Doi: 10.1109/MC.1987.1663532
Clarke, P. & O’Connor, R.V. 2012. The situational factors that
affect the software development process: Towards a
comprehensive reference framework. Information and
Software Technology, vol. 54, no. 5, pp. 433–447. Doi:
10.1016/j.infsof.2011.12.003
Lehman, M.M. 1980. On understanding laws, evolution, and
conservation in the large-program life cycle. Journal of
Systems and Software, vol. 1, pp. 213-221.
Lehman, M.M. 1991. Software engineering, the software
process and their support. Software Engineering Journal,
vol.6, no.5, pp.243-258, Sep.
Jacobson I., Ng, P.W., Mcmahon, P.E.,Spence, I. & Lidman, S.
2012. The Essence of software engineering: The SEMAT
kernel. Queue, vol. 10, no. 10, pp. 40-52. DOI:
10.1145/2381996.2389616.
Jacobson I., Ng, P.W., Mcmahon, P.E.,Spence, I. & Lidman, S.
2013. The Essence of Software Engineering – Applying
the SEMAT Kernel. New Jersey: Addison-Wesley
Professional, 2013.
Pressman, R.S. 2010. Software Engineering: A Practioniner`s
Approach, 7th. Ed., New Your, NY: McGrae-Hill, 2010, 930
p.
Scrum.org, 2015. Improving the Profession of Software
Development. Presents resources and methods
developed by Scrum practitioners and agile professionals.
Available at: <http://www.scrum.org>.
SEI - Carnegie Mellon University, 2015. SEI - Methods & Tools.
It presents tools and methods developed by the SEI and
its
research
partners.
Available
at:
<http://www.sei.cmu.edu/tools/?location=secondary-na
v&source=1358>.
SEMAT, 2015. Software Engineering Method and Theory.
Available at: <http://www.semat.org>.
Somerville, I. 2011. Software Engineering, 9th Ed. Boston:
Addison-Wiley, 2011, 790p. ISBN 9780137035151.
Weinberg, G. 2011. The Secrets of Consulting: A Guide to
Giving and Getting Advice Successfully. Wienberg &
Wienberg, Kindle Edition.
References
Agile Alliance, Guide to Agile Practices. Available at:
<http://guide.agilealliance.org/#sthash.xP4cQ00s.dpuf>.
Andreesse, M. 2011. Why Software is eating the world. The
Wall Street Journal. Essay, August 20, 2011.
Boehm, B.W. & Turner, T. 2004. Balancing agility and
discipline: a guide for the perplexed. Boston:
Addison-Wesley, Kindle edition.
Bourque, P. & Fairley, R.E. eds., 2014. Guide to the Software
Agilismo
Proceedings of the Latin American Software Engineering Symposium, Año 2015, pp. 64, ISSN 2500-5013
Guía para la Integración de Métodos Formales de Ingeniería de
Requerimientos en Procesos de Desarrollo Ágil
J.D. Murcia Torres, M.E. Torres Moreno
Pontificia Universidad Javeriana, Bogotá, Colombia
Introducción
En el mundo del desarrollo de software, son
muchas las metodologías que se encuentran
disponibles, sin embargo, cada proyecto tiene
necesidades diferentes, y seleccionar la adecuada
podría significar en gran medida el éxito o fracaso.
Los inconvenientes en los proyectos pueden ser
variados, sin embargo se ha logrado establecer
que la gran mayoría de estos problemas tienen
que ver con procesos errados de Ingeniería de
Requerimientos, y/o con una mala gestión de la
metodología usada [2]. Las metodologías ágiles
han hecho frente a algunas de estas dificultades,
sin embargo, por su naturaleza, no las logran
abarcar a plenitud.
La Guía, busca acoplar de una manera armónica
los diferentes conceptos teórico/prácticos
implícitos en los proyectos de desarrollo,
haciendo principal énfasis en los procesos de
Ingeniería de Requerimientos y las buenas
prácticas soportadas por las metodologías ágiles.
En este sentido, La Guía propone una serie de
“formas de” hacer las cosas en esta, y una
unificación de todos los aspectos teóricos
mencionados a continuación.
Marco Conceptual
El desarrollo de La Guía implicó una amplia
investigación sobre aspectos teóricos tales como
Ingeniería de Requerimientos, metodologías
ágiles, la forma en que se modelan los
requerimientos y SEMAT; siendo esta última, una
iniciativa que busca por medio de una teoría lo
suficientemente formal, la implementación de la
Ingeniería de Software, utilizando las mejores
prácticas de los “más de 100000 métodos
existentes”
[3], dentro de los cuales se
encuentran RUP, CMMI, Scrum y XP entre otros.
Los aspectos más importantes de estas temáticas,
y sus respectivas adaptaciones se enuncian a
continuación:
SEMAT (Software Engineering Method
and Theory)
Iniciativa que busca redefinir la Ingeniería de
Software por medio de lo que los autores
consideran como “La esencia de la Ingeniería de
Software: El núcleo de SEMAT” [4]. Dicha
redefinición se encuentra basada en una teoría
sólida, principios probados y las mejores prácticas
aplicables a los proyectos, incluyendo un núcleo
(Kernel) de elementos ampliamente aceptados y
que se pueden extender a usos específicos; de
manera que se traten asuntos tecnológicos y
humanos, apoyando a la industria, la academia,
investigadores y usuarios.
El Kernel se compone de dos grandes conjuntos
de elementos: “Las cosas con las que siempre
trabajamos” (Ver Ilustración 1) y “las cosas que
siempre hacemos” (Ver Ilustración 2); este
primero representado a través de los llamados
Alfas, quienes a su vez poseen un conjunto de
Estados que simbolizan el porcentaje de avance y
salud del proyecto; el segundo son Actividades
asociadas a los Alfas.
Ilustración 1. Cosas con las que siempre trabajamos. (Tomado de
[5])
En este sentido, elementos del Kernel como los
Alfas (y sus Estados) han sido representados
físicamente a través de las Cartas Alfa de Estados
(Ver Ilustración 3). Estas cartas se pretende sean
gestionadas en el transcurso del proyecto, de
manera que al finalizar este, se haya pasado por
cada uno de los estados.
Ilustración 2. Cosas que siempre hacemos. (Tomado de [5])
Ilustración 3. Cartas Alfa de Estados. (Tomado de [6])
Existen dos tipos de Cartas Alfa de Estados, una
muy general en la que se enuncia un Alfa y los
distintos Estados por los que este pasa, y otra que
detalla cada Estado a través de una lista de
chequeo esencial propuesta por SEMAT –a la cual
se le pueden adicionar tareas relacionadas con las
Actividades
asociadas al
Alfa y
más
específicamente al Estado en el que se encuentre
el proyecto–.
El Kernel posee tres principios fundamentales
(Accionable, por los Estados propuestos en los
Alfas; Extensible, por su capacidad de modificarse;
y Práctico, por la representación de Estados a
través de cartas gestionadas diariamente) que lo
hacen una herramienta verdaderamente positiva
y efectiva a la hora de gestionar cualquier
proyecto de software [6].
Metodologías Ágiles
Estas metodologías se basan en principios y
valores que enfocan el trabajo principalmente
hacia las personas, la productividad y la oportuna
respuesta al cambio [7]. En este sentido, fueron
analizadas metodologías como Kanban, Scrum y
XP, con el fin de determinar las principales
características propias de los proyectos de
desarrollo ágil, haciendo especial énfasis en las
dos primeras, ya que se consideró que serían las
más apropiadas –en este caso– a ser adaptadas al
Kernel de SEMAT, en cuanto a que se encuentran
más enfocadas hacia la gestión/ejecución de
proyectos.
Por su parte Scrum aporta a esta Guía la forma
en que gestiona sus iteraciones o "sprints", los
cuales siempre están encaminados a cumplir con
el objetivo (Sprint Goal) establecido durante una
reunión inicial (Sprint Planning Meeting). La forma
en que se ejecuta, y se mapean los artefactos de
Scrum a La Guía, será explicada más adelante.
Por otro lado Kanban, que está basado en los
principios Lean y el cual es considerado como un
“sistema de producción altamente y efectivo” [8],
aporta la metodología para gestionar proyectos a
través de “tarjetas visuales” –en este caso las
tarjetas que representan a los diferentes Estados
de los Alfas en SEMAT–, y la forma de trabajar con
su tablero de estados.
Modelado de Requerimientos
Según IEEE, un requerimiento se refiere a "una
sentencia que traduce o expresa una necesidad y
sus condiciones y restricciones asociadas" [9].
Estas "necesidades" son resultado de un proceso
de Ingeniería de Requerimientos (IR), y serán la
materia prima de los desarrolladores a la hora de
crear y dar forma al producto de software, debido
a que representan de manera atómica las
características y funcionalidades que este debe
tener.
Un proceso de IR implica por lo general cinco
etapas
primordiales
(obtención,
análisis,
especificación, validación y gestión) que
"garantizan" que los requerimientos finales estén
bien definidos [10]. Dependiendo de la
metodología utilizada, es necesario hacer
variaciones sobre cada etapa, de manera que se
adapte a la filosofía de esta.
Ante la importancia de la Ingeniería de
Requerimientos en el
desarrollo de software,
poco a poco se han propuesto diferentes modelos
que ayuden a los Ingenieros de Software en la
realización de las actividades que dicho proceso
implica (obtención, análisis, especificación, etc.).
En este sentido, iniciativas como las de KAOS
[11] e i* [12] son actualmente las más conocidas,
sin embargo, nuevas propuestas como la de Joy
Beatty, buscan estandarizar los modelos
existentes a través de lenguajes como RML [13].
Los modelos que Beatty propone son
clasificados en
cuatro grandes grupos:
Objetivos-Personas-Sistemas-Datos (OPSD) [13];
siendo esta clasificación la que se tuvo en cuenta
en la elaboración de La Guía para asignar los
modelos durante las diferentes etapas del
proyecto, a fin de poder analizar las soluciones.
Los Modelos de Objetivos describen el valor que
genera el sistema al negocio y se usan durante
etapas tempranas de los proyectos. En este
sentido fue seleccionado el Modelo de Objetivos
del Negocio, cuyas principales características
consisten en definir un conjunto de problemas
referentes al negocio, y a su vez, los objetivos que
podrían dar solución a dicha problemática. Al
finalizar el modelado a través de este objetivo, se
pretende que se hayan establecido las
características de alto nivel asociadas a los
objetivos de negocio propuestos, esto generará un
entendimiento del negocio, y de lo que se quiere
realmente lograr con el desarrollo [13] [14].
Ilustración 6. Plantilla del Modelo de Objetivos del Negocio.
(Tomado de [13])
Los Modelos de Personas describen y permiten
detectar agrupaciones de personas (Stakeholders)
que
posiblemente
puedan
proporcionar
información importante referente a los
requerimientos del sistema. De acuerdo a esto se
seleccionó un modelo de tipo Organigrama,
debido a que proponía distintos niveles de
granularidad que permitían determinar a los
Stakeholders relevantes [13] [15].
Ilustración 7. Plantilla del Organigrama. (Adaptado de [13])
Los Modelos de Sistemas por su parte, permiten
describir al sistema actual, sus interfaces y
comportamiento. Se seleccionaron dos modelos,
el modelo de Flujos de Procesos, y el Mapa del
Ecosistema. Este primero, en cuanto a que
permite no solo conocer un estado actual de los
procesos existentes, sino también realizar un
mejoramiento de los mismos [13] [16].
La Guía
Ilustración 8. Ejemplo de un Modelo de Flujos de Proceso. (Tomado
de [17])
El segundo modelo de la categoría sistemas
(Mapa del ecosistema), fue seleccionado ya que
logra reunir en un solo grafo todas las interfaces
de interacción existentes en el sistema, la
información transmitida entre estas, y la
direccionalidad de la misma [13] [18].
La Guía propuesta es concebida como una
herramienta a la hora de generar un “formalismo
ágil” durante procesos de Ingeniería de
Requerimientos en proyectos de desarrollo, y
teniendo como principal base al Kernel de SEMAT.
De acuerdo a lo anterior, La Guía propuesta se
ha articulado alrededor de los principios teóricos
mencionados anteriormente, los cuales fueron
adaptados con el fin de dar solución a la
problemática encontrada. Dicha adaptación es
unificada a través de un método que permitirá la
implementación de esta Guía.
Way-Of (método de implementación)
Ilustración 9. Plantilla de Mapa del Ecosistema. (Tomado de [13])
Los modelos de Datos describen las relaciones
entre los objetos de datos del negocio, ciclo de
vida de estos y aporte e impacto sobre el negocio.
De esta categoría se seleccionó el modelo
Diagrama de Datos del Negocio debido a que
permiten observar las interrelaciones entre los
objetos de datos del negocio, y la cardinalidad
existente entre dichos objetos [13] [19].
Ilustración 10. Plantilla de Diagrama de Datos del Negocio.
(Tomado de [13])
Este método proporciona gran capacidad de
adaptabilidad y flexibilidad en los procesos
diseñados e implementados, lo que sugiere que
pueden ser gestionados y modelados con facilidad,
permitiendo reaccionar a cambios internos y/o
externos que afecten la organización [20]. En este
sentido, son propuestos cuatro Way-Of (Forma de)
que incluyen elementos formales, informales,
estructurados y otros no tanto, que le dan
carácter a metodología y generan una base para
su posterior implementación [21]. Estos
elementos
son:
Way-Of-Thinking,
Way-Of-Working,
Way-Of-Modeling,
y
Way-Of-Supporting. En la Ilustración 11 se puede
observar la manera en que se adaptaron estos
elementos, y cómo son propuestos a ser
trabajados en La Guía.
Way-Of-Thinking hace referencia a la
fundamentación sobre la cual se pretende
desarrollar cada proyecto; en este caso en
específico, la forma de pensar será a través de
principios ágiles implementados en proyectos de
desarrollo de software. Es la base de todo.
Way-Of-Working se encuentra relacionado con
la implementación del Kernel de SEMAT a través
de la integración propuesta más adelante.
Un Way-Of-Modeling que consiste en la
implementación de los modelos explicados
anteriormente, durante las etapas del proceso de
IR.
Finalmente Way-Of-Supporting está enfocado
principalmente hacia el aseguramiento de una
harmonía en la implementación de todos los
conceptos teóricos indicados hasta el momento.
Este elemento se establece transversal al
Way-Of-Working y Way-Of-Modeling.
Integración
Este aspecto corresponde a la adaptación de
todos los elementos teóricos mencionados en el
marco conceptual, con el fin de lograr el principal
objetivo de La Guía: poder desarrollar un proceso
de Ingeniería de Requerimientos formalmente
“ligero”.
En este contexto, se propuso una metodología
que basada en las mejores prácticas, permitiera
utilizar el Kernel de SEMAT como principal
herramienta de gestión de los procesos de IR. Para
lograr esto, fueron seleccionados algunos
componentes del Kernel de SEMAT tales como los
Alfas Stakeholders, Oportunidad, Trabajo y
Sistema de Software, con el fin de representar las
diferentes etapas del proceso de IR, y los estados
por los que este debería pasar para garantizar –de
una manera teórica– la calidad del mismo.
En este mismo sentido, fueron adaptados otros
elementos del Kernel como el Ítem de
Requerimiento, el cual es un tipo especial de Carta
Alfa de Estado con el que se representa
físicamente a cada requerimiento, ayudando a su
gestión durante el proceso de IR. A este elemento
le fue adicionada funcionalidad sobre aspectos
tales
como
prioridad,
trazabilidad
y
versionamiento, que originalmente no se ofrecía
en el Kernel.
En cuanto a la manera de gestionar las
iteraciones al interior del proyecto, se propone el
uso
de
un
modelo
Planear-Hacer-Verificar-Adaptar, dentro del cual
se establecen algunas actividades necesarias de
realizar antes, durante y después de cada
iteración [6]. Parte de estas actividades incluyen
por ejemplo, determinar estados actuales y
objetivos del proyecto con el fin de tener claridad
sobre lo que se quiere lograr tras cada iteración;
determinar la manera en que se van a cumplir los
objetivos; y hacer retroalimentaciones sobre la
manera de trabajar, a fin de lograr mejoras en la
productividad iteración tras iteración.
Así mismo se determinó un conjunto de
actividades a realizar durante cada etapa del
proceso de Ingeniería de Requerimientos, dentro
de las cuales se encuentran gestionar el Ítem de
Requerimiento y generar modelos visuales
dependiendo la etapa de dicho proceso.
Ilustración 12. Ítem de Requerimiento. (Adaptado de [6])
Conclusiones
La Ingeniería de Software –al igual que los
sistemas que se desarrollan a través de los
procesos propuestos por esta– se encuentra en
constante cambio, por lo que iniciativas como la
de SEMAT son bastante interesantes en cuanto a
que no solo se basan en “las mejores prácticas”,
sino que también permiten adaptabilidad.
La Guía propuesta se adhiere a lo sugerido por
SEMAT, por lo que más que una nueva forma de
hacer las cosas, se considera como una iniciativa
libre de ser adaptada y mejorada en función de
cumplir con el objetivo principal de cualquier
desarrollo de software. En este sentido fue
validada a través de la opinión de un experto en
proyectos ágiles, quien determinó que esta (La
Guía) “presenta de manera exitosa y rigurosa,
varios elementos conceptuales de Ingeniería de
Software como métodos, mejores prácticas y
tendencias que integrados podrían tener un éxito
gigante”.
En estos instantes La Guía se encuentra en un
proceso de prueba en un entorno real.
Referencias
[13]
[1] K. Wiegers y J. Beatty, Software
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
Requirements, Tercera ed., Redmond,
Washington: Microsoft Press, 2013.
R. N. Charette, «Why Software Fails. IEEE
Spectrum,» 02 Septiembre 2005. [En línea].
Available: 02. [Último acceso: 15 Julio 2014].
I. Jacobson, B. Meyer y R. Soley, «SEMAT,» 1
Diciembre 2009-b. [En línea]. Available:
http://semat.org/wp-content/uploads/2013/
07/Intro-to-EssenceBerlin-Ivar.pptm. [Último
acceso: 26 Septiembre 2013].
I. Jacobson, B. Meyer y R. Soley, «Software
Engineering Method And Theory (SEMAT),»
01 Diciembre 2009. [En línea]. Available:
http://semat.org/. [Último acceso: 26
Septiembre 2013].
I. Jacobson, P.-W. Ng, P. E. McMahon, I.
Spence y S. Lidman, «The Essence of Software
Engineering: The SEMAT Kernel,»
Communications of the ACM, vol. 55, nº 12,
pp. 42-49, Diciembre 2012.
I. Jacobson, P.-W. Ng, . P. E. McMahon, I.
Spence y S. Lidman, The Essence of Software
Engineering: Applying the SEMAT Kernel,
Addison-Wesley Professional, 2013.
I. Sommerville, Software Engineering,
Addison-Wesley, 2010.
J. F. Krafcik, «Triumph of the lean production
system,» Sloan Management Review, vol. 1,
nº 30, pp. 41-52, 1988.
ISO/IEC/IEEE, «Systems and software
engineering - Life cycle processes Requirements engineering,» nº 29148, 1 12
2011.
IEEE Computer Society, SWEBOK, 3 ed., P.
Bourque y R. E. Fairley, Edits., IEEE Computer
Society, 2014.
Respect-IT, «A KAOS Tutorial,» 2007.
C. Cares, J. Franch Gutiérrez, E. Mayol Sarroca
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
y M. C. Quer Bosor, Reference Model for i*. A:
"Social Modeling for Requirements
Engineering", The MIT Press, 2011.
J. Beatty y A. Chen, Visual Models for
Software Requirements, 2012: Microsoft
Press, 2013.
I. Alexander y L. Beus-Dukic, Discovering
Requirements, Wiley, 2009.
International Institute of Business Analysis
(IIBA), A Guide to the Business Analysis Body
of Knowledge (BABOK Guide), Toronto: IIBA,
2009.
Object Management Group (OMG), «Business
Process Model and Notation 2.0,» 2011.
Bizagi, «Bizagi - Help,» Bizagi, [En línea].
Available:
http://help.bizagi.com/bpmsuite/es/index.ht
ml?crear_un_proveedor_en_sap_desd.htm.
[Último acceso: 13 05 2014].
M. K. Choubey, IT Infrastructure and
Management (For the GBTU and MMTU),
New Delhi: Pearson Education India, 2012.
L. Richardson, «An Entity Relationship
Diagram Example,» 6 Junio 2007. [En línea].
Available:
http://rapidapplicationdevelopment.blogspot
.com/2007/06/entity-relationship-diagram-ex
ample.html. [Último acceso: 20 Julio 2014].
F. Daoudi y S. Nurcan, «A framework to
evaluate methods’ capacity to design flexible
business processes,» de 6th International
Workshop on Business Process Modeling,
Porto, 2006.
M. N. Aydin, Determining An Appropriate
Approach To The Implementation Of A WfMS,
Enschede: Springer, 2005, pp. 515-525.
The Standish Group, «CHAOS Manifiesto,»
2012.
C. Larman, Agile and Iterative Development:
A Manager's Guide, Addison-Wesley, 2004, p.
27.
K. Beck, M. Beedle, A. v. Bennekum, A.
Cockburn, W. Cunningham, M. Fowler, J.
Grenning, J. Highsmith, A. Hunt, R. Jeffries, J.
Kern, B. Marick, R. C. Martin, S. Mellor, K.
Schwaber, J. Sutherland y D. Thomas,
«Manifiesto ágil,» 2001. [En línea]. Available:
http://agilemanifesto.org/principles.html.
[Último acceso: 11 09 2013].
[25] K. Schwaber y J. Sutherland, «The Scrum
guide,» 2013.
[26] J. M. López, «Bitelia,» 12 Noviembre 2013.
[En línea]. Available:
http://bitelia.com/2013/11/que-es-kanban.
[Último acceso: 04 Abril 2014].
[27] D. J. Anderson, Kanban, Blue Hole Press,
2010.
Metodologías ágiles como estrategias de enseñanza de desarrollo de
software
S. Gómez
Tecnológico de Antioquia, Medellín, Colombia
J. Moreno & C. Zapata
Universidad Nacional, Medellín, Colombia
Introducción
Las ciencias de la computación y el desarrollo de
software permean a la mayoría de áreas del
conocimiento, ampliando cada vez más la
necesidad de expertos en la temática. Por este
motivo la optimización del proceso de desarrollo
es el objetivo de varias tendencias. Las
metodologías agiles surgen como una alternativa
a los métodos formales de desarrollo de software;
el agilismo se basa en cuatro principios que
resaltan a los individuos y sus interacciones, al
software funcional, a la colaboración con el cliente
y a la respuesta al cambio. Su implementación en
las empresas de desarrollo viene creciendo,
llegando a estar presentes en más del 90% de las
organizaciones en el área (Capgemini, Sogeti, &
Hp 2014).
Sin embargo, se presentan dos dificultades. Por un
lado, el número de estudiantes en programas de
educación superior en el área de informática
viene disminuyendo (Washington et al. 2015). Un
ejemplo de esta situación se evidencia en
Colombia, donde existen 154 instituciones con
programas de diferentes niveles en el área de
sistemas e informática, pero que en la actualidad
presentan una disminución en el número de
aspirantes a ingresar en estos programas.
Adicionalmente, según los datos del Sistema
Nacional de Información de la Educación Superior,
en los últimos diez años, el 57,8% de personas que
inician estos programas no culminaron. La otra
problemática se debe a que aún existen
programas curriculares del área que no hicieron la
transición hacia la enseñanza de las metodologías
agiles.
A continuación, se presenta una revisión de la
literatura sobre el uso de las metodologías ágiles
en la educación, que resume las metodologías y la
manera de utilizarlas como estrategia pedagógica.
Metodologías Ágiles en Educación
Aprendizaje Basado en Proyecto Ágiles
El aprendizaje basado en proyectos (PBL por sus
siglas en inglés) es una estrategia pedagógica en
donde un grupo de estudiantes, de forma
colaborativa, resuelve una problemática real
mediante la ejecución de un proyecto, siguiendo
unas pautas que define el docente (Rebolledo
2010). De esta forma, cada estudiante junto con
su equipo de trabajo, va alcanzando los logros del
curso, mediante la planeación, implementación y
evaluación del proyecto que está desarrollando,
aplicando los conocimientos vistos en el aula de
clase en un contexto del mundo real (Martí et al.
2009).
Con el surgimiento de las metodologías ágiles,
también se desarrolla el PBL-Agile (Aprendizaje
basado en proyectos ágiles), en donde se
introducen elementos de agilidad en la forma
como los estudiantes deben ejecutar el proyecto.
Los principios de las metodologías agiles se
pueden aplicar desde el punto de vista de teorías
del aprendizaje, especialmente por la aplicación
del constructivismo, las pedagogías activas y el
aprendizaje colaborativo (Rawsthorne 2005).
Vigotsky plantea la importancia del contexto social
y la interacción con compañeros en el proceso de
pensamiento para generar aprendizaje. Así, el
estudiante debe dejar de ser un sujeto pasivo que
recibe conocimiento del docente, para convertirse
en un sujeto activo sumergido dentro de su
proceso de aprendizaje.
Al vincular las metodologías agiles dentro del
aprendizaje basado en proyectos, se obtienen
beneficios en aspectos como el aumento del
compromiso de los estudiantes con las actividades
del proyecto (motivación), debido a la necesidad
de realizar tareas del mundo real y a la necesidad
de hacer pequeñas actividades en lapsos de
tiempo determinados, en vez de una sola
actividad que abarque la totalidad del curso. Otro
aspecto a destacar es la autoregulación de los
equipos de trabajo, de forma que los mismos
estudiantes pueden organizarse permitiendo el
aprendizaje de todos, mediante una adecuada
planeación de las actividades. Por último, el
incremento de la creatividad y la proactividad,
debido a que los estudiantes deben encontrar sus
propias soluciones al problema que están
resolviendo (Zapater et al. 2013).
Entre las principales modificaciones se encuentra
la realización de actividades cortas con una
retroalimentación permanente (Lembo & Vacca
2012). Asimismo, se encuentran diferencias en el
tamaño de los proyectos, la no linealidad de los
mismos, la forma de interacción dentro de los
equipos de trabajo y la manera de documentar el
proyecto (Spundak 2014).
Manifesto Agil
Basado en el acercamiento entre las metodologías
agiles y el aprendizaje basado en proyectos.
También se establece una relación entre los
valores y principios del Manifiesto Ágil con el
ámbito educativo. Para hacer la comparación, se
toman como referencia los valores originales del
manifiesto:
 Individuos e interacciones sobre procesos y
herramientas
 Software funcionando sobre documentación
extensiva
 Colaboración con el cliente sobre negociación
contractual
 Respuesta ante el cambio sobre seguir un
plan
En un contexto educativo, estos valores se pueden
adaptar pero conservando su esencia, donde los
elementos de la derecha de la información son
importantes, son más importantes los de la
izquierda.
Entre las variaciones, se dan diferentes enfoques
dependiendo de la particularidad del proponente.
En el enfoque de Stewart et al. (2009) se indica:
 Aprendizaje centrado en el estudiante sobre
procesos y herramientas tradicionales
 Trabajo por proyectos sobre documentación
extensiva
 Colaboración entre estudiantes y docentes
sobre el seguimiento rígido del currículo
 Respuesta a la retroalimentación sobre el
seguimiento de un plan.
Este enfoque es general y se aplica a cualquier
tipo de curso, donde se podrían cumplir cada uno
de los valores. Sin embargo, hay otras
aproximaciones, como la de Cubric (2013), quien
se basó en los principios de buenas prácticas de
enseñanza de Chickering y Gamsons (1987),
redefiniendo los valores del manifiesto en la
búsqueda de la generación de un aprendizaje
significativo. Los valores quedaron distribuidos así:
 Respetar las necesidades individuales y los
estilos de aprendizaje de los estudiantes,
promoviendo la interacción por encima de la
relación entre estudiantes y directivos
(docentes)
 Incrementar el aprendizaje para toda la vida
más allá de los objetivos de aprendizaje
 Actuar según el progreso del aprendizaje del
estudiante y ajustar el contenido a sus
necesidades
 Promover evaluaciones frecuentes con énfasis
en retroalimentación formativa.
Otra variación la promueven Twidale y Nichols
(2013), quienes lo enfocan más desde el punto de
vista administrativo para el cumplimiento del fin
misional de una institución educativa, donde
solamente realizan variaciones a los valores 2 y 3,
dejando como resultado:
 Individuos e interacciones sobre procesos y
herramientas
 Logros de los estudiantes demostrables sobre
documentación extensiva
 Discusiones de aprendizaje con estudiantes (o
un miembro de la comunidad académica)
sobre documentos, métricas y políticas
 Respuesta ante el cambio sobre seguir un
plan
Casos de Éxito
Diferentes investigadores aplican la relación entre
los principios ágiles y las estrategias de
aprendizaje como metodología para sus cursos,
que van desde niveles básicos hasta cursos de
postgrado. El área donde se aplica mayormente es
ciencias de la computación; sin embargo, el uso de
proyectos se puede ampliar a otras áreas del
conocimiento.
En el área de programación, Bendix y Magnusson
(2008) diseñaron un modelo basado en la
metodología ágil de Extreme Programming (XP).
Para ello, realizan proyectos en equipo con todos
los elementos del XP, con un proyecto iterativo,
por pares y con retroalimentaciones permanentes
que posibilitan la corrección de errores durante la
ejecución. Para hacerlo, primero destinaron unas
horas a la enseñanza de XP y luego lo aplicaron al
curso de programación.
Bunse et al. (2004) también aplicaron XP en
proyectos de software de los estudiantes, pero
con el fin de validar la capacidad que tienen
personas en proceso de formación de adaptar
esta metodología ágil, debido a que exige un gran
nivel de disciplina y de conocimientos previos para
su adecuado cumplimiento. Melnik y Maurer
(2003) también llegaron a esta conclusión,
encontrando que la metodología XP es más difícil
de implementar en la academia que en la
industria, debido a problemas de calendario con
las reuniones, pues los estudiantes no tienen
disponibilidad diaria. Sin embargo, para los
estudiantes la experiencia fue positiva y
consideraron que mejoraba la calidad. El caso de
estudio se aplicó a diferentes tipos de cursos,
desde diplomados hasta cursos de posgrado,
teniendo estudiantes con diferentes niveles de
conocimiento,
siendo
más
aplicable
la
metodología para estudiantes avanzados.
McKinney et al. (2004) también aplican la
metodología XP, donde plantean que en los cursos
introductorios, los alumnos llegan con nociones
de programación, pero es difícil inculcar la
importancia de una buena ingeniería de software.
Por este motivo aplican metodologías agiles, en
donde los estudiantes vieron mayor dinamismo y
adquirieron la importancia de utilizarla.
Del Bianco y Sassaroli diseñan un curso de
desarrollo de software orientado al diseño de
aplicaciones en Java, donde estudiantes con
diferente experiencia en programación trabajan
como un equipo mediado por metodologías ágiles.
El desarrollo se hizo por medio de iteraciones con
pequeños pasos en el avance, donde cada
iteración correspondía a un módulo y se brindaba
retroalimentación permanente. Dentro de los
hallazgos en esta investigación, se encuentra que
para los estudiantes es muy importante la
presencia del docente para la organización de los
equipos.
Andy Hon (2004) diseñó un modelo denominado
Agile Teaching/Learning Methodology (ATLM), el
cual se puede aplicar a diferentes tipos de curso,
que requieran agilidad tanto para enseñanza
como
aprendizaje.
Asimismo,
plantea
herramientas colaborativas en línea para poder
soportar el modelo. Su estrategia se basa en tres
pasos: aprendizaje compartiendo (enseñando),
enseñanza como aprendizaje e importancia de la
retroalimentación.
Propuesta
Con base en la evidencia encontrada en la
literatura sobre casos de éxito en la aplicación de
metodologías ágiles como estrategia de
enseñanza-aprendizaje y ante la necesidad de
formación de desarrolladores de software, surge
como alternativa el diseño de un modelo de un
curso de desarrollo de software que aplique la
metodología PBL-Agile. Este curso tiene como
valor agregado la mediación de ambientes
virtuales de aprendizaje, permitiendo que el curso
no solo se realice en espacios tradicionales con un
espacio limitado de estudiantes sino con la
posibilidad de realizarlo a una escala mayor,
generando un impacto más amplio en la
formación.
Para el diseño del curso se escoge la metodología
ágil SCRUM, debido a que es más general y no
requiere el nivel de conocimiento necesario en la
metodología XP. Así, se posibilita la aplicación del
curso tanto en niveles básicos como avanzados,
pero cumpliendo siempre con los valores del
manifiesto ágil, fomentando el trabajo en equipo,
la retroalimentación permanente y efectiva y con
el agregado de tener unas actividades cortas
donde los estudiantes van a ir aplicando los
conocimientos del curso de forma permanente,
entregando siempre resultados funcionales. Otra
ventaja de la propuesta, con el respaldo de
ambientes virtuales de aprendizaje, es la
flexibilidad tanto en el currículo que se va a
cumplir (que se adapte a las capacidades del
estudiante y de su grupo de trabajo) como en las
diferentes herramientas de apoyo que se pueden
utilizar al momento de desarrollar el proyecto.
El curso donde inicialmente será planteada, es el
de finalización del ciclo Técnico del programa
Ingeniería en Software, ofertado en el Tecnológico
de Antioquia. Los estudiantes ya tienen unas
nociones de programación, de bases de datos y de
métodos tradicionales de ingeniería de Software.
El curso es de tres créditos académicos,
equivalentes a 144 horas de trabajo del estudiante
durante el semestre y la estrategia será de
aprendizaje
mixto,
con
unas
asesorías
presenciales, donde se incluyen los lineamientos
para la realización del curso y espacios para el
trabajo colaborativo. Asimismo, tiene un gran
componente virtual, en donde se realizará todo el
proceso del proyecto basado en metodologías
ágiles que desarrollarán los estudiantes.
El objetivo general del curso es desarrollar un
proyecto pedagógico integrador que permita el
afianzamiento de los contenidos vistos en
diferentes asignaturas por parte de los
estudiantes del programa Técnica Profesional en
Sistemas. También tiene unos objetivos
específicos, asociados al fomento del aprendizaje
colaborativo, en donde los estudiantes se
empezarán a familiarizar con estrategias de
desarrollo de proyectos, tal como lo harán
posteriormente en el mundo laboral. Mediante el
curso, también los estudiantes desarrollarán
conocimientos sobre la metodología SCRUM de
una forma práctica, debido a que conocerán la
teoría de la metodología, pero mediante la
aplicación de la misma. De esta forma, el curso
está planteado con unos entregables, similares a
las iteraciones que se realizan en la metodología,
también están los roles tanto de los estudiantes
como de los docentes que reflejan los roles reales
al momento de desarrollar un proyecto en la
metodología.
Durante las 16 semanas de duración del curso, los
estudiantes deben realizar 8 iteraciones con
entregas de prototipos funcionales que serán
retroalimentadas, para identificar falencias y
aprovechar las fortalezas encontradas. Cada
semana, hay dos encuentros, uno donde se
realizan actividades de seguimiento y otras,
mediante la aplicación del “Flipped Learning” se
dicta la teoría propia de las metodologías ágiles y
de los elementos de desarrollo que se buscan
afianzar durante el curso. El Flipped Learning,
indica que la teoría de la clase será estudiada por
parte de los estudiantes en su tiempo
independiente, para en las horas de clase resolver
las dudas y realizar ejercicios prácticos.
Finalmente, el componente virtual, permitirá ver
los contenidos teóricos, para la aplicación del
Flipped
Learning.
Pero
también
tiene
herramientas colaborativas enfocadas a la
comunicación e interacción de los estudiantes, a
través de foros, wikis y tableros de tareas. Por
último, tiene un componente de repositorio de
versiones de código, en donde se va a ir subiendo
el prototipo funcional que será entregado en cada
interacción.
Conclusiones
En las tendencias educativas del uso de
estrategias de aprendizaje activo sobre el
aprendizaje tradicional, como lo es el aprendizaje
colaborativo o el aprendizaje basado en proyectos,
cada individuo es el principal responsable de su
aprendizaje pero, además, influye en el
aprendizaje de sus compañeros. Por ello, se puede
establecer una relación natural con las
metodologías agiles, sus principios y valores, que
resaltan la importancia de los individuos y sus
interacciones para el correcto desarrollo de un
proyecto de software.
Los casos de éxito demuestran que la relación
entre las metodologías ágiles y el aprendizaje
basado en proyectos, se convierte en una
estrategia de enseñanza válida, principalmente en
cursos de desarrollo de software, pero también en
cursos de otra índole, en donde se puedan realizar
proyectos divididos en diferentes etapas.
La propuesta de este artículo se basa en las
posibilidades que ofrece la unión de las
metodologías ágiles con el ámbito educativo pero,
adicionalmente, responde a la necesidad de
formar personas con conocimientos en el área de
desarrollo de software, utilizando los ambientes
virtuales de aprendizaje como un medio para que
los cursos puedan llegar a un mayor número de
estudiantes. Además, se debe permitir el uso de
diferentes herramientas que se adapten a las
necesidades tanto de los estudiantes como de los
cursos.
Referencias
Bendix, L., & Magnusson, B. (2008). Teaching Software
Development Using Extreme Programming, 166–189.
Bunse, C., Feldmann, R., & Dörr, J. (2004). Agile methods in
software engineering education. Extreme Programming
and Agile Processes in Software Engineering, 284–293.
Retrieved
from
http://www.springerlink.com/index/E0D5RPYLHFFF0N30.
pdf
Capgemini, Sogeti, & Hp. 2014. World Quality Report
2013-14,
1–64.
Retrieved
from
http://www.capgemini.com/resources/world-quality-rep
ort-2013-14
Cubric, M. (2013). An agile method for teaching agile in
business schools. International Journal of Management
Education,
11(3),
119–131.
doi:10.1016/j.ijme.2013.10.001
Del Bianco, V., & Sassaroli, G. (2003). Agile teaching of an
agile software process. Proceedings of the 4th
International Conference on Extreme Programming and
Agile Processes in Software Engineering, 402–405.
Retrieved
from
http://portal.acm.org/citation.cfm?id=1763948
Hon A., C. W.,(2004). The agile teaching/learning
methodology and its e-Learning platform. Lecture Notes
in Computer Science (including Subseries Lecture Notes
in Artificial Intelligence and Lecture Notes in
Bioinformatics),
3143,
11–18.
Retrieved
from
http://www.scopus.com/inward/record.url?eid=2-s2.0-3
5048819538&partnerID=40
Lembo, D., & Vacca, M. (2012). Project Based Learning +
Agile Instructional Design = EXtreme Programming based
Instructional Design Methodology for Collaborative
Teaching, 1–24.
McKinney, D., & Froeseth, J. (2004). Agile CS1 Labs: eXtreme
Programming Practices in an Introductory Programming
Course. Extreme Programming …, 164–174. Retrieved
from
http://tocs.ulb.tu-darmstadt.de/8733295.pdf\nhttp://lin
k.springer.com/chapter/10.1007/978-3-540-27777-4_17
Melnik, G., & Maurer, F. (2003). Introducing Agile Methods
in Learning Environments: Lessons Learned. Extreme
Programming and Agile Methods-XP/Agile Universe,
172–184. doi:10.1007/978-3-540-45122-8_20
Martí, J. , Heydrich, M. , Rojas, M. & Hernandez, A.
Aprendizaje basado en proyectos: una experiencia de
innovación docente. Revista Universidad EAFIT 46: 11-21
Rawsthorn P. (2005). Agile Methods of Software Engineering
should Continue to have an Influence over Instructional
Design Methodologies.
http://www.rawsthorne.org/bit/docs/RawsthorneAIDFinal.p
df
Rebolledo, S. 2010. Aprendizaje Basado en Proyectos.
Innovación y Experiencias Educativas 26.
Spundak, M. 2014 Mixed agile/traditional project
management methodology – reality or illusion? 27th
IPMA World Congress. Procedia - Social and Behavioral Sciences
119 ( 2014 ) 939 – 948
Twidale, M. B., & Nichols, D. M. (2013). 2 . AGILE METHODS
FOR AGILE UNIVERSITIES, 27–48.
Washington, A. N., Ph, D., Burge, L., Ph, D., Mejias, M.,
Jean-pierre, K., & Knox, Q. A. (2015). Improving
Undergraduate Student Performance in Computer
Science at Historically Black Colleges and Universities
(HBCUs) through Industry Partnerships. SIGCSE Bulletin,
203–206.
Zapater, M., Malagón, P., De Goyeneche, J. M., & Moya, J. M.
(2013). Project-based learning and agile methodologies
in electronic courses: Effect of student population and
open
Issues.
Electronics,
17(2),
82–88.
doi:10.7251/ELS1317082Z
Incorporando SEMAT en un una metodología Ágil, para equipos
distribuidos.
D.E. Brown
Intelligent Applications Hatchery, LLC., Los Angeles, Estados Unidos.
W.A. Arévalo
Corporación Cidenet, Medellín, Colombia.
J.A. Jimenez
Universidad Nacional de Colombia, Medellín, Colombia.
Resumen
En el manejo de un proyecto con colaboración
entre Cidenet de Colombia y IA Hatchery de
California EEUU, se usó un sistema web para
coordinar y planear el trabajo. CloudForge de
CollabNet, CloudForge utiliza TeamForge y fue
adaptado para incorporar los Alfa y sus estados.
Como TeamForge permite la incorparación de
campos personalizados, se implementó los Alfa y
sus estados acorde con lo establecido por SEMAT.
Al asignar una tarea ésta utiliza un “Artifacts”. El
proyecto se implementó con “Trackers” de varios
tipos para planear y rastrear el progreso en cada
tarea. A las tareas de planificación del negocio, de
organización de los trabajos y las técnicas se les
asignó los Alfa que les pertenece.
Abstract
The project with colaboration between Cidenet in
Colombia and IA Hatchery in California USA, we
used web based system with purpouse to
coordinate and planning the work,
CloudForge
from CollabNet, CloudForge use TeamForge, we
adapt it to build the Alphas and their states.
TeamForge let us use personalized items, we
implement the Alphas and their states acording
with SEMAT. When we assign a task this use an
Artifacts. Our project implemented multiples
Trackers to planning and following the progress for
each task. Activities like business planning,
techniques and works organization we assigned
their respective Alpha.
Trabajo colaborativo
Teamforge
Es una herramienta de gestión de proyectos para
mejorar la productividad de toda la organización y
su velocidad de desarrollo. Esta herramienta
permite conectar equipos distribuidos, les dota de
herramientas y procesos a escala que beneficien
el negocio. Manteniendo los más altos estándares
de gobierno y cumpliendo siempre con la
seguridad IP (Collabnet, 2015).
Provee a los equipos de una visibilidad
centralizada a través de todo el ciclo de vida de los
desarrollos. Asimismo, ayuda a controlar el acceso
con base en la asignación de roles.
Adicionalmente, integra las mejores herramienta
tanto libres como comerciales, para brindar
trazabilidad en cualquier momento del proyecto.
Todo esto brinda una visibilidad del proyecto de
extremo, que permite optimizar y perfeccionar el
proceso de desarrollo, así como apoyar sus
necesidades de administración y cumplimiento.
Esta herramienta se adapta a la metodología de
desarrollo que se éste utilizando, sea cascada, ágil
o cualquier otra (Collabnet, 2015).
El núcleo de SEMAT
SEMAT (Software Engineering Method and Theory)
es un nuevo estándar de la OMG. Es un conjunto
de elementos que son universales para todos los
esfuerzos de ingeniería de software. Los estados
definidos para sus elementos, en el núcleo son un
instrumento para el razonamiento sobre el
progreso y la salud de un proyecto de desarrollo
de software, independiente del método utilizado
para el mismo (Jacobson et all, 2013).
El núcleo de SEMAT ayuda a los profesionales a
entender dónde están, señalan lo que deben
hacer a continuación, y sugerir lo que deben
mejorar y dónde. Además, proporciona una base
común para comprender y describir las similitudes
y diversidades de las prácticas de ingeniería de
software, a través de un conjunto universal de
elementos llamados alfas. (Jacobson et all, 2013).
Los Alfas son los conceptos centrales del núcleo
de SEMAT. Utilizan un enfoque orientado a objetos
para identificar las dimensiones típicas de los
proyectos de ingeniería de software. Cada alfa
representa una dimensión clave y se dividen en
tres áreas diferentes, que centran la atención en
un proyecto y son: los clientes, las soluciones y el
esfuerzo (Jacobson et all, 2013).
Antecedentes
Trabajo Colaborativo y Distribuido
En el mundo actual la tecnología es un factor clave
en la comunicación tanto personal como
corporativa. Actualmente, la industria del
software se está enfrentando a un cambio en la
forma de desarrollar software, el cual es conocido
como desarrollo distribuido de software (DSD, por
sus siglas en inglés). Este cambio crea situaciones
de las cuales las organizaciones pueden
beneficiarse, y retos a los que deben adaptarse.
Esta tendencia implica la separación de los
procesos de desarrollo y sus colaboradores en
diferentes localizaciones geográficas, lo cual
conlleva a que los desarrolladores deban
enfrentarse a dificultades en la interacción y
coordinación de sus actividades. Esto se debe a la
poca o nula interacción cara a cara entre los
desarrolladores, que es causada por la distancia
entre los desarrolladores que participan en
proyectos conjuntos. Para
hacer posible la interacción remota y síncrona en
DSD, los trabajadores tienen que hacer uso de
herramientas de comunicación tales como la
mensajería instantánea y el teléfono. Sin embargo
éstas han sido reportadas como fuentes
constantes de interrupciones, las cuales causan
efectos negativos en la realización de tareas.
(Palacio, et all, 2014).
Para buscar una mejor interacción y además llevar
un control de las actividades de los
desarrolladores, existen herramientas de gestión
que informan de las tareas asignadas y permiten
hacer el seguimiento del avance de este trabajo,
con informes detallados de las tareas y actividades
de cada desarrollador (Collabnet, 2015).
No obstante estas herramientas no integran la
aplicación de los elementos del núcleo de Semat.
Para ello, se escogió TeamForge, una herramienta
de Collabnet, que permite integra la gestión de
proyectos ágiles y facilita la personalización de las
características y tópicos a tener en cuenta para la
gestión y seguimiento del proyecto.
La adecuación de Team Forge
Elementos creados en la adecuación de
TeamForge
i. Un Tracker especial en TeamForge para cada
Alpha de SEMAT usando.
a) Nombre = Semat Alpha + “_Tracker”.
ii.Un campo especial para ¨Semat State¨ en
cada Tracker para manejar el progreso.
a) Nombre del tracker: Semat State.
iii. Carpetas Asignadas a los Alpha para los
distintos Proyectos.
a) Nombre de la Carpeta = Semat Alpha
instanciado en cada proyecto.
iv. Un campo de selección múltiple para la
lista de cosas que debe cumplir cada Alpha.
Ese campo fue añadido como un nuevo
campo en todos los Trackers.
a) Nombre del Tracker: Semat Alpha
Checklist.
v. El Alpha ¨Work¨ fue dividido en
sub-carpetas de ¨Work¨:
¨Sprint¨
y ¨Design¨ para manejar el diseño en detalle
de cada sprint.
vi. Se manejó en la nube de CloudForge, los
proyectos conjuntos de los dos empresa.
vii. Se escribieron reportes especiales en
TeamForge para el progreso de los
proyectos.
Tabla 1.
Semat
Figura 1. Encabezado de un Artifact en work_Tracker
Cada uno de estos artefactos se componen de un conjunto
de campos que permiten la administración y seguimiento
del proyecto. Para ellos deben ser configurados acorde con
las necesidades especificas de cada uno de estos. Dentro de
estos campos se incluyen los campos creados acorde con lo
presentado en la tabla 1.
La figuras 2 y 3, nos muestra los campos que componen el
artefacto y que se requieren para la configuración del
proyecto.
Figura 2 Campos del artefacto Work_Tracker.
Incorporación de Alfas y estados SEMAT en
TeamForge.
Teamforge
Ejemplo
Construcción
Temaforge
Alfa
Regla
Opportunity
_Tracker
Semat Alpha +
_Tracker”
Estado
Tracker
Opportunity
Tracker:
Identified
Tracker State
= Semat
State
Folder
Opportunity
Folder:
Opportunity
Alfa
Tracker
Opportunity
Estado
Tracker
Viable
Opportunity_Tr
acker
Tracker State
= Viable
La administración de los proyectos se realiza con base en
Semat, y la adecuación de los Artifacts de Teamforge,
permiten tener la visibilidad del proyecto y ofrecen un
seguimiento apropiado y adecuado para los proyectos en los
que se implementó.
Esta configuración se implementó en Teamforge utilizando
las herramientas provistas por la plataforma para ello. La
figura 1, muestra una interfaz de configuración de la
solución en la herramienta.
Con la implementación de los Alfa y sus Estados para la
construcción de los Artefactos en Teamforge, se logró un
adecuado seguimiento a cada una de las actividades del
proyecto. Adicionalmente, permitió generar una mejor
visibilidad del cumplimiento de lo Alfa y genera un estado de
compromiso con el equipo de trabajo para incorporar y
construir los proyectos con base en la estructura que ofrece
Semat. Dentro del trabajo futuro se plantea la medición de
la satisfación del equipo con la estrategia incorporada y la
toma de decisiones con base en las sugerencias recibidas
por cada uno de los miembros del equipo.
Referencias
Jacobson, I, Ng, P.W, McMahon, P.E., Spence, I &
Lidman, S. 2013. The Essence of Software
Engineering: Applying the SEMAT Kernel. In
Pearson edcation.
Palacio, R.R., Morán, A.L. & González V.M. 2014.
Soporte al inicio de colaboración en el desarrollo
distribuido de software mediante esferas de
trabajo colaborativas. In Sistemas y Computación
18(4): 787-808.
Collabnet.
2015.
In
http://www.collab.net/products/teamforge
line

Memorias 2015 - LASES - Latin American Software Engineering

Transcripción

Documentos relacionados

analisis critico de metodologias usadas en el proceso de