representación de los principios del manifiesto Ágil en el...

Representación de los principios del Manifiesto Ágil en el núcleo de

Semat

Daniel Esteban Yepes Palacio

Universidad Nacional de Colombia

Facultad de Minas, Departamento de Ciencias de la Computación y de la Decisión

Medellín, Colombia

2017

II Representación de los principios del manifiesto ágil en el núcleo de Semat.

Representación de los principios del Manifiesto Ágil en el núcleo de

Semat

Daniel Esteban Yepes Palacio

Tesis presentada como requisito parcial para optar al título de:

Magister en Ingeniería—Ingeniería de Sistemas

Director:

Ph.D. Carlos Mario Zapata Jaramillo

Línea de Investigación:

Ingeniería de Software

Grupo de Investigación:

Lenguajes Computacionales

Universidad Nacional de Colombia

Facultad de Minas, Departamento de Ciencias de la Computación y de la Decisión.

Medellín, Colombia

2017

Contenido III

A mi familia y todas las demás personas que

me acompañaron de una u otra forma en este

proceso de constante aprendizaje.

IV Representación de los principios del manifiesto ágil en el núcleo de Semat. Título de la tesis o trabajo de investigación

Agradecimientos Al docente Carlos Mario Zapata Jaramillo que ha sido inspirador en este proceso, tanto

personal como profesionalmente. Por su paciencia, dedicación y acompañamiento en

este proceso.

Resumen y Abstract V

Resumen

El manifiesto ágil busca un balance entre la satisfacción del cliente, las entregas

tempranas y continuas de producto funcionando y la adaptación al cambio. El manifiesto

ágil contiene cuatro valores y 12 principios que guían los métodos de desarrollo ágil de

software y se plantea como una alternativa a los métodos basados en planes.

Semat (Software Engineering Method and Theory) es una iniciativa que nace como

respuesta a un llamado a la acción para resolver muchos problemas que se tienen en la

ingeniería de software, como la carencia de una base teórica sólida, la separación de la

industria y la academia y la carencia de evaluación y validaciones experimentales

creíbles. Como resultado de la iniciativa se propone un estándar para poder representar

cualquier esfuerzo de la ingeniería de software en un terreno común, con elementos

ampliamente aceptados, validados y que se pueden extender a usos específicos.

Con el creciente uso de los métodos ágiles de desarrollo, varios autores intentan aplicar

los principios del manifiesto a diferentes campos como el desarrollo de sistemas

embebidos, el proceso de líneas de productos de software o la transición de métodos

tradicionales a métodos ágiles. En estas aplicaciones se evidencia que los principios del

manifiesto ágil se aplican de forma subjetiva, ya que se enuncian en lenguaje natural y no

se representan en un lenguaje formal y estándar en la ingeniería de software y, debido a

su falta de representación en un terreno común de la ingeniería de software, son difíciles

de llevar del contexto de desarrollo ágil a otros diferentes contextos.

En esta Tesis de Maestría se propone una representación de los 12 principios del

manifiesto ágil, haciendo uso de los elementos del núcleo de Semat y, así, poder

representarlos en un terreno común, para que se puedan implementar en diferentes

VI Representación de los principios del manifiesto ágil en el núcleo de Semat. Título de la tesis o trabajo de investigación

contextos, restando subjetividad a los principios y pudiendo evaluar diferentes prácticas y

métodos respecto de los principios del manifiesto ágil. Dado que el núcleo de Semat

carece de mecanismos para expresar restricciones, se propone una nueva sintaxis

basada en OCL (en inglés, lenguaje de restricción de objetos). Además, se propone una

validación por medio de representaciones en Semat existentes sobre métodos ágiles de

desarrollo.

Palabras clave: Manifiesto Ágil, Semat, Representación, Desarrollo ágil de

Software, Principios.

Resumen y Abstract VII

Abstract Agile Manifesto is intended to balance customer satisfaction, early and continuous

delivery of working software, and adaptation to change. Agile Manifesto comprises four

values and 12 principles for guiding agile software development methods as an

alternative to plan-based methods.

Semat (Software Engineering Method and Theory) is an initiative created to answer a call

for action for solving several problems software engineering has—e.g., the lack of widely

accepted theoretical basis, the gap between industry practice and academic research,

and the lack of credible experimental assessment and validation. As a result of such

initiative, its authors propose a standard for representing any software engineering

endeavor in a common ground, with validated, widely-agreed elements, and extensible for

specific usages.

The growing use of agile development methods leads to some authors to use agile

manifesto principles in several fields—e.g., development of embedded systems, software

product lines, and translation of traditional methods into agile methods. As evidenced by

such usage, the agile manifesto principles are subjectively applied—since they are

specified in natural language instead of a formal, standard software engineering

language—, and they are difficult to insert into the agile development context—since they

lack a software engineering common ground representation.

In this M.Sc. Thesis, we propose a representation of the 12 agile manifesto principles by

using the Semat Essence kernel elements. We aim to represent such principles in a

common ground to be implemented in different contexts and avoid subjective

interpretation. We also aim to assess different practices and methods regarding the agile

manifesto principles. We propose a new syntax based on OCL (Object Constraint

VIII Representación de los principios del manifiesto ágil en el núcleo de Semat. Título de la tesis o trabajo de investigación

Language) for the Semat kernel, since it lacks mechanisms for restrictions. We also

propose a validation based on current Semat-based representations of agile development

methods.

Keywords: Agile Manifesto, Semat, Representation, Agile software development,

principles.

Contenido IX

Contenido

Pág.

Resumen ............................................................................................................................. V

Lista de figuras ................................................................................................................. XI

Lista de tablas ................................................................................................................ XIV

1. Introducción .............................................................................................................. 151.1 Justificación ..................................................................................................... 151.2 Planteamiento del problema ............................................................................ 161.3 Objetivo General .............................................................................................. 16

1.3.1 Objetivos específicos ............................................................................ 161.4 Metodología ..................................................................................................... 17

1.4.1 Fase de exploración .............................................................................. 171.4.2 Fase de desarrollo ................................................................................ 201.4.3 Fase de validación ................................................................................ 211.4.4 Fase transversal ................................................................................... 23

1.5 Estructura de la tesis ....................................................................................... 24

2. Marco teórico ............................................................................................................ 252.1 Semat (Software Engineering Method and Theory) ........................................ 25

2.1.1 Alfas ...................................................................................................... 252.1.2 Espacios de Actividad ........................................................................... 302.1.3 Competencias ....................................................................................... 332.1.3.2 Niveles de Competencia ....................................................................... 342.1.4 Lenguaje OCL en Semat ...................................................................... 352.1.5 Otros elementos del núcleo de Semat .................................................. 35

2.2 El manifiesto ágil .............................................................................................. 372.2.1 Los valores del manifiesto ágil .............................................................. 382.2.2 Los principios del manifiesto ágil .......................................................... 38

3. Antecedentes. ........................................................................................................... 40

4. Propuesta de solución ............................................................................................. 474.1 Representación de los principios del manifiesto ágil en el núcleo de Semat. . 47

4.1.1 Principio 1 ............................................................................................. 474.1.2 Principio 2 ............................................................................................. 494.1.3 Principio 3 ............................................................................................. 514.1.4 Principio 4 ............................................................................................. 524.1.5 Principio 5 ............................................................................................. 544.1.6 Principio 6 ............................................................................................. 57

X Representación de los principios del manifiesto ágil en el núcleo de Semat. Título de la tesis o trabajo de investigación

4.1.7 Principio 7 ............................................................................................. 604.1.8 Principio 8 ............................................................................................. 614.1.9 Principio 9 ............................................................................................. 634.1.10 Principio 10 ........................................................................................... 654.1.11 Principio 11 ........................................................................................... 674.1.12 Principio 12 ........................................................................................... 69

5. Validación ................................................................................................................. 715.1 Validación principio 1 ....................................................................................... 715.2 Validación principio 2 ....................................................................................... 735.3 Validación principio 3 ....................................................................................... 765.4 Validación principio 4 ....................................................................................... 785.5 Validación principio 5 ....................................................................................... 805.6 Validación principio 6 ....................................................................................... 895.7 Validación principio 7 ....................................................................................... 935.8 Validación principio 8 ....................................................................................... 965.9 Validación principio 9 ....................................................................................... 965.10 Validación principio 10 ..................................................................................... 995.11 Validación principio 11 ................................................................................... 1005.12 Validación principio 12 ................................................................................... 104

6. Conclusiones y recomendaciones ....................................................................... 1086.1 Conclusiones ................................................................................................. 1086.2 Recomendaciones ......................................................................................... 110

Bibliografía ..................................................................................................................... 111

Contenido XI

Lista de figuras Pág.

Figura 1-1: Prácticas y productos de trabajo para identificación del área problemática . 18Figura 1-2: Prácticas y actividades para identificación del área problemática. ............... 18Figura 1-3: Prácticas y productos de trabajo para la revisión crítica de la literatura. ....... 19Figura 1-4: Prácticas y actividades para la revisión sistemática de la literatura. ............. 19Figura 1-5: Prácticas y productos de trabajo para formulación de hipótesis. ................... 20Figura 1-6: Prácticas y actividades para la formulación de hipótesis. .............................. 21Figura 1-7: Prácticas y productos de trabajo para validación de hipótesis. ..................... 22Figura 1-8: Prácticas y actividades para la validación de hipótesis. ................................ 22Figura 1-9: Prácticas y actividades para la fase transversal ............................................ 23Figura 1-10: Práctica y productos de trabajo para la fase transversal ............................ 23Figura 2-1: Alfas del núcleo de Semat. ........................................................................... 26Figura 2-2: Espacios de Actividad del núcleo de Semat. ................................................ 31Figura 2-3: Competencias del núcleo de Semat. ............................................................ 33Figura 3-1: Evidencias asociadas del SPL al manifiesto ágil. ......................................... 41Figura 3-2: El énfasis y los desafíos de los sistemas embebidos en el manifiesto ágil. Parte 1/2 ........................................................................................................................... 42Figura 3-3: El énfasis y los desafíos de los sistemas embebidos en el manifiesto ágil. Parte 2/2 ........................................................................................................................... 43Figura 3-4: Propuesta de modelo ágil. ............................................................................ 44Figura 3-5 : Mapeo de prácticas ágiles con el manifiesto ágil. ........................................ 46Figura 4-1: Principio 1 del manifiesto ágil en el núcleo de Semat. .................................. 48Figura 4-2: Principio 2 del manifiesto ágil en el núcleo de Semat. .................................. 49Figura 4-3: Principio 3 del manifiesto ágil en el núcleo de Semat. .................................. 51Figura 4-4: Principio 4 del manifiesto ágil en el núcleo de Semat. Parte 1/2 .................. 52Figura 4-5: Principio 4 del manifiesto ágil en el núcleo de Semat. Parte 2/2 .................. 53Figura 4-6: Principio 5 del manifiesto ágil en el núcleo de Semat. Parte 1/3 .................. 55Figura 4-7: Principio 5 del manifiesto ágil en el núcleo de Semat. Parte 2/3 .................. 56Figura 4-8: Principio 5 del manifiesto ágil en el núcleo de Semat. Parte 3/3 .................. 57Figura 4-9: Principio 6 del manifiesto ágil en el núcleo de Semat. Parte 1/3 .................. 58Figura 4-10: Principio 6 del manifiesto ágil en el núcleo de Semat. Parte 2/3 ................ 59Figura 4-11: Principio 6 del manifiesto ágil en el núcleo de Semat. Parte 3/3 ................ 60Figura 4-12: Principio 7 del manifiesto ágil en el núcleo de Semat. ................................ 61Figura 4-13: Principio 8 del manifiesto ágil en el núcleo de Semat. ................................ 62Figura 4-14: Principio 9 del manifiesto ágil en el núcleo de Semat. Parte 1/2 ................ 64

XII Representación de los principios del manifiesto ágil en el núcleo de Semat. Título de la tesis o trabajo de investigación

Figura 4-15: Principio 9 del manifiesto ágil en el núcleo de Semat. Parte 2/2 ................. 65Figura 4-16: Principio 10 del manifiesto ágil en el núcleo de Semat. ............................... 66Figura 4-17: Principio 11 del manifiesto ágil en el núcleo de Semat. Parte 1/2 ............... 68Figura 4-18: Principio 11 del manifiesto ágil en el núcleo de Semat. Parte 2/2 ............... 69Figura 4-19: Principio 12 del manifiesto ágil en el núcleo de Semat. ............................... 70Figura 5-1: Representación del principio 1 del manifiesto ágil en el núcleo de Semat. ... 71Figura 5-2: Mapeo de productos de trabajo de Scrum a los alfas. ................................... 72Figura 5-3: Representación de un incremento en Scrum. ................................................ 72Figura 5-4 Representación del principio 2 del manifiesto ágil en el núcleo de Semat. .... 73Figura 5-5: Mapeo de productos de trabajo de Scrum a los alfas. ................................... 74Figura 5-6: Mapeo de las actividades de Scrum con los espacios de actividad. ............ 75Figura 5-7: Representación de product backlog en Scrum. ............................................. 75Figura 5-8: Representación del principio 3 del manifiesto ágil en el núcleo de Semat. ... 76Figura 5-9: Mapeo de productos de trabajo de Scrum a los alfas. ................................... 77Figura 5-10: Representación de un incremento en Scrum. .............................................. 77Figura 5-11: Representación del principio 4 del manifiesto ágil en el núcleo de Semat. . 78Figura 5-12: Mapeo de productos de trabajo de Scrum a los alfas. ................................. 79Figura 5-13: Representación de product backlog en Scrum. ........................................... 79Figura 5-14: Principio 5 del manifiesto ágil en el núcleo de Semat. Parte 1/3 ................. 80Figura 5-15: Mapeo de productos de trabajo de Scrum a los alfas. ................................. 81Figura 5-16: Mapeo de las actividades de Scrum con los espacios de actividad. .......... 82Figura 5-17: Representación de Sprint backlog en Scrum. .............................................. 83Figura 5-18: Principio 5 del manifiesto ágil en el núcleo de Semat. Parte 2/3 ................. 83Figura 5-19: Mapeo de las actividades de Scrum con los espacios de actividad. .......... 84Figura 5-20: Mapeo de productos de trabajo de Scrum a los alfas. ................................. 85Figura 5-21: Representación de Sprint Planning Meeting en Scrum. .............................. 86Figura 5-22: Principio 5 del manifiesto ágil en el núcleo de Semat. Parte 3/3 ................. 86Figura 5-23: Mapeo de las actividades de Scrum con los espacios de actividad. ........... 87Figura 5-24: Mapeo de productos de trabajo de Scrum a los alfas. ................................. 88Figura 5-25: Representación de Sprint Retrospective en Scrum. .................................... 89Figura 5-26: Principio 6 del manifiesto ágil en el núcleo de Semat. Parte 1/2 ................. 90Figura 5-27: Mapeo de las actividades de Scrum con los espacios de actividad. .......... 91Figura 5-28: Representación de Daily Scrum en Scrum. ................................................. 91Figura 5-29: Principio 6 del manifiesto ágil en el núcleo de Semat. Parte 2/2 ................. 92Figura 5-30: Mapeo de las actividades de Scrum con los espacios de actividad. .......... 93Figura 5-31: Principio 7 del manifiesto ágil en el núcleo de Semat. ................................. 94Figura 5-32: Mapeo de productos de trabajo de Scrum a los alfas. ................................. 94Figura 5-33: Mapeo de las actividades de Scrum con los espacios de actividad. ........... 95Figura 5-34: Representación de Sprint Review en Scrum. .............................................. 95Figura 5-35: Representación de Increment en Scrum. ..................................................... 96Figura 5-36: Principio 9 del manifiesto ágil en el núcleo de Semat. Parte 1/2 ................. 97Figura 5-37: Principio 9 del manifiesto ágil en el núcleo de Semat. Parte 2/2 ................. 98Figura 5-38: Mapeo de las actividades de Scrum con los espacios de actividad. .......... 98Figura 5-39: Principio 10 del manifiesto ágil en el núcleo de Semat. ............................... 99

Contenido XIII

Figura 5-40: Mapeo de productos de trabajo de Scrum a los alfas. .............................. 100Figura 5-41: Principio 11 del manifiesto ágil en el núcleo de Semat. ............................ 101Figura 5-42: Mapeo de productos de trabajo de Scrum a los alfas. .............................. 102Figura 5-43: Mapeo de las actividades de Scrum con los espacios de actividad. ....... 103Figura 5-44: Representación de Sprint Planning Meteting en Scrum. .......................... 104Figura 5-45: Principio 12 del manifiesto ágil en el núcleo de Semat. ............................ 105Figura 5-46: Mapeo de las actividades de Scrum con los espacios de actividad. ....... 106Figura 5-47: Mapeo de productos de trabajo de Scrum a los alfas. .............................. 107

Contenido XIV

Lista de tablas Pág.

Tabla 1-1: Otros elementos del núcleo de Semat. Adaptación de [1]. Parte 1/2. ............ 36Tabla 1-2: Otros elementos del núcleo de Semat. Adaptación de [1]. Parte 2/2. ............ 37

Capítulo 1 15

1. Introducción

1.1 Justificación Las empresas de desarrollo de software están adoptando métodos agiles como marco de

trabajo para sus procesos de desarrollo de software, debido a las bondades que ofrecen

[2]. En la mayoría de ocasiones en las cuales se implementan estos métodos, se cambia

todo el proceso de desarrollo de software [10], haciendo que las transiciones sean un

poco más difíciles para estas organizaciones, pues deben invertir en un cambio de

mentalidad para todo el equipo de desarrollo.

Si se tuviera el manifiesto ágil expresado en un terreno común de la ingeniería de

software, las transiciones desde métodos basados en planes y la incorporación de

modelos de calidad a métodos ágiles sería más clara en los equipos de desarrollo de

software y se podrían suplir los aparentes vacíos [2-5] que establecen los métodos ágiles

respecto de los basados en planes. Además, sería posible comparar diferentes procesos

con los principios del manifiesto ágil para mejorar o evaluar dichos procesos.

Para la búsqueda de ese terreno común se plantea el uso de la iniciativa que se propone

en Semat (Teoría y método de la ingeniería de Software, por sus siglas en inglés) que se

estableció como estándar según el OMG (Object Managment Group) [6] y brinda la

posibilidad de tener un terreno común para todos los esfuerzos de la ingeniería de

software, por medio de un núcleo en el cual todo proceso de desarrollo de software se

puede representar.

Por ello, en esta Tesis de Maestría se propone una representación de los principios del

manifiesto ágil en un terreno común para permitir una transición más clara de diferentes

procesos hacia los principios del manifiesto ágil, permitiendo comparar, combinar o

reutilizar diferentes partes para mejorar estos procesos. Se emplea el núcleo de Semat,

puesto que se trata de un nuevo estándar para representar cualquier esfuerzo en

ingeniería de software y se complementa dicha representación con la adición de

16 Repr

Representación de los principios del manifiesto ágil en el núcleo de Semat. Título de la tesis o trabajo de investigación

restricciones en OCL, pues en la actualidad el núcleo no posee un mecanismo que

permita el manejo de restricciones.

1.2 Planteamiento del problema Los métodos ágiles de desarrollo de software surgen con la búsqueda de un balance

entre la satisfacción del cliente, una rápida respuesta ante el cambio y entregas rápidas

del producto funcionando [1]. Métodos ágiles de desarrollo de software como Scrum,

eXtreme Programming (XP) y Feature Drive Development (FDD) tienen sus puntos en

común en el manifiesto ágil.

Con base en el manifiesto ágil, se encuentra que hay autores que intentan replicar, usar y

acomodar sus principios en diferentes procesos, cómo el desarrollo en sistemas

embebidos [9], el proceso en líneas de productos de software (en inglés SPL) [8] o la

transición de métodos basados en planes a métodos ágiles [10]. El análisis de estos

procesos es difícil, al no tener el manifiesto ágil en un terreno común que permita

comparar los diferentes enfoques con los principios ágiles. Esto limita, en muchas

ocasiones, la interpretación de los principios del manifiesto ágil a juicio de los

investigadores.

En esta Tesis de Maestría se busca dar respuesta al siguiente interrogante, ¿Cómo se

pueden representar los principios del manifiesto ágil en un terreno común de la ingeniería

de software?

1.3 Objetivo General Proponer una representación de los principios del manifiesto ágil empleando para ello los

diferentes elementos del núcleo de Semat.

1.3.1 Objetivos específicos

1. Establecer los principios del manifiesto ágil que se van a abordar.

2. Analizar los principios del manifiesto ágil con base en los diferentes elementos

de la ingeniería de software.

3. Representar los principios del manifiesto ágil empleando los elementos del

núcleo de Semat.

Capítulo 1 17

4. Proponer un mecanismo para validar la representación de los elementos del

manifiesto ágil en el núcleo de Semat.

5. Validar la representación propuesta con el mecanismo seleccionado.

1.4 Metodología Para cumplir con los objetivos propuestos en esta Tesis, se elige una metodología que

incluye cuatro fases que apoyarán este proceso: la fase de exploración, la fase de

desarrollo, la fase de validación y una fase transversal. Estas fases se explican a

continuación.

1.4.1 Fase de exploración Se hace una revisión exhaustiva de la literatura referente a las representaciones

propuestas de los principios del manifiesto ágil. Con esta fase de exploración se busca

cumplir con los objetivos específicos 1 y 2 así:

Objetivo específico 1:

Establecer los principios del manifiesto ágil e identificar elementos de la ingeniería de

software.


Analizar los principios del manifiesto ágil en los diferentes elementos de la ingeniería de

software.

La fase de exploración se representa en las Figuras 1-1, 1-2, 1-3 y 1-4.

18 Repr


Figura 1-1: Prácticas y productos de trabajo para identificación del área problemática.

Fuente: Elaboración propia.

Figura 1-2: Prácticas y actividades para identificación del área problemática.


Capítulo 1 19

Figura 1-3: Prácticas y productos de trabajo para la revisión crítica de la literatura.


Figura 1-4: Prácticas y actividades para la revisión sistemática de la literatura.


20 Repr


1.4.2 Fase de desarrollo Se definen las reglas para la construcción y se realiza la representación de los principios

del manifiesto ágil (MA) en el núcleo de Semat. Con esta fase se apoya el cumplimiento

del objetivo específico 3.


Representar los principios del manifiesto ágil empleando los elementos del núcleo de

Semat.

La fase de desarrollo se representa en las Figuras 1-5 y 1-6.

Figura 1-5: Prácticas y productos de trabajo para formulación de hipótesis.


Capítulo 1 21

Figura 1-6: Prácticas y actividades para la formulación de hipótesis.


1.4.3 Fase de validación Se realiza una revisión de diferentes mecanismos que se puedan utilizar para validar la

representación propuesta y se utiliza un mecanismo para realizar la validación de la

representación. Esta fase apoya los objetivos específicos 4 y 5:


Proponer un mecanismo para validar la representación de los elementos del

manifiesto ágil en el núcleo de Semat.


Validar la representación propuesta con el mecanismo seleccionado.

La fase de validación se representa en las Figuras 1-7 y 1-8.

22 Repr


Figura 1-7: Prácticas y productos de trabajo para validación de hipótesis.


Figura 1-8: Prácticas y actividades para la validación de hipótesis.


Capítulo 1 23

1.4.4 Fase transversal A lo largo del proyecto se entregan informes constantemente sobre avances de la Tesis,

los cuales se representan en productos de trabajo.

La fase transversal se representa en las Figuras 1-9 y 1-10.

Figura 1-9: Prácticas y actividades para la fase transversal


Figura 1-10: Práctica y productos de trabajo para la fase transversal


24 Repr


1.5 Estructura de la tesis Esta Tesis de Maestría se estructura de la siguiente manera: En el Capítulo 2 se

presenta el Marco teórico en el que se presenta Semat (Software Engineering Method

and Theory), el manifiesto ágil y OCL (Object Constraint Language); en el Capítulo 3 se

describen los antecedentes sobre las representaciones del manifiesto ágil, en los cuales

se presentan la necesidad de tener una representación del manifiesto ágil en un terreno

común; en el Capítulo 4 se propone la representación de los 12 principios del manifiesto

ágil; en el Capítulo 5 se presenta la validación de la representación propuesta y,

finalmente, en el Capítulo 6 se presentan las conclusiones, recomendaciones y el trabajo

futuro que puede derivar de esta Tesis de Maestría.

Capítulo 2 25

2. Marco teórico

2.1 Semat (Software Engineering Method and Theory)

Semat es una iniciativa que fundaron en 2009 Ivar Jacobson, Bertrand Meyer y Richard

Soley. Esta iniciativa surge luego de reconocer que la ingeniería de software sufre

prácticas inmaduras [7] y ciertos problemas específicos. Con Semat se buscan dos

objetivos fundamentales para la ingeniería de software: el primer objetivo es “encontrar

un núcleo de elementos que se acepten ampliamente” y el segundo “definir una base

teórica sólida”.

Para el primer objetivo se definió un núcleo para poder establecer un terreno común a

todos los esfuerzos de la ingeniería de software. Para este núcleo se definen tres

enfoques fundamentales definidos como “cosas con las que siempre se trabaja”

(explicadas en la Sección 1.1.1), “cosas que siempre se hacen” (explicadas en la Sección

1.1.2) y las competencias (explicadas en la Sección 1.1.4). Con los anteriores elementos

y con algunos adicionales se realiza la construcción de la representación del manifiesto

ágil en un terreno común.

2.1.1 Alfas Los Alfas (en inglés Alpha, Abstract-Level Progress Health Attribute) se definen como

“Cosas con las que siempre se trabaja”, debido a que representan los conceptos clave en

cualquier esfuerzo de ingeniería de software [1]. Los alfas, además, permiten medir la

salud y el progreso de todos los esfuerzos de ingeniería de software mediante el uso de

estados, cada uno de los cuales tiene su lista de chequeo para su asegurar su

cumplimiento.

26 Repr


Los Alfas se representan en tres áreas de interés: el cliente, la solución y el esfuerzo

(véase la Figura 2.1).

Figura 2-1: Alfas del núcleo de Semat.

El área de interés del cliente incluye lo que se necesita comprender sobre los

interesados. Esta área del conocimiento incluye los siguientes alfas:

Alfa Oportunidad: Se define como “el conjunto de circunstancias que hacen apropiado

desarrollar o cambiar un sistema de software” [1]. La oportunidad representa lo que el

equipo debe conocer sobre las necesidades de los interesados, ayuda a entender los

requisitos y provee una justificación de la necesidad del nuevo sistema de software.

Los estados del alfa oportunidad son los siguientes:

Identificada: Una oportunidad de negocio, social o comercial se identificó y se

puede solucionar por medio de un sistema de software.

Con solución requerida: La necesidad de una solución basada en software se

confirmó.

Capítulo 2 27

Con valor establecido: El valor del éxito de la solución se estableció.

Viable: Está de acuerdo en que la solución trata la oportunidad y se puede

producir rápidamente y de manera económicamente viable para que sea exitosa.

Tratada: Una solución que se produjo trata de manera demostrada la

oportunidad.

Con beneficio acumulado: El uso operacional o la venta de la solución está

creando beneficios tangibles. Alfa Interesados: “La gente, los grupos de gente u organizaciones que afectan o se

afectan con el sistema de software” [1]. Este alfa es el que provee la oportunidad y es la

principal fuente para la construcción y estructuración de los requisitos. Además usa el

sistema de software y apoya al equipo.

Los estados del alfa Interesados son los siguientes: Reconocidos: El interesado se identificó.

Representados: El mecanismo para involucrar a los interesados se convino y el

representante de los interesados se nombró.

Involucrados: El representante de los interesados se involucra activamente en el

trabajo y cumple sus responsabilidades.

De acuerdo: El representante de los interesados está de acuerdo.

Satisfechos para despliegue: Las expectativas mínimas del representante de

los interesados se lograron.

Satisfechos en uso: El sistema cumple o excede en su cumplimiento con lo

mínimo de las expectativas de los interesados.

El área del interés de la solución contiene los alfas requisitos y sistema de software.

Estos representan las necesidades plasmadas en los requisitos e involucran la

implementación, construcción, pruebas, despliegue y mantenimiento de los sistemas de

software.

28 Repr


Alfa Requisitos: Se define como “lo que el sistema de software debería hacer para tratar

la oportunidad y satisfacer a los interesados” [1].

El alfa requisitos posee los siguientes estados:

Concebidos: La necesidad para un nuevo sistema de software se convino.

Acotados: El propósito y extensión de un nuevo sistema es claro.

Coherentes: Los requisitos proveen una descripción consistente de las

características esenciales de un nuevo sistema de software.

Aceptables: Los requisitos describen un sistema que es aceptable para los

interesados.

Tratados: Suficientes requisitos se trataron para satisfacer la necesidad de un

sistema de software en cierto sentido que es aceptable para los interesados.

Cumplidos: Los requisitos se trataron completamente para satisfacer la

necesidad de un nuevo sistema. Alfa Sistema de Software: “Es un sistema compuesto por software, hardware y datos

que proporciona valor por la ejecución de software” [1].

El Alfa Sistema de Software posee los siguientes estados:

Con arquitectura seleccionada: Una arquitectura se seleccionó para tratar los

riesgos técnicos y cualquier restricción organizacional.

Demostrable: Una versión ejecutable del sistema está disponible para demostrar

que la arquitectura se ajusta al propósito y apoya las pruebas.

Usable: El sistema es usable y tiene todas las características de calidad

requeridas de un sistema operacional.

Listo: El sistema (como un todo) se aceptó para desplegarlo en un ambiente en

vivo.

Operacional: El sistema está en uso en un ambiente en vivo.

Retirado: Al sistema ya no se le brinda mantenimiento.

Capítulo 2 29

El área de interés de esfuerzo comprende todo lo relacionado con el equipo y la forma en

como ellos enfocan su trabajo. Esta área comprende los alfas: trabajo, forma de trabajo y

equipo.

Alfa Trabajo: Comprende todo lo que el equipo realiza para reunir los objetivos de

producir un sistema de software que cumpla con los requisitos y trate la oportunidad que

presentan los interesados. El trabajo es una guía para las prácticas que componen la

forma de trabajo del equipo. El alfa trabajo puede pasar por los siguientes estados:

Iniciado: El trabajo se solicitó.

Preparado: Todas las precondiciones para comenzar el trabajo se reunieron.

Comenzado: El trabajo está avanzando.

Bajo control: El trabajo está yendo bien, los riesgos están bajo control y los

niveles de productividad son suficientes para lograr un resultado satisfactorio.

Concluido: El trabajo para producir resultados satisfactorios se concluyó.

Cerrado: Todas las tareas restantes se completaron y el trabajo se cerró

oficialmente. Alfa Forma de Trabajo: Es el conjunto de herramientas y prácticas que usa un equipo

para guiar y apoyar su Trabajo.

El alfa forma de trabajo posee los siguientes estados:

Con principios establecidos: Los principios y las restricciones que conforman la

forma de trabajo se establecieron.

Con bases establecidas: Las prácticas y herramientas clave que conforman los

fundamentos de la forma de trabajo se seleccionan y alistan para su uso.

En uso: Algunos miembros del equipo están usando y adaptando la forma de

trabajo.

30 Repr


En su lugar: Todos los miembros están usando la forma de trabajo para realizar

sus tareas.

Trabajando bien: La forma de trabajo está trabajando bien para el equipo.

Retirado: La forma de trabajo ya no está en uso para el equipo.

Alfa Equipo: Comprende un grupo de personas que se involucran activamente en el

desarrollo, mantenimiento entrega o soporte de un software específico.

El alfa equipo posee los siguientes estados:

Sembrado: La misión del equipo es clara y la habilidad necesaria para el

crecimiento del equipo está en su sitio.

Formado: El equipo se forma con personas suficientemente comprometidas para

comenzar la misión.

Colaborando: Los miembros del equipo están trabajando juntos como una

unidad.

Ejecutando: El equipo está trabajando efectivamente y eficientemente.

Suspendido: El equipo ya no es responsable de llevar a cabo su misión.

2.1.2 Espacios de Actividad El núcleo de Semat provee unos espacios de actividad como complemento a los

alfas, definiéndolos como “las cosas que siempre se hacen” en la ingeniería de

software. Estos espacios de actividad ayudan a guiar las actividades en los procesos

de ingeniería de software (véase la Figura 2-2).

Capítulo 2 31

Figura 2-2: Espacios de Actividad del núcleo de Semat.

Los espacios de actividad también corresponden a cada una de las áreas de interés

del cliente, de la solución y del esfuerzo, de la siguiente manera:

Área de interés del cliente: Aquí se encuentran espacios de actividad relacionados

con comprender la oportunidad e involucrar a los interesados.

Explorar posibilidades: Explorar las posibilidades que se presentan con la

creación o mejora de un sistema de software. Incluye el análisis de la oportunidad

y la identificación de los interesados.

Comprender las necesidades del interesado: Involucrarse con los interesados

para entender sus necesidades y asegurar que se producen resultados correctos.

Asegurar la satisfacción del interesado: Compartir los resultados del trabajo

desarrollado con los interesados para conseguir su aceptación del sistema

producido y verificar que la oportunidad se trató exitosamente.

Usar el sistema: Constatar el uso del sistema de software en un ambiente en

vivo y verificar sus beneficios a los interesados.

Área de interés de la solución: Tiene espacios de actividad relacionados con el

desarrollo de una adecuada solución.

32 Repr


Comprender los requisitos: Establecer un entendimiento compartido de lo que

el sistema que se produce debe hacer.

Darle forma al Sistema: Darle forma al sistema de tal manera que sea fácil para

desarrollar, cambiar y mantener y pueda enfrentar las actuales y futuras

demandas. Incluye el diseño y la arquitectura en general del sistema que se

produce.

Implementar el Sistema: Construir el sistema mediante la implementación, las

pruebas e integración de uno o más elementos del sistema. Incluye la solución de

errores y la realización de pruebas unitarias.

Probar el sistema: Verificar que el sistema producido reúne los requisitos de los

interesados.

Desplegar el sistema: Tomar el sistema probado y hacerlo disponible para su

uso fuera del equipo de desarrollo.

Operar el sistema: Apoyar el uso del sistema de software en un ambiente en

producción.

Área de interés del esfuerzo: En esta área de interés, el equipo se tiene que formar y

progresa en su trabajo de acuerdo con la forma de trabajo.

Prepararse para hacer el trabajo: Preparar al equipo y su ambiente de trabajo.

Entender y comprometerse a completar el trabajo.

Coordinar Actividades: Coordinar y dirigir el trabajo del equipo. Incluye planear

el trabajo y reconfigurar el equipo.

Apoyar el Equipo: Ayudar a los miembros del equipo a ayudarse, colaborar y

mejorar su forma de trabajo.

Rastrear el progreso: Medir y evaluar el progreso que hace el equipo.

Detener el trabajo: Parar el esfuerzo de ingeniería de software y entregar las

responsabilidades del equipo.

Capítulo 2 33

2.1.3 Competencias Se trata de complementar los alfas y los espacios de actividad para dar una visión de las

capacidades requeridas para llevar a cabo el esfuerzo de ingeniería de software (véase

la Figura 2-3).

Figura 2-3: Competencias del núcleo de Semat.

Competencias de cliente: Comprenden la habilidad de demostrar un claro

entendimiento del negocio y aspectos técnicos del dominio y tener la habilidad de

comunicar de forma precisa los puntos de vista de los interesados.

Representación de los interesados: Esta competencia abarca la habilidad de

recolectar, comunicar y balancear las necesidades de otros interesados y

representar exactamente sus puntos de vista.

Competencias de solución: Comprenden las habilidades relacionadas con la captura y

análisis de los requisitos y la construcción y operación de un sistema de software que los

cumpla.

Análisis: Esta competencia abarca la habilidad de entender las oportunidades y

su relación con las necesidades de los interesados, para transformarlas en un

conjunto de requisitos entendibles y consistentes.

34 Repr


Desarrollo: Esta competencia abarca la habilidad de diseñar y programar

sistemas efectivos de software siguiente los estándares y normas convenidas por

ellos.

Pruebas: Esta competencia abarca la habilidad de probar un sistema, verificando

que es usable y que reúne los requisitos.

Competencias de esfuerzo: Comprende las habilidades para organizar y gestionar el

trabajo.

Liderazgo: Esta competencia permite a una persona inspirar y motivar a un grupo

de personas para lograr una conclusión exitosa de su trabajo y a reunir sus

objetivos.

Gestión: Esta competencia reúne la habilidad de coordinar, planear y hacer

seguimiento al trabajo que hace el equipo.

2.1.3.2 Niveles de Competencia

Asistir: Demuestra un entendimiento básico de los conceptos y puede seguir

instrucciones.

Aplicar: Es capaz de aplicar conceptos en un contexto simple mediante la

aplicación rutinaria de la experiencia ganada hasta la fecha.

Dominar: Capaz de aplicar conceptos en muchos contextos y tiene la experiencia

para trabajar sin supervisión.

Adaptar: Capaz según su juicio de aplicar “cuándo” y “cómo” los conceptos clave

en contextos más complejos. Puede apoyar a otros a aplicar los conceptos.

Innovar: Un experto reconocido, capaz de extender los conceptos a nuevos

contextos y a inspirar a otros.

Capítulo 2 35

2.1.4 Lenguaje OCL en Semat

Object Constraint Language OCL es un lenguaje usado para especificar

restricciones en el contexto de modelos orientados a objetos. Es equivalente a

lógica de primer orden sobre los objetos. Se usa principalmente con diagramas

UML para complementar la especificación de los objetos modelados [13]. En la

especificación de Semat se establecen dos casos para el uso de OCL: las

Invariants que describen reglas bien formadas para los elementos, principalmente

descritos tanto en lenguaje informal como con expresiones OCL, mientras que las

Additional Operations se usan para cualquier operación adicional necesaria

cuando expresan las reglas bien formadas. De igual manera, se describen tanto

en lenguaje formal como con expresiones OCL.

Las restricciones Temporales de OCL [12] proponen una combinación de un

patrón y un alcance. Un alcance es la parte de la ejecución de un sistema sobre la

que el patrón se mantiene.

Los patrones propuestos son absence, universality, existence, bounded existence,

precedence, chain precedence, chain response y response.

El alcance tiene cinco tipos; globally, before Q, after Q, between Q and R, after Q

until R.

2.1.5 Otros elementos del núcleo de Semat

La sintaxis gráfica en Semat contiene elementos que pueden representar aspectos

específicos de componentes de la ingeniería de software, permitiendo representar

métodos y prácticas [1]. A continuación, se detallan otros elementos necesarios para la

representación.

36 Repr


Tabla 2-1: Otros elementos del núcleo de Semat. Adaptación de [1]. Parte 1/2.

Elemento Representación Descripción

Actividad

Una actividad define uno o más tipos de

partes de trabajo y guía como se deben

realizar.

Patrones

Un patrón es una descripción de una

estructura en una práctica.

Productos de

trabajo

Son artefactos de valor y relevancia

para el área de esfuerzo de la ingeniería

de software. Aquí se pueden

representar documentos, código fuente,

pruebas y ejecutables, entre otros.

Manifiesto de

producto de

trabajo

El manifiesto de producto de trabajo se

utiliza para conectar un alfa con un

producto de trabajo. Esta conexión se

representa con una línea horizontal con

un diamante relleno en la punta que

conecta el alfa.

Asociación de

actividad

(“parte de”)

La asociación de Actividad (“parte de”)

se utiliza para conectar espacios de

actividad con actividades. Se representa

con una línea horizontal con un

diamante relleno en el extremo en el

que se conecta con el espacio de

actividad. Cuando se conectan varias

actividades, todas deben quedan en el

mismo nivel.

Capítulo 2 37

Tabla 2-2: Otros elementos del núcleo de Semat. Adaptación de [1]. Parte 2/2.

Elemento Representación Descripción

Asociación de

actividad (no

“parte de”)

Una asociación de actividad (no “parte

de”) se utiliza para conectar dos

actividades y/o espacios de actividad.

Se visualiza como una línea sólida

(puede ser una línea curva) con una

punta triangular. La línea puede tener

uno o más segmentos conectados.

Asociación de

patrón

La asociación de patrón se utiliza para

conectar el patrón con sus elementos

asociados. Se visualiza como una línea

sólida con un diamante en la punta en la

cual se conecta el patrón. La línea tiene

origen en un círculo en el que se pone

el nombre de la asociación y del que se

conectan los elementos asociados al

patrón con una línea sólida por cada

elemento.

2.2 El manifiesto ágil

En el año 2001 se reúnen 17 críticos de los procesos de desarrollo de software bajo la

convocatoria de Kent Beck. En esta reunión tratan la forma de desarrollar software y

llegan a un término denominado “métodos ágiles” para describir métodos más ligeros en

comparación con los métodos tradicionales. Así, llegan a un acuerdo para establecer

cuatro valores fundamentales para los métodos ágiles y doce principios que deben

seguir, los cuales se describen en las Secciones 2.2.1 y 2.2.2 respectivamente.

38 Repr


2.2.1 Los valores del manifiesto ágil

El manifiesto ágil expresa lo siguiente:

“Estamos descubriendo formas mejores de desarrollar software tanto con nuestra propia

experiencia como ayudando a terceros. Mediante este trabajo se aprende a valorar:

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 el seguimiento de un plan.

Esto es, aunque se valoran los elementos de la derecha, se valoran más los de la

izquierda” [11].

2.2.2 Los principios del manifiesto ágil

Los 12 principios del manifiesto ágil son:

• “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

• Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia en el periodo más corto posible.

• Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

• Los proyectos se desarrollan en torno de individuos motivados. Hay que darles el entorno y el apoyo que necesitan y confiarles la ejecución del trabajo.

• El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

• El software funcionando es la medida principal de progreso. • Los procesos ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

Capítulo 2 39

• La atención continua a la excelencia técnica y al buen diseño mejoran la agilidad. • La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial. • Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados. • A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a

continuación, ajustar y perfeccionar su comportamiento en consecuencia” [11].

Capítulo 3 40

3. Antecedentes.

Aunque no existen representaciones gráficas sobre el manifiesto ágil, varios autores

intentan hacer mapeos entre el manifiesto ágil y procesos para buscar lograr una unión

entre procesos y objetivos.

Da Silva et al. [8] realizan un estudio que pretende brindar un mejor entendimiento entre

las líneas de producto de Software (SPL) y los principios del manifiesto ágil. Para esto,

tratan de enfocar las SPL y el agilísimo desde diferentes perspectivas: un caso de

mapeo, un caso de estudio y la opinión de expertos. Así, aclaran que sólo una

perspectiva es insuficiente para establecer las relaciones. En este estudio se plantea que

estos enfoques se realizan con evidencias analíticas y empíricas, lo que da a entender

que es un enfoque subjetivo. Da Silva et al. [8] toman el contexto de las SPL y lo mapean

a los principios del manifiesto ágil (véase la Figura 3-1).

Capítulo 3 41

Figura 3-1: Evidencias asociadas del SPL al manifiesto ágil. Tomado de [8]

Además, se evidencia la necesidad de establecer una representación del manifiesto ágil

en un terreno común para poder realizar una comparación mucho más clara entre los

elementos que componen las SPL y el manifiesto ágil y así tratar de dar un criterio más

objetivo de las evidencias que se presentan [8].

Kaisti et al. [9] pretenden establecer un Agile System Development. Los autores

establecen que el manifiesto ágil se enfoca en el desarrollo de software ágil, pero deja

42 Repr


otros componentes como el hardware y las actividades de la ingeniería mecánica por

fuera del alcance. Kaisti et al. [9] hacen un recuento de los principios ágiles, tratan de

establecer en qué componentes se están enfocando y, desde la perspectiva de los

sistemas embebidos, cuál es el desafío al que se enfrentan al tratar de establecer un

Agile System Development (véanse las Figuras 3-2 y 3-3).

Figura 3-2: El énfasis y los desafíos de los sistemas embebidos en el manifiesto ágil.

Tomado de [9]. Parte 1/2

Capítulo 3 43

Figura 3-3: El énfasis y los desafíos de los sistemas embebidos en el manifiesto

ágil. Tomado de [9]. Parte 2/2

La mayoría de documentos sobre la aproximación del manifiesto ágil con sistemas

embebidos incluyen reportes de experiencias [9], lo que hace que este tipo de estudios

sea muy subjetivo y refleje opiniones del punto de vista particular. En este punto es

donde podría tomar gran valor una representación en un terreno común del manifiesto

ágil, en el cual se puede acercar menos subjetivamente interpretaciones del manifiesto

ágil y poder establecer o modificar esta representación en un posible manifiesto ágil para

sistemas embebidos.

Para Popli et al. [10], los enfoques tradicionales del desarrollo de software se están

reemplazando con métodos ágiles. Los autores hacen un estudio de los diferentes

enfoques tradicionales (espiral y cascada entre otros) y el enfoque ágil, para establecer

los puntos fundamentales de ambos enfoques, con el fin de establecer un modelo de

mapeo de los modelos de desarrollo de software tradicional hacia los modelos ágiles. El

resultado del estudio de los ciclos de vida establece siete componentes principales [10]:

• Team Formation by good recruitment policy (TFR)

• Goal Building cycle with quality analyst, business analyst, and customer (GBC)

• Effort and budget estimation (EBE)

• Coding and testing activities with Communication (CTC)

44 Repr


• Demonstrations in review with feedback (DRF)

• Risk evaluation and correction (REC)

• Satisfaction for all parties (SFP)

Los anteriores siete componentes se establecen como parte fundamental en los entornos

ágiles (véase la Figura 3-4) y sirven como base para realizar una función de mapeo.

Figura 3-4: Propuesta de modelo ágil. Tomado de [10].

Luego del análisis del modelo, los autores establecen una función de mapeo para ayudar

a una organización existente que use métodos tradicionales a adaptarse a métodos

ágiles, construyendo las ecuaciones 2.1 y 2.2. La función de mapeo mostrada en la

ecuación 2.2 tiene los siguientes componentes:

MF: Función de Mapeo.

T: Equipos grandes a equipos pequeños.

J: Grandes tareas a pequeñas historias.

Capítulo 3 45

I: Iteraciones largas a sprints pequeños.

F: Ciclos de largos feedback a feedback instantáneos.

D: Entregas tardías a pequeñas y rápidas entregas.

M: Largas reuniones a reuniones diarias y cortas.

TG: Testing tardío a evaluación dirigida con testing.

MO: Dos monitores a una terminal para programación por pares.

E: Estimar líneas de código a estimación por story points.

B: Project manager a un enfoque de no jefe.

CE: Coordinación efectiva.

CE = Factores implícitos+ Factores explícitos (3.1)

MF = (T, J, I, F,D,M, TG,MO, E, B, CE) (3.2)

Popli et al. establecen que, con el modelo anterior, se puede hacer un mapeo y convertir

cualquier modelo tradicional a un modelo ágil. Lo anterior se realiza a juicio de expertos,

pues al tener un terreno común para el manifiesto ágil, se podría ayudar en este mapeo y

se podría hacer más sencillo el hallazgo de los parámetros para realizar una función de

mapeo.

Singh et al. [2] también realizan un mapeo con base en un estudio sobre la gestión del

conocimiento en entornos agiles en las empresas de la india. Para este artículo, realizan

un mapeo basado en los valores del manifiesto ágil y tratando de asociar varios métodos

ágiles por medio de sus elementos (véase la Figura 3-5).

46 Repr


Figura 3-5 : Mapeo de prácticas ágiles con el manifiesto ágil. Tomado de [2].

Los anteriores antecedentes reflejan la necesidad de establecer el manifiesto ágil en un

terreno común, debido a que permitirá combinar, evaluar y clarificar procesos en torno de

la agilidad. Además, no se tiene una representación formal del manifiesto ágil en

términos de elementos de la ingeniería de software y todo lo que se pueda hacer en torno

del manifiesto ágil está sujeto a la interpretación subjetiva.

Capítulo 4 47

4. Propuesta de solución

4.1 Representación de los principios del manifiesto ágil en el núcleo de Semat.

En este Capítulo se propone la representación de los principios del manifiesto ágil en el

núcleo de Semat. Para la construcción de esta representación se buscaron los elementos

principales de ingeniería de software que contenía cada uno de los principios para,

posteriormente, relacionarlos y completarlos con restricciones por medio de OCL. Cabe

aclarar que el núcleo de Semat actualmente no tiene un mecanismo para representar las

restricciones y, por ello, en esta Tesis se propone OCL como mecanismo para esa

representación.

A continuación, se presentan cada uno de los doce principios del manifiesto ágil en el

núcleo de Semat, su explicación y las razones de la construcción.

4.1.1 Principio 1

“Nuestra mayor prioridad es satisfacer al cliente mediante entrega temprana y continua

de software con valor”. En la Figura 4-1 se representa este principio.

48 Repr


Figura 4-1: Principio 1 del manifiesto ágil en el núcleo de Semat.


En este primer principio del manifiesto ágil se da principal atención al “software con valor”

y a la forma en la que de éste se hace “entrega temprana y continua”. Con lo anterior se

evidencia que están presentes dos elementos principales en la ingeniería de software; el

primero hace referencia al alfa sistema de software. Para que este alfa tenga valor para

el cliente tiene que estar en un estado usable, listo u operacional según la lista de

chequeo de cada uno de estos estados del alfa. Estas restricciones en los estados se

representan con OCL (véase Figura 4-1).

El segundo alfa involucrado es la oportunidad. Para establecer un sistema de software

con valor para el cliente, la oportunidad de un nuevo sistema de software debe ser clara,

por lo cual el alfa debe estar mínimo en un estado de valor establecido; si no se identifica

la oportunidad del sistema de software en un valor establecido (como mínimo), no es

posible sustentar que el sistema de software, es un sistema de software con valor.

El producto de trabajo “software funcionando” es otro elemento importante en este

principio. En un entregable se materializan los alfas y sobre él recae el principio cuando

hace referencia que se debe entregar de forma temprana y continua. Para hacer

Capítulo 4 49

referencia a “forma temprana y continua” es necesario completar por medio de OCL esta

característica particular. En OCL se representa la frecuencia de entrega como una

variable invariante y la cual se establece que debe ser constante para toda la

aplicabilidad del método ágil, es decir, cuando el tiempo sea mayor que 0 y, además, el

periodo relacionado debe estar entre 0 y N, donde se establece que N es una variable en

días. Al decir que esto aplica para todo t>0 se establece que se aplicará de forma

temprana y el periodo entre 0 y N establece que será de forma continua. El producto de

trabajo debe ser el resultado de una actividad que es parte del espacio de actividad

desplegar el sistema. Para poder tener software funcionando es necesario involucrar el

espacio de actividad desplegar el sistema.

4.1.2 Principio 2

“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los

procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”.

En la Figura 4-2 se representa este principio.



50 Repr


El tema central en este principio son los requisitos cambiantes, la adaptación al cambio

en cuanto a requisitos en cualquier etapa del desarrollo. En este principio se especifica

que esos requisitos cambiantes brindarán una ventaja competitiva al cliente.

El alfa requisitos es fundamental en este principio, debido a que este alfa es el que se

retroalimenta constantemente por medio de un producto de trabajo. Este producto de

trabajo se actualiza en cualquier momento de la aplicabilidad del método de desarrollo (lo

cual se expresa en la Figura 4-2 por medio de OCL). A su vez, el producto de trabajo se

actualiza por medio de una actividad del dominio del cliente, la cual pertenece al espacio

de actividad de comprender los requisitos.

El producto de trabajo que compone al alfa Requisitos se asocia con una restricción por

medio de OCL. Esta restricción establece temporalidad en el producto de trabajo,

indicando que, en cualquier momento de la aplicabilidad del método de desarrollo, el

producto de trabajo se actualizará. Esta actualización la hará algún rol asociado con el

área de interés esfuerzo.

OCL tiene los nombres reservados de temp, eventually, isCalled y globally. Temp hace a

referencia a la inclusión del tiempo en la restricción. Eventually muestra un adverbio de

tiempo en el cual se realizará la acción. isCalled hace referencia a lo que se hará con

acción. Update se refiere al tipo de acción que se llevará a cabo sobre el producto de

trabajo y finalmente globally indica que la restricción expresada en OCL se aplicará

durante todo el uso del método de desarrollo.

“Aceptamos que los requisitos cambien, incluso en las etapas tardías del desarrollo” se

evidencia en la representación en Semat con la posibilidad de actualizar o modificar el

producto de trabajo en cualquier instante.

Capítulo 4 51

4.1.3 Principio 3

“Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con

preferencia al periodo más corto posible”. Este principio se representa en la Figura 4-3.



Lo que es parte fundamental en el principio tres son las entregas de software funcional,

estableciendo reglas de tiempo en las que se debe entregar este software funcional. Por

lo anterior, se evidencia la presencia del alfa sistema de software en un estado mínimo

usable (debido a que se establece que el software debe ser funcional). Nuevamente,

para llegar a este estado funcional se debe entregar un producto de trabajo que es

resultado de una actividad dependiente de un espacio de actividad desplegar el sistema.

La actividad la debe realizar un rol del espacio de actividad esfuerzo. El producto de

trabajo se acompaña con restricciones en OCL para establecer el tiempo. Temp indica

que es una restricción de temporalidad en OCL; la palabra reservada always indica que

esto se deberá cumplir siempre durante toda la aplicabilidad del método.

52 Repr


4.1.4 Principio 4

“Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto”. Este principio se representa en las Figuras 4-4 y 4-5.

Figura 4-4: Principio 4 del manifiesto ágil en el núcleo de Semat. Parte 1/2


Para este principio se involucran personas de negocio y personas del equipo, las cuales

deben estar en actividades conjuntas durante todo el proyecto. Según Fowler [11] esta

actividad se enfoca en el proceso de requisitos en los métodos ágiles, debido a que no se

esperan unos requisitos detallados desde el principio del proyecto, sino, que se espera

por medio de la interacción diaria ir acortando brechas en el entendimiento de los

requisitos que tienen los desarrolladores respecto de las personas de negocio. Por la

anterior razón se involucra el espacio de actividad comprender las necesidades de los

interesados, la cual tiene una actividad que se debe ejecutar diariamente y que alimente

el producto de trabajo de requisitos. En esta actividad y en la construcción de este

producto de trabajo interactuarán tanto personas de negocio como desarrolladores. La

Capítulo 4 53

temporalidad diaria de la actividad se representa, por medio de OCL, con la palabra

temp; always indica que esa actividad se ejecutará siempre, invariablemente con un

periodo de un día; finalmente, globally indica que se ejecutará esto siempre durante toda

la ejecución del proyecto.

Adicional a la representación realizada en la Figura 4-4, se determinan unos estados

necesarios mínimos en los que se deben estar los alfas para cumplir el propósito del

principio, con base en las listas de chequeo de los estados de cada uno de los alfas.

Para el alfa equipo, el estado mínimo necesario es colaborando; para el alfa trabajo, el

estado mínimo necesario es bajo control; finalmente, para el alfa interesados, el estado

mínimo es de acuerdo. El producto de trabajo representa los tres alfas en sus estados

(véase la Figura 4-5).



54 Repr


4.1.5 Principio 5

“Los proyectos se desarrollan en torno de individuos motivados. Hay que darles el

entorno y el apoyo que necesitan y confiarles la ejecución del trabajo”. Este principio se

representa en las Figuras 4-6, 4-7 y 4-8.

Este principio empieza con dos elementos claves como los individuos y la motivación. El

principio sugiere que los individuos que participan en los proyectos deben ser personas

motivadas, por lo cual en cada una de las actividades que se realizan en torno del trabajo

deben inducir motivación, inyectada en varias ocasiones en los proyectos ágiles por

medio de la competencia coaching. Esa motivación se complementa por medio de “darles

el entorno y el apoyo que necesitan y confiarles la ejecución del trabajo” por lo cual se

involucran espacios de actividad coordinar actividades y prepararse para hacer el trabajo,

cuando se menciona “darles el entorno”. Además, está presente el espacio de actividad

apoyar al equipo cuando se menciona “el apoyo que necesitan”. Estos espacios de

actividad ayudan a los alfas trabajo, forma de trabajo y equipo a estar en los estados

esperados.

Este principio se representa con tres diagramas relacionando los espacios de actividad y

alfas. En la Figura 4-6 se muestra el alfa trabajo en un estado bajo control, que se logra

mediante el espacio de actividad coordinar actividades y una actividad específica en la

cual se debe aplicar coaching. La actividad genera un producto de trabajo en el cual

trabaja un rol del área de interés esfuerzo.

Capítulo 4 55



En la Figura 4-7 se relaciona el alfa forma de trabajo en un estado mínimo de en su lugar

(estado que también podría tomar el valor de trabajando bien), estos estados se logran

mediante un producto de trabajo que se logra con una actividad del espacio de actividad

prepararse para hacer el trabajo. La actividad relacionada debe involucrar una

competencia de coaching para inducir la motivación a los individuos. Por medio de OCL

se representa que el alfa forma de trabajo debería tomar los estados de en su lugar o

trabajando bien.

56 Repr




En la Figura 4-8 se complementa la representación del principio cinco, relacionando el

alfa equipo, el cual debe alcanzar un estado de colaborando o ejecutando, representado

por medio de OCL. Los anteriores estados se logran por medio de una actividad del

espacio de actividad apoyar al equipo; la actividad, de igual manera, se debe realizar con

competencia de coaching para mantener la motivación del equipo.

Capítulo 4 57



4.1.6 Principio 6

“El método más eficiente y efectivo de comunicar información al equipo de desarrollo y

entre sus miembros es la conversación cara a cara”. Este principio se representa en las

Figuras 4-9, 4-10 y 4-11.

Este principio hace énfasis en la forma más eficiente y efectiva de comunicación con (y

entre) los equipos de desarrollo. La comunicación en los equipos se da con el fin de

entender los requisitos y rastrear el progreso del proyecto. Para este principio, entonces,

se identificó la competencia comunicación y los espacios de actividad principales

entender los requisitos y rastrear el progreso. La actividad relacionada con el espacio de

actividad entender los requisitos recibirá como entrada el alfa oportunidad y como salida

estará el alfa requisitos que esté en un estado acotado. La actividad relacionada con el

espacio de actividad rastrear el progreso toma como entrada la forma de trabajo y como

58 Repr


salida estará el equipo en estado mínimo ejecutando. Estas entradas y salidas se

deberán apoyar por medio de la competencia comunicación, que deberá tener un

enfoque cara a cara. Esta representación se muestra en las Figuras 4-9, 4-10 y 4-11,

estableciendo tanto las relaciones entre espacios de actividad y actividad, como el diseño

de las cartas de cada una de las actividades.



Capítulo 4 59


Fuente: Elaboración propia

60 Repr




4.1.7 Principio 7

“El software funcionando es la medida principal de progreso”. Este principio se

representa en la Figura 4-12.

En este principio está presente el software funcionando y la medición del progreso. Para

representar el software funcionando se establece el alfa sistema de software en un

estado operacional; para medir el progreso se utiliza el espacio de actividad rastrear el

Capítulo 4 61

progreso. El producto de trabajo que se utiliza para rastrear el progreso es una

representación del alfa sistema de software y la actividad utiliza este producto de trabajo

en forma de insumo. En esta actividad se debe involucrar un rol que ejecute la actividad.

En comentario OCL se especifica que el producto de trabajo es la principal medida del

progreso.



4.1.8 Principio 8

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de

forma indefinida”. Este principio se representa en la Figura 4-13.

En este principio, el punto principal se refiere a lo que se denomina el “desarrollo

sostenible”. Según Fowler [11], el desarrollo sostenible significa encontrar un ritmo de

trabajo que el equipo pueda sostener en el tiempo y que se mantenga saludable. En las

prácticas asociadas con los procesos ágiles, se espera que los interesados estén en

estado de acuerdo, debido a que los promotores también deben estar en un estado

adecuado para mantener el ritmo constante. El alfa equipo debe estar en un estado

colaborando para mantener un ritmo constante, el cual se debe mantener como mínimo

durante la aplicabilidad del proceso ágil de desarrollo.

62 Repr


En OCL se establece que el ritmo constante se basa en la entrega de productos de

trabajo y ejecución de actividades con una frecuencia constante. La palabra reservada

temp indica que se involucrará temporalidad de OCL en la restricción y always indica que

siempre se debe aplicar la restricción. Primero se presenta la expresión OCL para los

productos de trabajo; aunque se representan sólo dos productos de trabajo, cabe aclarar

que pueden ser más. La expresión dice que para todos los productos de trabajo deberá

existir una frecuencia de entrega, al igual que para todas las actividades. Lo anterior se

deberá aplicar para todo tiempo mayor a 0, es decir, para toda la aplicabilidad del

proceso ágil, complementándolo con la palabra reservada globally.



Capítulo 4 63

4.1.9 Principio 9

“La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad”. Este

principio se representa en las Figuras 4-14 y 4-15.

Según el principio nueve, es fundamental mantener una atención continua a las

competencias técnicas y de diseño para promover la agilidad dentro de los procesos. Lo

que sugiere el principio cuando menciona la excelencia técnica es que en el espacio de

actividad implementar el sistema haya una tarea. Esta tarea se realiza con una

competencia de diseño en el nivel de dominar, adaptar o innovar [1], representado por

medio de OCL. De la misma manera, se aplica para el espacio darle forma al sistema,

involucrando una actividad y la competencia diseño en niveles avanzados como

dominar, adaptar e innovar (véanse las Figuras 4-14 y 4-15).

64 Repr




Capítulo 4 65



4.1.10 Principio 10

“La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial”.

Este principio se representa en la Figura 4-16.

El principio 10 se enfoca completamente en la simplicidad. Fowler [11] dice que todos los

métodos ágiles tienen un gran componente de minimalismo y se deben mantener simples

en todos sus aspectos. Fowler dice que en todo método ágil se debe incluir sólo lo que

todos necesitan en vez de lo que alguien necesite.

Los métodos se representan por medio de los alfas y los productos de trabajo. Al tener

pocos productos de trabajo representan simplicidad en todo el dominio del método. La

simplicidad se muestra también desde el área de interés cliente (alfas de color verde),

pasando por el área de interés solución (alfas de color amarillo) hasta el área de interés

66 Repr


esfuerzo (alfas de color azul). Pocos productos de trabajo en cada uno de los alfas

generan simplicidad en la aplicabilidad de los métodos de desarrollo. Por ejemplo, el alfa

forma de trabajo, al tener pocos productos de trabajo, genera pocas reglas para aplicar el

método, lo que genera simplicidad en la forma de trabajo. Las representaciones de los

alfas tienen cardinalidad de 1 hasta n, dónde n debe ser pequeño para mantener la

simplicidad del método ágil (véase Figura 4-16).



Capítulo 4 67

4.1.11 Principio 11

“Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados”.

Este principio se representa en las Figuras 4-17 y 4-18.

Este principio se basa en dos puntos principales, como menciona Fowler [11]. El primero

de ellos es la construcción de buenas arquitecturas, requisitos y diseños emergen desde

el desarrollo iterativo e incremental en vez de planeaciones tempranas. El segundo punto

hace énfasis en que estas propiedades de “emerger” se presentan cuando los equipos

son auto-organizados en su interacción y las reglas del proceso son pocas.

El primer punto se representa en la Figura 4-17. Las arquitecturas, requisitos y diseños

se involucran en el espacio de actividad darle forma al sistema. Para la ejecución de este

espacio actividad se debe tener una competencia alta de diseño, para que puedan ser

“las mejores” y en el producto de trabajo resultante de esta actividad también se deben

involucrar actividades del espacio de actividad coordinar actividades y prepararse para

hacer el trabajo, con competencias trabajo colaborativo y comunicación, que permitan

evidenciar la filosofía de los equipos auto-organizados. Los productos de trabajo

resultantes son representaciones de los alfas sistema de software y requisitos, debido a

que son los que se involucran directamente en las arquitecturas, requisitos y diseños.

68 Repr




La auto-organización de los equipos se refuerza por medio de una actividad relacionada

con el espacio de actividad apoyar al equipo. La actividad de este espacio de actividad

recibe como entrada el alfa forma de trabajo y entrega como salida los alfas requisitos en

un estado coherente y sistema de software en un estado usable. Lo anterior se logra por

medio de las competencias de comunicación y trabajo colaborativo. Esta actividad

siempre debe tener el enfoque de equipo auto-organizado como se muestra en la tarjeta

de la actividad (véase la Figura 4-18).

Capítulo 4 69



4.1.12 Principio 12

“A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a

continuación, ajustar y perfeccionar su comportamiento en consecuencia”. Este principio

se representa en la Figura 4-19.

Este principio se enfoca en inspeccionar la forma de trabajo y retroalimentarla. Sugiere

que los procesos ágiles deben realizar esta labor de forma constante con referencia a

intervalos regulares. En esta labor se involucra el equipo y se centra principalmente en la

70 Repr


“reflexión” que, en forma de competencias, se pueden asociar con una revisión crítica y

una retrospectiva a la forma de trabajo.

Debido a lo anterior, se representa el principio por medio de un alfa forma de trabajo, que

es el que hay que ajustar o perfeccionar. Este alfa tiene su representación en un

producto de trabajo (que puede representar una guía al método que se sigue en el

momento), que se inspecciona con las competencias retrospectiva y revisión crítica en

una actividad. Esta actividad se asocia con una notación en OCL indicando que esta

actividad se debe realizar frecuentemente durante todo el proyecto, de acuerdo con el

OCL temporal. La actividad se ejecuta en un espacio de actividad que se presenta vacío,

debido a que en el núcleo de Semat no se encontró un espacio de actividad acorde con

el alfa forma de trabajo (véase la Figura 4-19).



Capítulo 5 71

5. Validación

En este Capítulo se muestra la validación de los principios del manifiesto ágil en el núcleo

de Semat. Para la validación se buscaron representaciones de métodos ágiles utilizando

los elementos de Semat. en la revisión de la literatura se encontraron dos fuentes [1, 14],

en las cuales los autores presentan una subespecificación de Scrum como framework

que sigue los principios del manifiesto ágil utilizando elementos de Semat.

5.1 Validación principio 1

En el principio 1 se establece un producto de trabajo asociado con un alfa sistema de

software (véase Figura 5-1). En las fuentes [1,14] los autores representan Scrum con un

producto de trabajo llamado incremento o incremento del producto, como se observa en

las Figuras 5-2 y 5-3.

Figura 5-1: Representación del principio 1 del manifiesto ágil en el núcleo de Semat.


72 Repr


Figura 5-2: Mapeo de productos de trabajo de Scrum a los alfas.

Fuente: Tomado de [14] con modificación.

Figura 5-3: Representación de un incremento en Scrum.

Fuente: Tomado de [1].

Capítulo 5 73


En el principio 2 se establece un producto de trabajo asociado con un alfa requisitos y

con una actividad del espacio de actividad entender los requisitos (véase la Figura 5-4).

En las fuentes [1, 14], los autores representan Scrum con el producto de trabajo llamado

product backlog, como se observa en las Figuras 5-5 y 5-7. Además, se presentan las

actividades release planning y sprint planning asociadas con el espacio de actividad

entender los requisitos (véase la Figura 5-6) de forma similar a como se plantea en el

principio 2 planteado en la presente Tesis.

Figura 5-4 Representación del principio 2 del manifiesto ágil en el núcleo de Semat.


74 Repr




Capítulo 5 75

Figura 5-6: Mapeo de las actividades de Scrum con los espacios de actividad.


Figura 5-7: Representación de product backlog en Scrum.


76 Repr



De forma similar al principio 1, en el principio 3 se establece un producto de trabajo

asociado con un alfa sistema de software (véase Figura 5-8), por lo cual se establece de

la misma manera que los autores [1, 14] representan esta parte de Scrum con un

producto de trabajo llamado incremento o incremento del producto como se observa en

las Figuras 5-9 y 5-10.



Capítulo 5 77



Figura 5-10: Representación de un incremento en Scrum.


78 Repr



En el principio 4 se establece un producto de trabajo asociado con el alfa requisitos

(véase Figura 5-11). En las fuentes [1, 14] se presenta Scrum con el producto de trabajo

llamado product backlog como se observa en las Figuras 5-12 y 5-13.



Capítulo 5 79



Figura 5-13: Representación de product backlog en Scrum.


80 Repr



En el principio 5 se establecen tres partes de la representación (véanse las figuras 5-14,

5-18 y 5-22). La primera parte asocia el alfa trabajo con una actividad de un espacio de

actividad coordinar actividades. La segunda parte asocia el alfa forma de trabajo con una

actividad del espacio de actividad prepararse para hacer el trabajo. La tercera parte

asocia el alfa equipo con una actividad del espacio de actividad apoyar al equipo. Cada

una de estas partes se valida (véanse las figuras 5-15, 5-16 5-17, 5-19, 5-20, 5-21, 5-23,

5-24, 5-25) debido a que hay correspondencia entre alfas, productos de trabajo, espacios

de actividad y actividades [1, 14].



Capítulo 5 81



82 Repr




En esta subespecificación de Scrum (véase la Figura 5-17) se representa un subalfa

dependiente del alfa trabajo llamado Sprint. De acuerdo con el planteamiento realizado

para este principio, existirá un producto de trabajo asociado con el alfa trabajo;

indirectamente este producto de trabajo se conoce en Scrum como el Sprint Backlog.

Para completar lo que sugiere el principio, estos elementos deben tener las

características que se plantean en la representación propuesta en esta Tesis.

Capítulo 5 83

Figura 5-17: Representación de Sprint backlog en Scrum.




84 Repr




Capítulo 5 85



La representación realizada para Scrum (véase la Figura 5-21) muestra la asociación del

Sprint Planning Meeting con el espacio de actividad prepararse para hacer el trabajo.

Para Scrum, el Sprint Planning Meeting es una representación de confianza en el equipo,

como lo sugiere el principio al permitir que el alcance del Sprint lo defina el equipo

Scrum. Es claro que la representación propuesta en la especificación es una

subespecificación que se podría completar con la representación propuesta en esta

Tesis.

86 Repr


Figura 5-21: Representación de Sprint Planning Meeting en Scrum.




Capítulo 5 87



88 Repr




La representación realizada para el Sprint Retrospective (véase la figura 5-25) muestra la

asociación de esa actividad con el espacio de actividad apoyar al equipo, elementos que

se pueden representar en el principio 5.

Capítulo 5 89

Figura 5-25: Representación de Sprint Retrospective en Scrum.



En el principio 6 se establecen dos partes de la representación. La primera

representación propuesta de este principio hace referencia a el espacio de actividad

rastrear el progreso y una actividad (véase la Figura 5-26). La segunda parte de la

representación de este principio hace referencia al espacio de actividad comprender las

necesidades de los interesados y una actividad (véase la Figura 5-29). Cada una de

estas partes de la representación del principio 6 se asocia con una representación de las

fuentes [1, 14], relacionando los espacios de actividad con las actividades (véanse las

Figuras 5-27, 5-28 y 5-30).

90 Repr




En las Figuras 5-27 y 5-28 se establece una relación entre el espacio de actividad

rastrear el progreso y una actividad llamada Daily Scrum. Lo anterior representa

parcialmente el principio 6, debido a que las Daily Scrum tiene como uno de sus objetivos

mejorar la comunicación, para lo cual se sugieren reuniones cara a cara entre los

miembros del equipo.

Capítulo 5 91



Figura 5-28: Representación de Daily Scrum en Scrum.


Las Figuras 5-29 y 5-30 tienen una asociación entre el espacio de actividad comprender

las necesidades de los interesados y una actividad. Para la representación de Scrum

(véase la Figura 5-30) se establece que esta actividad es Product Envisioning, la cual es

una reunión entre los interesados y el equipo.

92 Repr




Capítulo 5 93




En el principio 7 hay una asociación entre el sistema de software en estado operacional,

un producto de trabajo, un espacio de actividad llamado rastrear el progreso y una

actividad (véase la Figura 5-31). Esta misma asociación se plantea en las fuentes [1, 14]

al representar Scrum (véanse las Figuras 5-32, 5-33, 5-34 y 5-35).

94 Repr






Capítulo 5 95



Figura 5-34: Representación de Sprint Review en Scrum.


96 Repr


Figura 5-35: Representación de Increment en Scrum.



En la revisión de la literatura no se pudo evidenciar ninguna validación para este principio.


En el principio 9 se establecen dos partes para la representación (véanse las Figuras 5-

36 y 5-37). Ambas partes se validan con la representación de una de las fuentes [14]

(véase la Figura 5-38). Estas partes tienen dos espacios de actividad llamados darle

forma al sistema e implementar el sistema que se asocian con una actividad de Scrum

llamada Development Work. Para esta actividad se deben tener altos niveles de

competencia en desarrollo y conocimiento técnico [11], como lo sugiere el principio 9

propuesto en la presente Tesis.

Capítulo 5 97



98 Repr






Capítulo 5 99


En el principio 10 (representado en la Figura 5-39) se establecen pocos productos de

trabajo asociados con cada uno de los alfas de las áreas de interés. Para la validación

del principio se toma una de las fuentes [14] (véase la figura 5-40) y se cuenta la cantidad

de productos de trabajo asociados con cada uno de los alfas en la representación

realizada para el método, la cual mantiene la condición de que n sea pequeña para

mantener la simplicidad.



100 Representación de los principios del manifiesto ágil en el núcleo de Semat. Título de la tesis o trabajo de investigación




Las representaciones de una de las fuentes [14] (véanse las Figuras 5-42 y 5-43)

muestran los productos de trabajo de los alfas requisitos y sistema de software y la

actividad del espacio de actividad coordinar actividades, las cuales hacen parte de la

representación propuesta en la presente Tesis para el principio 11 (véase la Figura 5-41).

Capítulo 5 101



Capítulo 5 103



En la representación de una de las fuentes [1], que se muestra en la Figura 5-44, hay un

espacio de actividad llamado prepararse para hacer el trabajo, relacionado con el

principio 11, y asociado con la actividad Sprint Planning Meeting la cual, según la

propuesta de la presente Tesis, se debe realizar con las competencias de trabajo

colaborativo y comunicación para llevarlas a cabo.


Figura 5-44: Representación de Sprint Planning Meteting en Scrum.



La segunda fuente hace referencia a la actividad de la retrospectiva del Sprint, la cual se

asocia con el espacio de actividad apoyar el equipo y que, de igual manera, refleja el

sentido del principio. Estas dos representaciones se pueden mapear a la representación

propuesta del principio, debido a su estructura y a las competencias asociadas. Cabe

aclarar que no está claro si la actividad de Retrospectiva del Sprint se debe asociar con

un espacio de actividad apoyar el equipo, debido a que posiblemente la retrospectiva no

solo influya en el equipo, sino también en la forma de trabajo.

En el principio 12 hay una asociación entre el alfa forma de trabajo, un producto de

trabajo, un espacio de actividad y una actividad (véase la Figura 5-45). En una de las

fuentes [14], los autores se refieren a este principio por medio de la actividad Sprint

Retrospective, la cual la asocian con el espacio de actividad rastrear el progreso (véase

la Figura 5-46), el cual en la representación del principio 12 no se usa por las razones

expresadas en la sección 4.1.12. En la Figura 5-47 se muestra el complemento de

validación a este principio, en el cual se establecen los productos de trabajo relacionados

con el alfa forma de trabajo y que se retroalimentan con la actividad Sprint Retrospective.

Capítulo 5 105



Capítulo 5 107



6. Conclusiones y recomendaciones

6.1 Conclusiones A la ingeniería de software le hacía falta un estándar como el propuesto en Semat para

representar cualquier esfuerzo en esta disciplina. La importancia radica en poder hacer

uso de un terreno común para poder comparar, representar, restar subjetividad y tener un

conocimiento común en diversos equipos de trabajo.

Representar los principios del manifiesto ágil en el núcleo de Semat representó un

desafío completo a la labor realizada, debido a que se trató de expresar de una forma

estándar los principios del manifiesto ágil, los cuales actualmente se expresan en

términos informales y que se pueden prestar para diferentes interpretaciones.

En la construcción de los principios del manifiesto ágil con el núcleo de Semat se observó

que las representaciones existentes sobre diversos métodos ágiles aún se quedan cortas

para representar todo el contenido de un método o framework. Falta considerar más

detalles para poder representar la totalidad de un método, por ejemplo competencias y

temporalidad tarjetas de actividades, entre otros.

También se evidenció que es importante agregar la temporalidad a las representaciones

en Semat debido a que muchos de los métodos ágiles hacen especial énfasis en este

tema. En la presente Tesis se hizo, entonces, uso de la temporalidad por medio de OCL

para poder representar estas restricciones de tiempo, lo cual fue muy útil al permitir poder

expresar un poco más a fondo la esencia de cada uno de los principios.

Las competencias ofrecidas en el documento de especificación de Semat parecen

incompletas respecto de las competencias que exigen los principios del manifiesto ágil,

Conclusiones 109

por lo cual aquí se hizo uso de competencias adicionales, requeridas para poder ofrecer

una representación más acertada de cada uno de los principios.

En la representación del principio 12 faltó por definir un espacio de actividad asociado

con un producto de trabajo del alfa forma de trabajo. Al parecer, al núcleo de Semat le

hace falta un espacio de actividad que esté más asociado directamente con el alfa forma

de trabajo. En una de las fuentes [14] se propuso que este espacio de actividad fuera

rastrear el progreso, pero estos espacios de “reflexión” (como lo menciona el enunciado

del principio) no parece tener la intención de rastrear el progreso.

Respecto de los principios del manifiesto ágil, se puede evidenciar que, por ejemplo, los

principios 1 y 3 son muy similares, debido a que involucran casi los mismos elementos,

sólo con unas variaciones en OCL para el principio 3. Aunque sólo se evaluó un método

ágil como Scrum, se evidenció que, al parecer, no cumple con todos los principios del

manifiesto ágil y que métodos basados en planes podrían contener prácticas ágiles.

Aunque no se incluyeron comparaciones con métodos basados en planes, parece ser

que no habría mucha diferencia entre métodos basados en planes y métodos ágiles,

pues parecen tener los mismos componentes y los mismos enfoques básicamente, sólo

que los métodos ágiles prestan mayor atención a que los requisitos puedan cambiar

constantemente y a los cortos periodos en los que se ejecutan las iteraciones.

Al realizar la validación de los principios se evidencia lo útil que pueden llegar a ser las

diferentes representaciones del esfuerzo de ingeniería de software en un terreno común,

ya que se puede hacer un mapeo más claro entre diversos elementos de la ingeniería de

software.

La presente es una propuesta de representación de los principios del manifiesto ágil

utilizando elementos del núcleo de Semat y es de aclarar que faltan detalles más

profundos en la representación de cada uno de los principios del manifiesto ágil. Sin

embargo, las representaciones aquí consignadas constituyen un punto de partida

interesante para poder evaluar los procesos o métodos ágiles con un criterio basado en

un terreno común, para poder comparar, adaptar, evaluar o modificar las formas de

trabajo y así poder aportar en realizar y clarificar un poco los procesos ágiles de


desarrollo de software, que, al plantearse como ágiles, en muchas ocasiones parecieran

carecer un poco de orden.

6.2 Recomendaciones

Semat, al ser una iniciativa con pocos años de estudio, cuenta con pocas

representaciones para diversos métodos ágiles, lo cual dificultó la validación de los

principios, en especial el principio 8. Se recomienda como trabajo futuro plantear diversas

representaciones de diferentes métodos ágiles y comparar y validar contra los principios

del manifiesto ágil.

Además, es conveniente realizar comparaciones de los principios del manifiesto ágil

contra representaciones realizadas en métodos basados en planes, para evaluar que tan

ágiles podrían llegar a ser esos métodos, desde la perspectiva del manifiesto ágil.

En relación con la iniciativa Semat, se recomienda evaluar la inclusión de un espacio de

actividad que se asocie más directamente con el alfa forma de trabajo, que pareciera que

no existe.

Bibliografía [1] Essence –Kernel and Language for Software Engineering Methods. V 1.1, 2015.

[2] A. Singh, K. Singh, and N. Sharma, “Agile knowledge management: a survey of Indian perceptions,” Innov. Syst. Softw. Eng., vol. 10, no. 4, pp. 297–315, 2014.

[3] I. Inayat, S. S. Salim, S. Marczak, M. Daneva, and S. Shamshirband, “A systematic literature review on agile requirements engineering practices and challenges,” Comput. Human Behav., vol. 51, no. 10, pp. 915–929, 2015.

[4] M. Waterman, J. Noble, and G. Allan, “How much architecture? Reducing the up-front effort,” in Proceedings - Agile India 2012, Bangalore, India, 2012, pp. 56–59.

[5] P. Kamthan, “On the role of Wiki for managing knowledge in agile software development,” in Proceedings of the 2013 International Conference on Collaboration Technologies and Systems, CTS 2013, San Diego, CA, 2013, pp. 622–623.

[6] Semat, “Newsletter-SEMAT-1407011,” 2014. [Online]. Available: http://semat.org/documents/20181/23928/Newsletter-SEMAT-1407011.pdf/3a765951-7fed-4e41-8140-39ec7cceb6e0 . [Accessed: 13-Mar-2017].

[7] I. Jacobson, P. Ng, P. E. Mcmahon, and C. (Traductor) Zapata, “La Esencia de la Ingeniería de Software: El Núcleo de Semat,” Rev. Latinoam. Ing. Softw., vol. 1, no. 3, pp. 71–78, 2013.

[8] I. F. da Silva, P. A. da Mota Silveira Neto, P. O’Leary, E. S. de Almeida, and S. R. de Lemos Meira, “Using a Multi-Method Approach to Understand Agile Software Product Lines,” Inf. Softw. Technol., vol. 57, no. 1, pp. 527–542, 2014.

[9] M. Kaisti, T. Mujunen, T. Mäkilä, V. Rantala, and T. Lehtonen, “Agile principles in the embedded system development,” in Agile Processes in Software Engineering and Extreme Programming, vol. 179, G. Cantone and M. Marchesi, Eds. Rome: Springer, 2014, pp. 16–31.

[10] R. Popli, R. Anita, and N. Chauhan, “A mapping model for transforming traditional software development methods to agilemethodology,” Int. J. Softw. Eng. Appl., vol. 4, no. 4, pp. 53–64, 2013.


[11] M. Fowler and J. Highsmith, “The agile manifesto,” Softw. Dev., vol. 9, no. 8, pp. 28–35, 2001.

[12] B. Kanso and S. Taha, “Temporal constraint support for OCL”. In International Conference on Software Language Engineering (pp. 83-103), Springer Berlin Heidelberg, 2012

[13] Object Constraint Language. V 2.4, 2014.

[14] J. S Park, J. Sung, P.E McMahon and B. Myburgh, “Scrum powered by essence”, ACM SIGSOFT Software Engineering Notes 41.1 (2016): 1-8.

representación de los principios del manifiesto Ágil en el...

Documents