Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil

CIS1410IS07

GUÍA PARA LA INTEGRACIÓN DE MÉTODOS FORMALES DE INGENIERÍA DE

REQUERIMIENTOS EN PROCESOS DE DESARROLLO ÁGIL

JUAN DARÍO MURCIA TORRES

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

BOGOTÁ, D.C.

Página 2

CIS1410IS07

GUÍA PARA LA INTEGRACIÓN DE MÉTODOS FORMALES DE INGENIERÍA

DE REQUERIMIENTOS EN PROCESOS DE DESARROLLO ÁGIL

Autor:

Juan Darío Murcia Torres

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO

DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE

SISTEMAS

Director

Miguel Eduardo Torres Moreno

Jurados del Trabajo de Grado

Jaime Andrés Pavlich Mariscal

David Uribe

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~CIS1410IS07

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

BOGOTÁ, D.C.

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnífico

Joaquín Emilio Sánchez García S.J.

Decano Académico Facultad de Ingeniería

Ingeniero Jorge Luis Sánchez Téllez

Decano del Medio Universitario Facultad de Ingeniería

Padre Antonio José Sarmiento S.J.

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Director Departamento de Ingeniería de Sistemas

Página 4

Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus

proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que

AGRADECIMIENTOS

Este trabajo de grado, lo dedico a mi familia que me aguantó durante todo este

semestre en la casa; a mis amigos, que me ayudaron a perder el tiempo

disper-sando tensiones propias de este proceso, y a Dios, ya que sin Él muchas de estas

cosas vividas no sólo durante este semestre, si no durante toda la carrera, no

hubieran sido posibles…

Página 6

Contenido

INTRODUCCIÓN ...14

I

-

DESCRIPCION

GENERAL

DEL

TRABAJO

DE

GRADO...15

1.

O

PORTUNIDAD

,

P

ROBLEMÁTICA

,

A

NTECEDENTES

...15

1.1 Descripción del contexto ... 15

1.2 Formulación del problema que se resolvió ... 16

1.3 Justificación ... 16

1.4 Impacto Esperado ... 17

2.

D

ESCRIPCIÓN DEL

P

ROYECTO

...17

2.1 Visión global ... 17

2.3 Objetivo general ... 17

2.4 Fases Metodológicas o conjunto de objetivos específicos ... 18

2.5 Método que se propuso para satisfacer cada fase metodológica ... 19

II

-

MARCO

TEÓRICO ...21

1.

M

ARCO

C

ONTEXTUAL

...21

2.

M

ARCO

C

ONCEPTUAL

...23

2.1 Ingeniería de Requerimientos ... 23

2.2 Metodologías Ágiles ... 25

2.3 SEMAT... 32

2.4 Modelado de Requerimientos ... 42

2.5 Método para la implementación de La Guía (Way-Of) ... 44

III

–

DESARROLLO

DEL

TRABAJO ...47

1.

F

ASE DE

A

NÁLISIS Y

E

SPECIFICACIÓN

...48

1.1 Documento de Análisis y Especificación ... 49

2.

F

ASE DE

I

NTEGRACIÓN DE

C

OMPONENTES

...49

2.1 Forma de realizar las iteraciones ... 50

2.2 Alfas utilizados ... 50

2.3 Actividades realizadas ... 52

2.4 Modelos propuestos ... 53

2.5 Adaptaciones del Kernel de SEMAT ... 53

3.

F

ASE DE

V

ALIDACIÓN

...54

V

–

CONCLUSIONES,

RECOMENDACIONES

Y

TRABAJOS

FUTUROS ...56

1.

C

ONCLUSIONES

...56

2.

R

ECOMENDACIONES

...56

3.

T

RABAJOS

F

UTUROS

...56

VI

-

REFERENCIAS

Y

BIBLIOGRAFÍA ...58

VII

-

ANEXOS ...63

A

NEXO

1.

G

LOSARIO

...63

A

NEXO

2.

P

OST

-M

ORTEM

...64

1.

M

ETODOLOGÍA PROPUESTA VS

.

M

ETODOLOGÍA REALMENTE UTILIZADA

. ...64

2.

A

CTIVIDADES PROPUESTAS VS

.

A

CTIVIDADES REALIZADAS

. ...64

3.

E

FECTIVIDAD EN LA ESTIMACIÓN DE TIEMPOS DEL PROYECTO

...64

4.

C

OSTO ESTIMADO VS

.

C

OSTO REAL DEL PROYECTO

...65

5.

E

FECTIVIDAD EN LA ESTIMACIÓN Y MITIGACIÓN DE LOS RIESGOS DEL PROYECTO

. ....65

A

NEXO

3.

L

A

G

UÍA

...66

Página 8

Ilustraciones

Ilustración 1. Clasificación de Requerimientos ... 24

Ilustración 2. Scrum. (Tomado de [37]) ... 26

Ilustración 3. XP. (Tomado de [41]) ... 29

Ilustración 4. "Cosas con las que siempre trabajamos". (Tomado de [36]) ... 33

Ilustración 5. "Cosas que siempre hacemos". (Tomado de [36]) ... 33

Ilustración 6. Alfa Oportunidad. (Tomado de [47]) ... 35

Ilustración 7. Estados - Alfa Oportunidad. (Tomado de [47]) ... 35

Ilustración 8. Alfa Stakeholders. (Tomado de [47]) ... 36

Ilustración 9. Estados - Alfa Stakeholders. (Tomado de [47]) ... 36

Ilustración 10. Alfa Requerimientos. (Tomado de [47]) ... 37

Ilustración 11. Estados - Alfa Requerimientos. (Tomado de [47]) ... 37

Ilustración 12. Alfa Sistema de Software. (Tomado de [47]) ... 38

Ilustración 13. Estados - Alfa Sistema de Software. (Tomado de [47]) ... 38

Ilustración 14. Alfa Equipo. (Tomado de [47]) ... 39

Ilustración 15. Estados - Alfa Equipo. (Tomado de [47]) ... 39

Ilustración 16. Alfa Trabajo. (Tomado de [47]) ... 40

Ilustración 17. Estados - Alfa Trabajo. (Tomado de [47]) ... 40

Ilustración 18. Alfa Forma de Trabajar. (Tomado de [47]) ... 41

Ilustración 19. Estados - Alfa Forma de Trabajar. (Tomado de [47]) ... 41

Ilustración 20. Clasificación OPSD de modelos RML. (Tomado de [48]) ... 43

Ilustración 21. Aspectos del método "Way-of" para diseño y desarrollo de procesos de negocio. ... 45

Ilustración 23. Ejemplo de aplicación de Burndown for Trello [53] en el proyecto. ... 48

Ilustración 24. Ciclo Planear-Hacer-Verificar-Adaptar. (Adaptado de [35])... 50

Ilustración 25. Estados objetivo para la etapa de Obtención de Requerimientos. ... 51

Ilustración 26. Estados objetivo para la etapa de Análisis de Requerimientos. ... 51

Ilustración 27. Estados objetivo para la etapa de Especificación de Requerimientos. ... 52

Ilustración 28. Estados objetivo para la etapa de Validación de Requerimientos. ... 52

Página 10

ABSTRACT

Agile methodologies have gradually become the leading choice by software engineers when carrying out their projects [1]. Current needs, and the constant change in businesses, makes this type of methodologies an excellent basis for manage and develop software projects, how-ever, as with more traditional methods, project management involving many requirements makes difficult the software development process [2]. That is why, it is proposed the adapta-tion of some methods (commonly used in formal processes) of Requirements Engineering, through a theoretical basis provided by the kernel SEMAT.

RESUMEN

RESUMEN EJECUTIVO

Según los principios de las metodologías ágiles, la simplicidad en las tareas es un factor fun-damental a la hora de desarrollar software [3]. Parte de esta simplicidad consiste en la reduc-ción de la documentareduc-ción generada durante el proceso de desarrollo, dedicando más esfuerzos a la creación de software funcional por medio de una fuerte comunicación con el cliente. Adicionalmente, estas metodologías –a pesar de hacer uso de la Ingeniería de

Requerimien-tos–, muchas veces no presentan una clara trazabilidad entre sus artefactos, generando así

inconvenientes (en cuanto a gestión) en proyectos que manejan muchos entregables [4].

Es de saber que todos los proyectos de software son diferentes, ya que poseen características que varían de acuerdo al tipo de software a desarrollar, al ciclo de vida establecido y definido por la organización, y a las mismas necesidades del cliente, de este modo las compañías pue-den seleccionar metodologías ágiles o tradicionales para realizarlos. Sin embargo, muchas veces para abordar nuevos proyectos dentro de la organización –o soportar los ya realizados

ante la gerencia–, es necesario contar con documentación detallada y políticas de trazabilidad

definidas [1], lo cual usando metodologías tradicionales –en teoría– estaría asegurado, pero

en los proyectos ágiles esto desafortunadamente no siempre es así, por lo que se sugiere una metodología que ayude a soportar los procesos ágiles ya existentes dentro de la organización, con una Ingeniería de Requerimientos lo suficientemente formal.

Así mismo, una gran cantidad de inconvenientes que surgen en los proyectos, se dan por la importancia que tienen los Stakeholders, en cuanto a que al ser ellos los conocedo-res/afectados del sistema, son los encargados de proporcionar los requerimientos del mismo; requerimientos que se pueden observar como complejas combinaciones de diferentes niveles de la organización, y que se conectan con las características del ambiente en el que este va a operar [5]. Por esto, las personas son consideradas indispensables, pero muchas veces no cuentan con la paciencia o tiempo para participar en las actividades que implica este proceso [2].

Este tipo de problemas son más comunes en metodologías tradicionales, en las cuales los ingenieros deben valerse de diferentes técnicas durante la etapa de Obtención de Requeri-mientos, con el fin de que la información obtenida sea relevante y suficiente para continuar con las siguientes etapas y desarrollar el sistema que el cliente realmente espera. Caso contra-rio a las Metodologías Ágiles, en las cuales el cliente y/o usuacontra-rio está presente durante la mayor parte del proceso de desarrollo, haciendo que el producto (o subproductos) final gene-rado, esté más acorde a los requerimientos del usuario.

Página 12

De esta manera, se determinó una meta, a modo de objetivo general: “Elaborar una guía que

permita ayudar a organizaciones de desarrollo ágil, en la selección de técnicas propias de una Ingeniería de Requerimientos formal, las cuales –de acuerdo al contexto del proyecto y la

organización– apoyen los procesos ya existentes al interior de las mismas, teniendo como

referente el uso de buenas prácticas en la Ingeniería de Software”.

Para la creación del método, se precisó trabajar durante 3 fases, proporcionando así un con-texto y marco de referencia válido, teniendo en cuenta la problemática tratada anteriormente, y un conjunto de requisitos (considerados) mínimos para una apropiada implementación del método, el cual a su vez, es caracterizado por el desarrollo de una Guía (desde ahora La Guía).

Así mismo, se consideró que para que el trabajo realizado tuviera retroalimentación constan-te, era necesario usar una metodología Scrum para su gestión. Cada Sprint de dos semanas, y con una gestión a través de la herramienta web Trello.

En una primera fase (de Análisis y Especificación), se realizó toda la investigación que se consideró pertinente para poder proporcionar más que un contexto, un marco de referencia válido sobre el cual desarrollar todas las ideas plasmadas en La Guía. En esta fase se aborda-ron temas como Ingeniería de Requerimientos (Desde ahora IR), Metodologías Ágiles como Scrum, XP y Kanban, el Kernel de SEMAT, y la actualidad de estos temas. Todo esto quedó detallado en un Documento de Análisis y Especificación-

En una segunda fase (de Integración de Componentes), adicionalmente al marco de referencia generado en la fase anterior, fueron agregadas otras temáticas tales como modelado de reque-rimientos a través de RML, se profundizó un poco más sobre en Kernel de SEMAT, y se definieron los métodos para la implementación de La Guía. Algunas de estas cosas no fueron incluidas dentro del Documento de Análisis y Especificación debido a que no había un con-texto sobre el cual aprobarlos.

Adicionalmente, esta segunda fase fue en la que se propuso y desarrolló La Guía, esto es, todo el conjunto de elementos que hacen parte de ella, y la forma en que estos (se propuso) fueran gestionados. Este proceso incluyó desde la determinación de un contexto para trabajar (Ver Sección 2.5 Método para la implementación de La Guía (Way-Of), del capítulo II - MARCO TEÓRICO), pasando por la selección de los elementos del Kernel de SEMAT que deberían ser tratados, en qué etapas deberían hacerlo y cómo sería su gestión, hasta la deter-minación de la manera en que se debe manejar cada iteración, y los posibles modelos visuales que podrían ser usados en cada etapa.

Al final de esta fase, se contaba con un documento (La Guía) que proporcionaba un conjunto de buenas prácticas, enmarcadas bajo una bandera común: El Kernel de SEMAT. Dicho Ker-nel dio a La Guía una base sólida, que sumada a los otros aspectos anteriormente especifica-dos, proporcionaban una posible buena solución a la problemática identificada en un princi-pio.

Página 14

INTRODUCCIÓN

El presente documento busca mostrar el trabajo realizado durante la elaboración de La Guía para la Integración de Métodos Formales de Ingeniería de Requerimientos en Procesos de Desarrollo Ágil. Dicha Guía se desarrolló bajo la premisa de que los proyectos de desarrollo de software a través de la implementación de metodologías ágiles, son potentes en las fases de pruebas y desarrollo, sin embargo, pueden ser aún mejores si se fortalece su proceso de Ingeniería de Requerimientos.

En este sentido es válido mencionar, que las Metodologías Ágiles se han convertido poco a poco en las de principal selección por parte de Ingenieros de Software, a la hora de escoger el tipo de metodología para gestionar y desarrollar sus proyectos. Esto en gran medida, a la facilidad de adaptabilidad que proporcionan.

Lo mencionado anteriormente, no implica que los proyectos estén siendo gestionados de ma-nera correcta, ni que dichas metodologías proporcionen a los miembros de equipos de desa-rrollo todas las facilidades que podrían tener para gestionar los proyectos perfectamente y sin errores. Informes como CHAOS del proyecto CHAOS de The Standish Group [6], indican precisamente que a pesar de todo, aún se están cometiendo errores fatales, que comprometen el correcto desempeño del proyecto, y en algunos casos, la propia continuidad del mismo.

Adicionalmente se ha encontrado que muchos de los inconvenientes que se pueden tener en los proyectos de desarrollo de software, convergen en gran medida en una cosa: los requeri-mientos. Una incorrecta obtención, análisis, especificación, validación, y gestión de estos, aumenta los riesgos y podría volver inmanejable al proyecto, sin importar si este se esté ma-nejando a través de metodologías ágiles o más tradicionales.

La Guía para la Integración de Métodos Formales de Ingeniería de Requerimientos en Pro-cesos de Desarrollo Ágil, propone la unificación de varios elementos referentes a la Ingenie-ría de Requerimientos, al modelado de estos y a las metodologías ágiles, y todo bajo un mis-mo lenguaje proporcionado por el Kernel de SEMAT.

I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO

1. Oportunidad, Problemática, Antecedentes

1.1 Descripción del contexto

Según los principios de las metodologías ágiles, la simplicidad en las tareas es un factor fun-damental a la hora de desarrollar software [3]. Parte de esta simplicidad consiste en la reduc-ción de la documentareduc-ción generada durante el proceso de desarrollo, dedicando más esfuerzos a la creación de software funcional por medio de una fuerte comunicación con el cliente. Adicionalmente, estas metodologías –a pesar de hacer uso de la Ingeniería de

Requerimien-tos–, muchas veces no presentan una clara trazabilidad entre sus artefactos, generando así

inconvenientes (en cuanto a gestión) en proyectos que manejan muchos entregables [4].

Actualmente en muchas metodologías ágiles se es consciente de lo anterior, y se está propo-niendo más formalismo a pesar de su naturaleza, como es el caso de XP (en su segunda edi-ción) el cual propone algunas nuevas prácticas en las que –a diferencia de su primer versión–

se sugiere documentar aspectos como el contrato de negociación y algunas decisiones que se tomen durante el desarrollo del proyecto [7]. De una manera mucho más formal, las metodo-logías tradicionales enfocan sus esfuerzos principalmente en el descubrimiento, desarrollo, trazabilidad, y análisis de requerimientos, de tal forma que sean definidos de manera estricta por medio de técnicas bastante bien estructuradas del área de conocimiento conocida como Ingeniería de Requerimientos [8].

Todos los proyectos de software son diferentes, ya que poseen características que varían de acuerdo al tipo de software a desarrollar, al ciclo de vida establecido y definido por la organi-zación, y a las mismas necesidades del cliente, de este modo las compañías pueden seleccio-nar metodologías ágiles o tradicionales para realizarlos. Sin embargo, muchas veces para abordar nuevos proyectos dentro de la organización –o soportar los ya realizados ante la

ge-rencia–, es necesario contar con documentación detallada y políticas de trazabilidad definidas

[1], lo cual usando metodologías tradicionales –en teoría– estaría asegurado, pero en los

pro-yectos ágiles esto desafortunadamente no siempre es así, por lo que se sugiere una metodolo-gía que ayude a soportar los procesos ágiles ya existentes dentro de la organización, con una Ingeniería de Requerimientos lo suficientemente formal.

Página 16

Además de lo anterior, existen iniciativas como SEMAT [11], que buscan por medio de una teoría lo suficientemente formal, la implementación de la Ingeniería de Software utilizando

las mejores prácticas de los “más de 100000 métodos existentes” [12] dentro de los cuales se

encuentran RUP, CMMI, Scrum y XP entre otros. En el caso de La Guía desarrollada, se utilizó SEMAT a fin usar todas estas buenas prácticas propuestas, e integrar la Ingeniería de Requerimientos en procesos de desarrollo ágil.

Finalmente, en un contexto nacional las organizaciones Fedesoft [13] y MinTIC [14] son las encargadas de agrupar a las empresas desarrolladoras de Software en Colombia, proveyendo además de normativas, regulación y estándares, talleres, certificaciones, seminarios y demás actividades para garantizar que dichas empresas realicen este proceso con calidad. En el caso de La Guía generada, tal y como se mencionó en la propuesta presentada anteriormente, se hizo énfasis únicamente en organizaciones cuyas metodologías de desarrollo fueran a través de procesos ágiles, y en un contexto que agrupara las necesidades más generales de dichos procesos.

1.2 Formulación del problema que se resolvió

¿Cómo por medio de la aplicación de una Guía Metodológica puede la Ingeniería de Reque-rimientos formal, apoyar y fortalecer procesos propios de las metodologías ágiles, a través de la selección de métodos adecuados al entorno del proyecto y la organización?

1.3 Justificación

Según el último Informe CHAOS del proyecto CHAOS de The Standish Group, en 2012 el 39% de los proyectos de software culminaron de manera exitosa, sin embargo –y aunque esta

cifra ha disminuido en comparación a años anteriores– el 18% de los proyectos terminó de

manera fallida, y en un 43% de las oportunidades hubo problemas durante la etapa de desa-rrollo [6].

Las anteriores cifras dan una idea acerca de la actualidad de los proyectos de desarrollo de software, y muestran que sólo algunos consiguen ser exitosos. De esta manera se logra ver que en un 61% de los proyectos se tienen inconvenientes que hacen que estos no funcionen de manera apropiada, generando en determinado caso que el proyecto no se logre si quiera

culminar. Según el artículo “What Software Fails” publicado en una edición digital de IEEE

Spectrum, los proyectos pueden fallar por los siguientes factores comunes [15]: Objetivos de proyecto no realizables, Inexactitud en la estimación de recursos, Requerimientos del sistema definidos de manera errónea, Presentación pobre de los informes del proyecto, Riesgos no gestionados, Comunicación pobre entre clientes, desarrolladores y usuarios, Uso de tecnolo-gía poco madura e inestable, Incapacidad para manejar la complejidad del proyecto, Malas prácticas de desarrollo, Gestión pobre del proyecto, Políticas de los Stakeholders y finalmente Presiones comerciales.

Es de notar que los factores enunciados anteriormente son genéricos y no aplican siempre en todos los proyectos, eso depende del tipo de metodología usada por la organización, y la ges-tión que se le dé. Por ejemplo, cuando se usan Metodologías Ágiles, es casi incomprensible

de sus fortalezas. De acuerdo a esto, y teniendo en cuenta que la Guía se desarrolló enfocada a organizaciones que hagan uso de métodos y procesos ágiles, se observa que sería posible reducir muchos de estos factores de riesgo, y más aún, ayudar a abordar los elementos que no se están teniendo en cuenta durante la ejecución del proyecto –y que podrían ser claves en un

futuro, apoyando dichos procesos sobre Ingeniería de Requerimientos un poco más formal a la usada en la actualidad por la organización–.

1.4 Impacto Esperado

Se espera que La Guía generada realmente ayude a las organizaciones a continuar desarro-llando software de calidad. De igual forma, se piensa que La Guía propone buenos elementos que facilitan integrar las actividades establecidas en esta (referentes a procesos de Ingeniería de Requerimientos), al interior de cualquier proyecto de desarrollo ágil de software.

En un corto plazo, se esperan implementaciones en un ámbito meramente académico, de tal forma que los estudiantes y/o docentes que puedan desarrollar proyectos para sus clases basa-dos en esta Guía, observen una facilidad a la hora de implementarla, logrando así los objeti-vos esperados.

En un mediano plazo, se pretende que La Guía sea usada por organizaciones desarrolladoras de software que utilicen metodologías ágiles, permitiendo a la industria del software ser más competitiva, y desarrollar software de la misma o de mejor calidad a la actual –lo cual no se

podría determinar en un comienzo, ya que La Guía se desarrolla únicamente con el fin de proporcionar facilidades a las organizaciones que la apliquen, no asegura que se mejoren los procesos de desarrollo, ya que esto depende de una correcta implementación y la gestión apropiada en los proyectos–.

A largo plazo, lo ideal es que La Guía sea reconocida nacional e internacionalmente (si es posible) por grandes organizaciones de desarrollo que utilicen metodologías ágiles.

2. Descripción del Proyecto

2.1 Visión global

Desarrollo de una Guía en la que a través de la implementación de parte del Kernel de SEMAT (sólo incluyendo lo referente al proceso de Ingeniería de Requerimientos), se inte-graron algunos elementos propios de la Ingeniería de Requerimientos (como la generación de modelos y diagramas) en un proceso de desarrollo ágil.

2.3 Objetivo general

Elaborar una guía que permita ayudar a organizaciones de desarrollo ágil, en la selección de técnicas propias de una Ingeniería de Requerimientos formal, las cuales –de acuerdo al

con-texto del proyecto y la organización– apoyen los procesos ya existentes al interior de las

Página 18

2.4 Fases Metodológicas o conjunto de objetivos específicos

2.4.1 Fase de Análisis y Especificación

Durante esta fase se usó una metodología de investigación exploratoria [16], ya que fue la fase en la cual se realizó una aproximación y profundización en temáticas como SEMAT, Ingeniería de Requerimientos y Metodologías Ágiles. La idea principal de esta fase consistió en proporcionar un contexto inicial que sirviera como base para la elaboración de La Guía.

2.4.1.1 Objetivos Específicos

 Sintetizar los aspectos más importantes de los métodos más usados de las Metodolo-gías Ágiles, y crear un documento que muestre dicho resultado.

 Establecer los métodos y prácticas de la Ingeniería de Requerimientos (por medio de SEMAT y la síntesis generada con el cumplimiento del objetivo anterior) que más se acomodan a las metodologías usadas actualmente.

2.4.2 Fase de Integración de Componentes

Esta fase se enfocó principalmente en la integración de los elementos generados en la fase anterior con el fin de elaborar La Guía. Para esto, se usó una metodología de integración ba-sada en flujos de trabajo [17]. La idea de estos flujos es que permitieran no solo enlazar y unificar técnicas de desarrollo ágil con Ingeniería formal de Requerimientos por medio la aplicación del Kernel de SEMAT, sino también intentar mejorar los procesos de desarrollo de software al interior de las organizaciones –lo cual, como se mencionó anteriormente es muy

subjetivo, ya que para que esto se dé, influyen muchos factores que se encuentran fuera del alcance de La Guía–. De acuerdo a lo anterior, se trató que la integración fuera realizada y

ajustada teniendo en cuenta estos procesos. De igual forma, se llevó el control de avance general del proyecto por medio del Product Backlog, y de cada iteración requerida, mediante el Sprint Backlog correspondiente.

2.4.2.1 Objetivos Específicos

 Generar un documento que integre los diferentes módulos generados en el objetivo anterior, el cual, si es aplicado de manera apropiada (y de acuerdo a las característi-cas de cada proyecto), sea capaz de optimizar los procesos de desarrollo y negocio que actualmente se usan.

2.4.3 Fase de Validación

2.4.3.1 Objetivos Específicos

 Validar La Guía con la ayuda de un experto en Ingeniería de Software e Ingeniería de Procesos.

2.5 Método que se propuso para satisfacer cada fase metodológica

2.5.1 Fase de Análisis y Especificación

2.5.1.1 Metodología (Investigación exploratoria)

Por medio del análisis de las Metodologías Ágiles más usadas en organizaciones de desarro-llo de software, se definió un contexto sobre el cual fueron profundizados temas como Inge-niería formal de Requerimientos y procesos ágiles de desarrollo de software. De igual forma, se llevó el control de avance general del proyecto por medio del Product Backlog, y de cada iteración requerida, mediante el Sprint Backlog correspondiente.

2.5.1.2 Actividades

 Levantamiento de información correspondiente a la actualidad (problemas más co-munes, y forma de gestionar procesos de desarrollo) de las organizaciones desarro-lladoras de software, enfocando esta búsqueda principalmente en las que soporten procesos ágiles.

 Análisis de las principales tendencias en el uso e implementación de métodos ágiles e Ingeniería de Requerimientos.

 Usando SEMAT, se especificó un conjunto de prácticas formales de Ingeniería de Requerimientos, que se acomodaran mejor a los métodos más usados actualmente.

2.5.1.3 Hitos

 Documento de análisis sobre las principales metodologías, tendencias y herramientas ágiles y de Ingeniería de Requerimientos usadas actualmente en el desarrollo de software.

 Documento que incluyó una base teórica acerca de SEMAT. –Este documento fue

fi-nalmente unificado al anterior, generando así un gran documento de Análisis y Espe-cificación de todos los elementos que iban a ser incluidos en La Guía–.

 Product Backlog actualizado.

 Sprint Backlog por cada iteración realizada. 2.5.2 Fase de Integración de Componentes

2.5.2.1 Metodología (Integración basada en flujos de trabajo)

Teniendo en cuenta los posibles flujos de trabajo referentes a procesos de Ingeniería de Soft-ware al interior de las organizaciones, fueron propuestas mejoras que se acomodaran e inte-graran a dichos procesos y al contexto generado durante la fase de Análisis y Especificación, a través de un conjunto de prácticas apropiadas.

2.5.2.2 Actividades

Página 20

2.5.2.3 Hitos

 Guía Metodológica.

 Product Backlog actualizado.

 Sprint Backlog por cada iteración realizada. 2.5.3 Fase de Validación

2.5.3.1 Metodología (Validación por experto)

De acuerdo al conocimiento de terceros, se determinó si La Guía desarrollada durante las fases anteriores, fue realizada de manera que se cumpliera con el Objetivo General del pro-yecto.

2.5.3.2 Actividades

 Validar con un tercero (experto en proyectos de desarrollo de software) la calidad y validez de la guía propuesta.

2.5.2.3 Hitos

 Validación por parte de uno o más expertos.

II - MARCO TEÓRICO

1. Marco Contextual

Los principales inconvenientes que surgen en un proyecto (con relación a los requerimientos), se dan por la importancia que tienen los Stakeholders, en cuanto a que al ser ellos los conoce-dores/afectados del sistema, son los encargados de proporcionar los requerimientos del mis-mo, los cuales se pueden observar como complejas combinaciones de diferentes niveles de la organización, y que se conectan con las características del ambiente en el que este va a operar [5]. Por esto, las personas son consideradas indispensables, pero muchas veces no cuentan con la paciencia o tiempo para participar en las actividades que implica este proceso [2]. Este tipo de problemas son más comunes en metodologías tradicionales, en las cuales los ingenie-ros deben valerse de diferentes técnicas durante la etapa de Obtención de Requerimientos, con el fin de que la información obtenida sea relevante y suficiente para continuar con las siguientes etapas y desarrollar el sistema que el cliente realmente espera. Caso contrario a las Metodologías Ágiles, en las cuales el cliente y/o usuario está presente durante la mayor parte del proceso de desarrollo, haciendo que el producto (o subproductos) final generado, esté más acorde a los requerimientos del usuario.

Las Metodologías Ágiles fueron introducidas formalmente desde mitad de los años 90s con la implementación de los métodos más usados (RUP, Scrum y XP), pero fue hasta 2001 cuando se conocieron formalmente como Metodologías Ágiles con la publicación del Manifiesto Ágil [3] [19].

Teniendo en cuenta que una Ingeniería de Requerimientos formal gasta tiempo, y con la ne-cesidad de rápidos cambios en el software, las Metodologías Ágiles han obtenido gran popu-laridad debido a los enormes cambios tecnológicos de los últimos tiempos, y a las facilidades y oportunidades que ellos han generado en cuanto a comunicaciones, mercados y condiciones económicas. Estos cambios obligan a los sistemas nuevos y a los ya existentes a responder de manera competitiva a las diferentes demandas que se proponen a diario [1], por tal motivo, se espera que el software desarrollado hoy en día atienda dichas necesidades.

Página 22

Con el paso del tiempo se han observado algunos cambios y tendencias en la forma de desa-rrollar software, y esto no solo incluye metodologías de desarrollo, sino también todo lo refe-rente a la Ingeniería de Requerimientos. Algunas cosas han cambiado y otras han continuado igual, como es el caso de la falta de relevancia que se le da al proceso de Ingeniería de Re-querimientos —aun cuando es conocido por todos los Ingenieros de Software que éste hace

parte fundamental en cualquier proyecto de desarrollo— y el problema común de todo

pro-yecto que se da porque los Stakeholders ignoran lo que realmente quieren [2].

Por otro lado, el avance tecnológico de los últimos tiempos, unificado a la necesidad de que éste sea cada vez más rápido, y la búsqueda por cumplir las diferentes expectativas referentes a las comunicaciones y a los nuevos mercados, hace que el nuevo software a desarrollar deba ser más competitivo. Teniendo en cuenta este contexto de continuo cambio, se han observado diferentes tendencias que cada vez son más fuertes. Algunas de dichas tendencias se podrían relacionar con el fortalecimiento de las Metodologías Ágiles por medio de un uso más amplio de la Ingeniería de Requerimientos en proyectos de desarrollo, lo que genera una mayor –y

más fácil— integración en proyectos futuros [2].

Adicional a esto, se han desarrollado herramientas que ayudan la Gestión de Requerimientos y de algunos de los componentes propuestos durante el proceso de Ingeniería de Requeri-mientos como el Product Backlog (en el caso de Scrum) [2]. Dichas herramientas en un prin-cipio deberían poder usarse acorde al principal referente que se tiene hoy en día en cuanto a requerimientos, el estándar ISO/IEC/IEEE 29148 [20], el cual no garantiza por completo que lo que se esté haciendo se encuentre bien, pero por lo menos sirve de guía a los Ingenieros y Stakeholders en este importante proceso.

En la actualidad, los continuos cambios en las organizaciones y de los entornos en los que estas se desempeñan –como se mencionaba anteriormente–, han llevado a buscar mecanismos

o frameworks de adaptabilidad que faciliten a los Ingenieros de Software a determinar cierta información que permita ahorrar energía con elementos que poco van a variar durante cada proyecto, pero teniendo en cuenta los demás. Un claro ejemplo es el del Departamento de Salud y Servicios Humanos de los Estados Unidos, el cual por medio de un framework simi-lar, determina el por qué alguna regulación cambia, cómo lo hace y cuáles porciones de una norma propuesta son más propensas a cambiar una vez se emite una regla final. Esto permite a los ingenieros centrase principalmente en el análisis y especificación de requerimientos de cumplimiento referente a las áreas más estables de la norma, mientras las menos estables son aclaradas durante la reglamentación final [21] [22].

Así mismo, cada vez más se tienen en cuenta aspectos del negocio que pueden cambiar en cualquier momento, y se está dejando de ver a la IR como sólo un proceso más en el desarro-llo de cualquier sistema. Un ejemplo claro en cuanto a seguridad consiste en tratar de prote-ger bienes variables en tiempo de ejecución por medio de seguridad adaptativa manejada por requerimientos [21] [22].

Teniendo en cuenta lo anterior se observa en la IR cada vez con mayor frecuencia el uso de

para la gestión de requerimientos que hagan a los sistemas más dinámicos [29], con el fin de obtener resultados más precisos durante y después de cada proyecto de desarrollo de software [21] [30].

Adicional a esto, las tecnologías web como la computación en la nube, también han comen-zado a hacer parte activa en estas tendencias. Por medio del uso de dichas tecnologías se ha facilitado enormemente la comunicación con los Stakeholders cuando de requerimientos e identificación de recursos se habla. [31] [32]

En cuanto a Metodologías Ágiles, en los últimos tiempos se ha popularizado su uso, por lo que en la actualidad muchas organizaciones aplican y recomiendan dichas metodologías. Esta popularidad se ha ido fortaleciendo por la misma naturaleza de las metodologías ágiles a no ser tan formales ni estructuradas, lo que genera que estas no obliguen a los proyectos a usar ciertos métodos, que en algunas ocasiones podrían ir en contra del negocio. La principal ven-taja de las metodologías ágiles es su adaptabilidad, y la posibilidad de mezclar métodos y prácticas de diferentes metodologías, lo que las hace más versátiles y usables. [3] [7] [33]

Así mismo desde su aparición en 2009, SEMAT se ha convertido poco a poco en un excelen-te referenexcelen-te para lograr unificar las metodologías y adaptarlas tanto al proyecto, como a la organización; las metodologías que se pueden usar con este método de gestión son bastantes y no importa si son de raíces ágiles o tradicionales, sin embargo es de saber que tiene una mayor afinidad con metodologías ágiles. [34] [35] [36]

2. Marco Conceptual

2.1 Ingeniería de Requerimientos

La Ingeniería de Requerimientos corresponde a un proceso sistemático para el descubrimien-to, desarrollo, trazabilidad, análisis, clasificación, comunicación y Gestión de Requerimien-tos, el cual define un sistema en niveles sucesivos de abstracción [8]. Dicho proceso busca fundamentalmente facilitar las tareas que soporten los demás procesos de negocio al interior de una organización, y como todo proceso, sirve de entrada y salida para muchos otros [5]. El proceso abarca básicamente 5 etapas, las cuales son (para un mayor detalle, diríjase al “Do-cumento de Análisis y Especificación”, Sección 1 o a La “Guía”, Sección 2.1):

2.1.1 Obtención de Requerimientos

Primera etapa del proceso de Ingeniería de Requerimientos, la cual se encarga principalmente de la recolección y clasificación inicial (no tan estricta) de los requerimientos. En esta etapa es primordial:

Página 24

 Una comunicación efectiva entre los Stakeholders (los cuales también son definidos con detalle en esta fase), y el equipo desarrollador. Para esto puede ser útil modelar desde diferentes modelos de abstracción –de acuerdo al tipo de conocimiento del

Stakeholder–. [5]

 Tener un completo entendimiento de la problemática que se piensa solucionar, y esto implica conocer detalladamente: los objetivos de alto nivel de la organización, los Stakeholders, las reglas del negocio, y los ambientes operacional y organizacional. [2]

2.1.2 Análisis de Requerimientos

Etapa siguiente a la Obtención de Requerimientos la cual se encarga principalmente de limi-tar el alcance de los requerimientos obtenidos anteriormente, así como de deteclimi-tar y resolver los posibles conflictos que estos puedan presentar [5]. En esta etapa es primordial:

 Detallar las actividades de los usuarios [2].

 Clasificar formalmente los requerimientos –lo que implica una descomposición de

los obtenidos inicialmente– [5]. Para el contexto de este documento, se establece una

clasificación como la que se muestra en la Ilustración 1.

 Priorizar los requerimientos de acuerdo a las necesidades del negocio y el proyecto [2].

 Entender la situación del problema a través del uso de diagramas de casos de uso, modelos de flujo de datos, modelos de estado, modelos basados en objetivos, interac-ciones entre usuarios, modelos de objetos y modelos de datos, entre otros [5].

Ilustración 1. Clasificación de Requerimientos 2.1.3 Especificación de Requerimientos

Etapa siguiente al Análisis de Requerimientos la cual se encarga principalmente de formalizar el lenguaje en el que estos se encuentran escritos. En esta etapa es primordial:

 Evitar ambigüedades (los requerimientos tienen que ser entendidos sólo de una mane-ra, sin importar el conocimiento del lector).

 Tratar de separar requerimientos cuando se encuentre en su estructura algún tipo de

conector “y” u “o”.

 Tener en cuenta (a modo general), que los requerimientos deben: ser verificables, ser conocidos por los Stakeholders, solucionar problemas del negocio (usuarios,

Stakeholders, sistema…), ser medibles, estar limitados por restricciones del negocio

o del proyecto, definir las capacidades del sistema a crear/actualizar. [20] 2.1.4 Validación de Requerimientos

Etapa siguiente a la Especificación de Requerimientos la cual se encarga principalmente de determinar por parte de los desarrolladores si los requerimientos especificados anteriormente, ayudarán a dar solución a la problemática. En esta etapa es primordial:

 Establecer si los requerimientos efectivamente satisfacen a los objetivos de negocio [2].

 Realizar actividades en las que se valide la comprensión del problema [5].

 Revisar la especificación de los requerimientos para detectar inconsistencias, esto es, errores, falsas suposiciones y falta de claridad [5].

 Crear prototipos para evaluar el correcto entendimiento de los requerimientos [1].  Diseñar pruebas de aceptación a fin de desechar y/o confirmar requerimientos [5]. 2.1.5 Gestión de Requerimientos

La Gestión de Requerimientos no se ejecuta en algún momento en específico del proyecto, sino que abarca todo lo referente a la planeación, monitorización del progreso y gestión de cambios durante todo el ciclo de vida de este [8]. Para una buena gestión es importante:

 Reconocer y tener en cuenta que los requerimientos son cambiantes [20].

 Planear, monitorear el progreso y gestionar cambios en el ciclo de vida del proyecto [8].

 Definir y controlar la correcta publicación de requerimientos, documentos, modelos, código, etc. [20]

 Aprobación los resultados por parte del experto del negocio (¿Se cumple con las ne-cesidades de los usuarios? ¿Se cumple con los objetivos del negocio?). [8]

 Recolectar y comparar métricas de requerimientos [8].

 Tener un correcto manejo de las versiones de los requerimientos, de los documentos generados y de los modelos utilizados [8] [20].

2.2 Metodologías Ágiles

Anteriormente ya se ha hablado sobre lo que son las metodologías ágiles y sus principales características. En esta sección se detallan algunas de las Metodologías Ágiles más famosas (para un mayor detalle en estas metodologías, diríjase al “Documento de Análisis y

Página 26

2.2.1 Scrum

Considerado como el método ágil más popular, Scrum es un framework iterativo e incremen-tal para proyectos y productos o desarrollo de aplicaciones [37] que se desarrolla en ciclos de trabajo llamados Sprints. Scrum no es un proceso o técnica para construir productos; en lugar de eso es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos [38].

Ilustración 2. Scrum. (Tomado de [37])

Scrum consta de 3 elementos fundamentales para su desarrollo, el Scrum Team, los Eventos de Scrum, y los Artefactos de Scrum:

2.2.1.1 Scrum Team

El Scrum Team, cuenta con 3 roles:

 Dueño del Producto (Product Owner): Es el único responsable (persona) de ges-tionar el Product Backlog, y sus decisiones deben ser respetadas por la organización. Esta gestión incluye [38]:

o Expresar claramente los elementos del Product Backlog.

o Ordenar los elementos del Product Backlog para alcanzar los objetivos y

mi-siones de la mejor manera posible.

o Optimizar el valor del trabajo desempeñado por El Equipo.

o Asegurar que el Product Backlog sea visible, transparente y claro para todos,

y que muestre en lo que El Equipo trabajará a continuación.

o Asegurar que el equipo de desarrollo entiende los elementos del Product

 El Equipo (The Team): Los equipos son auto-gestionados, auto-organizados y mul-tifuncionales, y son los responsables de encontrar la manera de convertir el Product Backlog en un incremento de funcionalidad al interior de cada iteración gestionando su propio trabajo a ser realizado. Los miembros del equipo son responsables del éxito de cada iteración y del proyecto en conjunto [38]. El tamaño óptimo de El Equipo debe estar entre 3 y 9 personas, que es un grupo lo suficientemente pequeño como para permanecer ágil, y lo suficientemente grande como para completar una cantidad de trabajo significativa.

 Scrum Master: No es el administrador del equipo ni del proyecto. El Scrum Master es el responsable de asegurar que Scrum se aplique y sea entendido de la manera ade-cuada y está al servicio del Scrum Team para garantizar que éste trabaje ajustado a la teoría, prácticas y reglas de Scrum. De igual forma ayuda a externos al Scrum Team a entender qué interacciones con el equipo pueden ser de ayuda y cuáles no, además de maximizar el valor creado por el Scrum Team por medio de modificaciones de dichas interacciones. [38]

2.2.1.2 Eventos de Scrum

En Scrum, todo el trabajo se realiza en Sprints (son el corazón de Scrum), los cuales contie-nen a todos los eventos de Scrum. Dichos eventos son bloques de tiempo, de manera que tienen una duración máxima. Una vez comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los demás eventos pueden terminarse una vez alcancen el objetivo del evento, asegurando que se emplee la cantidad de tiempo apropiada y sin desperdicio en el proceso. [38]

Cada Sprint debe tener una duración de 1 a 4 semanas (no más, no menos); tiempo en el cual se crean incrementos en el producto. Estos incrementos implican un producto utilizable y potencialmente desplegable. No puede haber miembros de un mismo Equipo Scrum en Sprints simultáneos, por lo que cada iteración inicia con la finalización de la anterior. [38]

Los Eventos de Scrum son [38]:

 Objetivo del Sprint (Sprint Goal): Es propuesto durante el Sprint Planning Mee-ting, y corresponde a la meta establecida para el Sprint. Proporciona una guía al Equipo acerca del por qué se está realizando dicho incremento.

 Reunión de planificación del Sprint (Sprint Planning Meeting): Es la reunión ini-cial de cada Sprint, en la que se planifica el trabajo a realizar durante la iteración. Es-ta reunión es vigilada por el Scrum Master para asegurar que se haga de la manera adecuada y no debería durar más de 8 horas. Durante esta reunión se responden prin-cipalmente las siguientes preguntas:

o ¿Qué puede entregarse en el incremento resultante del Sprint que comienza? o ¿Cómo se conseguirá hacer el trabajo necesario para entregar el incremento?  Scrum diario (Daily Scrum): Reunión diaria de 15 minutos de duración en la que

todos los miembros del Equipo deben estar presentes, con el fin de crear un plan para las siguientes 24 horas. Durante esta reunión se pretende que cada miembro del Equipo responda las siguientes preguntas:

Página 28 o ¿Qué haré hoy para ayudar al Equipo a cumplir con el Sprint Goal?

o ¿Veo algún impedimento que evite que El Equipo o yo logremos el Sprint

Goal?

 Revisión del Sprint (Sprint Review): Al terminar el Sprint, El Equipo dedica 4 ho-ras o menos (dependiendo la duración del Sprint) para presentar al Product Owner lo realizado durante la iteración [39], con el fin de actualizar el Product Backlog y defi-nir los elementos para el siguiente Sprint. El Sprint Review corresponde a una reunión informal y no de seguimiento, en la que pueden además participar los intere-sados que colaboraron al Equipo. Adicional a la presentación ante el Product Owner, se busca fomentar la colaboración entre El Equipo. Al igual que en el Sprint Planning Meeting, es deber del Scrum Master asegurarse que la reunión se haga de la manera adecuada.

 Retrospectiva del Sprint (Sprint Retrospective): Reunión de duración no mayor a 3 horas (dependiendo la duración del Sprint), en la que se tiene como propósito:

o Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones,

pro-cesos y herramientas.

o Identificar y ordenar los elementos más importantes que salieron bien, y las

posibles mejoras.

o Crear un plan para implementar las mejoras a la forma en que el equipo

Scrum desempeña su trabajo.

2.2.1.3 Artefactos de Scrum.

Scrum define los siguientes artefactos con el fin de proporcionar transparencia y oportunida-des para la inspección y adaptación [38]:

 Product Backlog: Contiene una lista de los requerimientos (características) del sis-tema o producto a ser desarrollado por el proyecto, junto a una descripción, ordena-ción, estimación y valor para cada ítem. El Product Owner es el responsable del con-tenido y su priorización y disponibilidad. El Product Backlog es dinámico; la gestión cambia constantemente para identificar lo que el producto necesita para ser apropia-do, competitivo y útil [39].

 Sprint Backlog: Especifica el trabajo o lista de tareas que El Equipo define seleccio-nar del Product Backlog para un Sprint específico. En el Sprint Backlog se hace visi-ble todo el trabajo que El Equipo considera como necesario para lograr el Sprint Goal. A medida que el trabajo se completa, se va actualizando la estimación del tra-bajo restante.

2.2.2 XP

Metodología ágil de desarrollo propuesta formalmente por primera vez en “Extreme Progra-mming Explained” [40], donde fue definida como “un ligero, eficiente, de bajo riesgo, prede-cible, científico y divertido método para desarrollar software”. Se diferencia según su autor

Kent Beck por [7]:

 Su enfoque de planeación incremental, el cual rápidamente surge con un plan general que se espera, evolucione a través del ciclo de vida del proyecto.

 Su capacidad de programar con flexibilidad la implementación de la funcionalidad, en respuesta a las cambiantes necesidades del negocio.

 Su dependencia de pruebas automatizadas escritas por clientes y programadores para monitorear el progreso del desarrollo, permitiendo al sistema evolucionar y capturar los defectos tempranamente.

 Su dependencia de la comunicación oral, pruebas, y código fuente para comunicar la estructura y propósito del sistema.

 Su dependencia de un proceso de diseño evolutivo que dura lo que dura el sistema.  Su dependencia de la estrecha colaboración de los programadores con conocimientos

comunes.

 Su dependencia de las prácticas que funcionan tanto con los instintos de corto plazo de los programadores y como de los intereses a largo plazo del proyecto.

Como se mencionó anteriormente, XP es considerado una metodología ágil para el desarrollo de software, por lo que suele ser complementario a Scrum (que es menos técnico y más enfo-cado hacia la gestión de proyectos) [1].

Ilustración 3. XP. (Tomado de [41])

En la primera versión de XP, este era definido con 4 valores, 15 principios básicos y 20 prác-ticas, y se indicaba de manera muy estricta que para poder ser XP, se tenían que cumplir las 20 prácticas propuestas, sin embargo, desde su segunda edición, pasó a ser definido por me-dio de 5 valores, 14 principios, 13 prácticas primarias y 11 de corolario [42].

 Valores.

Página 30 o Retroalimentación. o Coraje. o Respeto.  Principios. o Humanidad. o Económico. o Beneficio mutuo. o Auto-semejanza. o Mejora. o Diversidad. o Reflexión. o Flujo. o Oportunidad. o Redundancia. o Fracaso. o Calidad.

o Responsabilidad aceptada.  Prácticas.

o Primarias.

 Planeación y Análisis de Requerimientos.  Historias.

 Ciclo seminal.  Ciclo trimestral.  Flojo.

 Factores humanos y equipo.  Sentarse juntos.  Todo el equipo.

 Espacio de trabajo informativo.  Trabajo energizado.

 Programación en pares.  Pares.

 Diseño.

 Diseño incremental.

 Programación de “primero prueba”.

 Codificación de software y liberación.  Compilación de 10 minutos.  Integración continua. o Prácticas de corolario.

 Planeación y Análisis de Requerimientos.  Participación real del cliente.  Despliegue incremental.  Contrato de alcance negociado.  Pago por uso.

 Contracción de equipos.  Diseño.

 Análisis de origen de causa.  Codificación de software y liberación.

 Código y pruebas.  Código compartido.  Código base único.  Despliegue diario. 2.2.3 Kanban

Este no es un método para el desarrollo de software, sino para la gestión de proyectos; y aun-que poco a poco se ha ido adaptando a los proyectos referentes al software (gracias a David J. Anderson quien adaptó el método original al desarrollo de software [43], y a Microsoft quien lo usó por primera vez), fue pensado inicialmente para ayudar en los procesos de producción de Toyota, usando técnicas JIT (Just-In-Time). Esta metodología de gestión, tiene como base fundamental los principios Lean, y presenta su practicidad en el uso de tarjetas para modelar actividades. Precisamente por esto el nombre de Kanban, ya que es una palabra del japonés, que etimológicamente hablando traduce “Kan” visual y “ban” tarjeta. Estas tarjetas se usan comúnmente para identificar necesidades de material en la cadena de producción. [44] [45]

Kanban sugiere sistemas de producción altamente efectivos, regidos por algunos principios

—que reflejan que su origen viene de Lean— y que dependiendo el autor, pueden variar, pero

aun así, mantienen la esencia. Los principios Kanban son [45]:

 Calidad garantizada.  Reducción de desperdicio.  Mejora continua.

 Flexibilidad.

Algo fundamental en este método es el uso de un tablero de tareas para mejorar el flujo de trabajo durante el proyecto. Algunos autores proponen diferentes formas o pasos para acomo-dar la estrategia a ser usada con el tablero, y que más se acomode al proyecto. Algunos de estos pasos consisten en [45]:

1. Definir el flujo de trabajo del proyecto.

a. Crear un tablero visible por todos los miembros del equipo.

b. Cada columna del tablero consiste en un estado concreto del flujo de tareas. c. Deben existir tantas columnas como estados tenga que pasar una actividad. d. Las actividades se gestionan de manera continua y no por Sprints.

e. Las nuevas tareas son acumuladas en la sección inicial y priorizadas luego por el cliente.

2. Visualizar las fases del ciclo de producción. a. Principio de desarrollo incremental.

b. Cada tarea es una serie de pasos para agilizar el proceso de producción. c. Cada paso se puede representar con un “post-it”.

Página 32

e. Cada “post-it” contiene información básica del paso: descripción +

estima-ción de duraestima-ción.

f. Pueden ser usados más elementos en el tablero para detallar mejor cada acti-vidad.

g. La idea es clarificar al máximo el trabajo a realizar, las tareas asignadas, la priorización y la meta asignada.

3. Stop starting, start finish.

a. Se prioriza el trabajo que está en curso en vez de comenzar tareas nuevas. b. El trabajo en curso debe estar limitado, por lo que existe un número máximo

de tareas a realizar en cada fase.

c. No se puede abrir una nueva tarea sin finalizar otra. 4. Control de flujo.

a. No se aplica a un solo proyecto, sino que mezcla tareas y proyectos. b. Flujo de trabajo constante.

c. Tareas importantes en cola y seguimiento pasivo para no interrumpir el traba-jo.

En la actualidad este “sistema de producción altamente eficiente y efectivo”, se ha venido

implementando para la gestión de proyectos de desarrollo de software, teniendo principal afinidad con las Metodologías Ágiles. Como se mencionó anteriormente, este permite gestio-nar de una manera general la forma en la que se van completando las tareas, de una manera visual, permitiendo facilidades a la hora de establecer el estado del proyecto. Adicionalmente es de fácil utilización, actualización y apropiación por parte del equipo, por lo que se convier-te en una excelenconvier-te herramienta para complementar la metodología de desarrollo selecciona-da.

2.3 SEMAT

Es una iniciativa tomada por Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence y Svante Lidman que busca redefinir la Ingeniería de Software por medio de lo que los autores

consideran como “La esencia de la Ingeniería de Software: El núcleo de SEMAT”. [46]

SEMAT busca dicha redefinición basándose en una teoría sólida, principios probados y las mejores prácticas aplicables a los proyectos de software, de manera que [36]:

 Se incluya un núcleo (Kernel) de elementos ampliamente aceptados y que se puedan extender a usos específicos.

 Traten asuntos tecnológicos y humanos.

 Los apoyen la industria, la academia, los investigadores y los usuarios.  Apoyen la extensión ante los requisitos cambiantes y la tecnología.

SEMAT se enfoca fundamentalmente en dos objetivos principales, y que son independientes el uno del otro [36]:

Para definir el Kernel, lo principal fue identificar un terreno común que de alguna u otra for-ma definiera a la Ingeniería de Software. Una vez identificado ese terreno, se determinó un conjunto de elementos esenciales que son universales a todos los esfuerzos de desarrollo de software y un lenguaje sencillo para describir métodos y prácticas. Luego de definidos los

elementos esenciales, estos fueron clasificados en 2 grandes grupos, algunos, dentro de “las cosas con las que siempre trabajamos” cuando se desarrollan sistemas de software (Ver

Ilus-tración 4), y los demás dentro de “las cosas que siempre hacemos” en dichos proyectos (Ver

Ilustración 5). Estos dos grupos (y más en específico, los elementos al interior de cada uno) son lo que se conoce en SEMAT como la esencia del Kernel. [36]

Ilustración 4. "Cosas con las que siempre trabajamos". (Tomado de [36])

Ilustración 5. "Cosas que siempre hacemos". (Tomado de [36])

Página 34

Teniendo en cuenta todo el proceso anteriormente descrito, y previamente identificados los principios del Kernel de SEMAT, se puede decir que dicho Kernel proporciona [36]:

 Un marco de pensamiento para que los equipos razonen sobre el progreso que están haciendo y la salud de sus esfuerzos.

 Un terreno común para la discusión, mejoramiento, comparación e intercambio de métodos y prácticas de ingeniería de software.

 Un marco para que los equipos ensamblen y mejoren continuamente su forma de tra-bajo, mediante la composición de prácticas definidas por separado y de diverso ori-gen.

 Un fundamento para la definición de medidas que no dependan de las prácticas, para evaluar la calidad del software producido y los métodos que se usan para producirlo.  Y lo más importante, una forma de ayudarle a los equipos a comprender dónde están,

qué deberían hacer luego y dónde necesitan mejorar.

De acuerdo a esto, el Kernel asegura que todos los aspectos esenciales de la Ingeniería de software serán considerados en los proyectos. Adicionalmente, teniendo en cuenta que se trata de mantener independiente a prácticas de metodologías en específico, y que apoya los valores del Manifiesto Ágil, el Kernel valora a los individuos e interacciones por encima de los procesos y las herramientas. [36]

Así mismo, considera más importante las necesidades de los miembros de cada equipo, y los

valores del “uso de métodos”, por encima de “la descripción de las definiciones de los méto-dos”, apoyado en las mejores prácticas modernas de la Ingeniería de Software y permitiendo

hacer uso de la metodología que se desee [36]. A continuación se profundiza un poco sobre

“las cosas con las que siempre trabajamos”, es decir, sobre los Alfas:

2.3.1 Los Alfas

Son elementos fundamentales del Kernel y esenciales a la Ingeniería de Software. Estos, han sido considerados como conjuntos de estados, en vez de elementos de trabajo (como docu-mentación o herramientas de software), ya que así representan el progreso y salud del proyec-to, y a la Ingeniería de Software en general –no a metodologías en específico–. [36]

Han sido identificados 7 Alfas, los cuales, como se mencionó anteriormente, corresponden a

“las cosas con las que siempre trabajamos”. Cada Alfa tiene estado una serie de Estados,

quienes de igual manera se encuentran asociados una lista de chequeo que especifica los cri-terios necesarios para alcanzar todo el estado [36]. Para un mayor detalle sobre los Alfas y sus Estados, diríjase a la Sección 2.4.1 de La “Guía”.

2.3.1.1 Alfa Oportunidad

Ilustración 6. Alfa Oportunidad. (Tomado de [47])

Es la oportunidad que une a los Stakeholders y proporciona la motivación para producir una actualización o un nuevo sistema de software. Es entendiendo la oportunidad que se puede identificar el valor y resultado deseado que los Stakeholders esperan realizar del uso del sis-tema de software, ya sea solo como una parte de todo el negocio, o como una solución técni-ca. Los estados de este Alfa son [47]:

Página 36

2.3.1.2 Alfa Stakeholders

Los Stakeholders proporcionan la Oportunidad, y son la fuente de los requerimientos. Ellos están involucrados a lo largo del proceso de Ingeniería de Software con el fin de apoyar al equipo y asegurar la aceptación del sistema de software. [47]

Ilustración 8. Alfa Stakeholders. (Tomado de [47])

Los Stakeholders son fundamentales para el éxito del sistema y del trabajo realizado para producirlo. Sus comentarios y aportes en general, ayudan a dar forma a todo el sistema y al software resultante. Los estados de este Alfa son [47]:

2.3.1.3 Alfa Requerimientos

Este Alfa se refiere a lo que debería hacer el software para dirigir la oportunidad y satisfacer las necesidades de los Stakeholders. [47]

Ilustración 10. Alfa Requerimientos. (Tomado de [47])

Los requerimientos son capturados como un conjunto de ítems. Estos pueden ser comunica-dos y almacenacomunica-dos de varias formas y con distintos niveles de detalle. Así como es importan-te que los requerimientos totales sean enimportan-tendidos, es necesario que los íimportan-tems acá usados de manera individual también lo sean. Entre otras cosas esto ayudaría a determinar cuándo un sistema ya está terminado, e inclusive a determinar si un requerimiento está dentro del alcan-ce. Los estados de este Alfa son [47]:

Página 38

2.3.1.4 Alfa Sistema de Software

Ilustración 12. Alfa Sistema de Software. (Tomado de [47])

Un sistema de software se diferencia de otros sistemas ya que a pesar de estar compuesto por una combinación de software, hardware y datos con el fin de cumplir a cabalidad con los requerimientos, este proporciona valor principalmente por medio de la ejecución de software. Dicho sistema puede ser parte de otro software, hardware, negocio o solución social más grande que la que este pretende abarcar. Los estados de este Alfa son [47]:

2.3.1.5 Alfa Equipo

El equipo corresponde a un grupo de personas que se encuentran activamente comprometidas al interior del proyecto. Esto quiere decir, durante el desarrollo, mantenimiento, entrega o soporte del sistema de software. [47]

Ilustración 14. Alfa Equipo. (Tomado de [47])

A pesar de que un equipo está compuesto por varias personas, cada una de las cuales con habilidades distintas, la guía que proporcionan los Alfas sólo debe ser usada por una persona (líder), con el fin de evitar ambigüedades. Los estados de este Alfa son [47]:

Página 40

2.3.1.6 Alfa Trabajo

Ilustración 16. Alfa Trabajo. (Tomado de [47])

La habilidad de los miembros para coordinar, organizar, estimar, completar y compartir su trabajo, tiene un profundo efecto en el cumplimiento de los compromisos y entrega de valor a los Stakeholders. Los miembros del equipo deben entender cómo llevar a cabo su trabajo, y cómo reconocer cuándo el trabajo está bien hecho. Los estados de este Alfa son [47]:

2.3.1.7 Alfa Forma de Trabajar

La forma de trabajar se puede ver como el conjunto de prácticas y herramientas usadas por un equipo para guiar y soportar su trabajo [47].

Ilustración 18. Alfa Forma de Trabajar. (Tomado de [47])

El equipo debe entender que es un equipo, y que esto implica trabajo colaborativo, para lo que es necesario que entre los mismos miembros se hagan acuerdos de cooperación que los guíen durante el esfuerzo que implica cualquier proceso de Ingeniería de Software. Los esta-dos de este Alfa son [47]:

Página 42

2.4 Modelado de Requerimientos

Una de las principales problemáticas que genera el uso de procesos tradicionales de Ingenie-ría de Requerimientos, es precisamente la gestión sobre los requerimientos. En sistemas muy grandes, se hace demasiado difícil su administración, y no siempre las herramientas que hay en el mercado son lo suficientemente versátiles como para permitir a los Ingenieros de Soft-ware operar con facilidad y efectividad. Caso similar sucede con procesos ágiles –los cuales

funcionan muy bien cuando se desarrollan sistemas pequeños que impliquen pocos requeri-mientos, pero que se complican una vez el número de estos aumenta– en proyectos

demasia-do grandes. [48]

Teniendo en cuenta lo anterior, también se puede agregar que la principal barrera que presen-ta el ser humano, es la capacidad de procesar gran cantidad de información de manera simul-tánea, por lo que en sistemas que implican muchos requerimientos, la forma más efectiva de

tratarlos es por medio de modelos que proporcionen una visión “más simple”, pero a la vez,

(posiblemente) más completa de lo que podría decirse solo con palabras [48]. En este caso

aplica perfectamente aquel dicho que dice que “…una imagen vale más que mil palabras…”.

Es por lo anterior que se han desarrollado varias iniciativas para el modelado de requerimien-tos, siendo algunas de las más famosas y usadas las de KAOS (propuesta por las Universida-des de Oregon y Louvain) [49] y i* [50]. Dichas metodologías de modelado han servido de ayuda por mucho tiempo para poder determinar requerimientos en proyectos de desarrollo de software, no obstante esto, para la elaboración de esta guía, será usada la propuesta realizada

por Joy Beatty y Anthony Chen, en su libro “Visual Models for Software Requirements”

[48].

Un modelado de requerimientos implica que debe haber un lenguaje diseñado

específicamen-te para que estos modelos puedan se visuales y estructurados, esto hace que su “consumo” se

facilite para Stakeholders de tipo ejecutivo, de negocio y técnicos [48]. En el caso de este documento, será usado RML como lenguaje de modelado.

Ilustración 20. Clasificación OPSD de modelos RML. (Tomado de [48])

Los modelos de Objetivos describen el valor que genera el sistema al negocio, y ayudan a la priorización de requerimientos basándose en el valor generado. Es importante en todo proyec-to realizar solo las cosas que generen valor para el negocio. Este tipo de modelos se usa en etapas tempranas del proyecto para determinar junto a los Stakeholders el valor que se gene-rará; y durante el proyecto para identificar qué objetivos han sido o no satisfechos por los requerimientos [48]. Los modelos propuestos en esta categoría son [48]:

 Modelo de Objetivos del Negocio.  Modelo de Cadena Objetivo.  Árbol de Características.

 Modelo de Correlación de Requerimientos.

Los modelos de Personas describen a los Stakeholders del sistema, sus procesos de negocio y sus objetivos. Así mismo ayuda a identificar grupos y subgrupos de personas que pueden proporcionar información valiosa a la hora de obtener los requerimientos [48]. Los modelos propuestos en esta categoría son [48]:

 Organigrama.

 Modelo de Flujo de Proceso.  Modelo de Casos de Uso.  Matriz de Roles y Permisos.

Los modelos de Sistemas describen al sistema actual, sus interfaces, y el comportamiento que se da cuando interactúan entre estas. Estos modelos sirven para determinar sistemas externos e internos con los que se interactúa [48]. Los modelos propuestos en esta categoría son [48]:

 Mapa del Ecosistema.  Flujo del Sistema.

 Flujo de Interfaz de Usuario.

[image:43.612.216.410.90.250.2]