revencyt-redidiciencia.métodos de desarrollo de

Cabral Alfonzo Marisela

Métodos de desarrollo de aplicaciones Web para PYMES parte 1

Universidad de Los Andes-Facultad de Ingeniería-Postgrado en Computación. 2011. p. 171

Venezuela

Disponible en:

http://bdigital.ula.ve/RediCiencia/busquedas/DocumentoRedi.jsp?file=33934&type=ArchivoDocumento

&view=pdf&docu=27092&col=5

¿Cómo citar?

http://bdigital.ula.ve/RediCiencia/busquedas/citacionDocumentos.jsp?docu=27092&col=5

http://bdigital.ula.ve/RediCiencia/busquedas/DocumentoRedi.jsp?file=33934&type=ArchivoDocumento&view=pdf&docu=27092&col=5




UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERIA

POSTGRADO EN COMPUTACIÓN

MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA

PYMES

Trabajo de Grado presentado ante la ilustre Universidad de Los Andes como requisito

final para optar al título de:

Magíster Scientiae en Computación.

Autor: Ing. Marisela Cabral A.

Tutor: Dr. Jonas A. Montilva.

Enero, 2011

MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES

- 2 -

RESUMEN

Los métodos de desarrollo de software son una guía de referencia y un requisito

fundamental para cualquier organización que desee producir software de calidad.

Tomando como requisito principal las necesidades de un método de desarrollo

que se adapte a nuestro país como entorno y al uso cada vez mayor de sistemas

basados en tecnologías Web, se diseño un método para el desarrollo de software

denominado Blue WATCH. Este método es una versión del método WATCH (Montilva J.,

Barrios. J. & Rivero, M., 2008), por lo tanto, hereda de él algunas características

fundamentales en su estructura y conceptualización, pero se diferencia en muchos

aspectos que le permiten dar respuestas a los requisitos expuestos.

El método especificado está diseñado para facilitar el desarrollo de aplicaciones

Web con equipos pequeños entre 3 y 10 personas y está claramente enfocado a buscar

un balance entre disciplina y agilidad, permitiendo a una organización pequeña ser

competitiva en términos de calidad y a su vez imprimiendo flexibilidad y agilidad en el

proceso de desarrollo de software.

Palabras claves: Métodos de desarrollo ágiles, aplicaciones Web, métodos de

desarrollo para PYMES.


- 3 -

TABLA DE CONTENIDOS

INTRODUCCIÓN............................................................................................................. 10

CAPITULO 1 ................................................................................................................... 14

DESCRIPCIÓN DEL PROBLEMA....................................................................................... 14

Definición del problema ..................................................................................................... 14

Justificación ........................................................................................................................ 15

Objetivos ............................................................................................................................. 16

Metodología de Investigación........................................................................................... 17

Alcance ................................................................................................................................ 19

Resumen ............................................................................................................................... 19

CAPITULO 2 ................................................................................................................... 20

MARCO TEÓRICO .......................................................................................................... 20

Conceptos Relacionados .................................................................................................... 20

Antecedentes ....................................................................................................................... 32

Análisis comparativo de métodos de desarrollo ágil ..................................................... 42

Equivalencia de términos ................................................................................................... 55

Agilidad y calidad ............................................................................................................... 56

Agilidad versus Disciplina .................................................................................................. 59

Identificación de los requisitos del método .................................................................... 60

Resumen ............................................................................................................................... 64

CAPITULO 3 ................................................................................................................... 65

EL MÉTODO BLUE WATCH ............................................................................................. 65

Meta modelo del Blue WATCH............................................................................................ 65

Método BLUE WATCH .......................................................................................................... 73

Evolución del Blue WATCH ................................................................................................. 73

Características del BLUE WATCH ....................................................................................... 74

Modelos del Blue WATCH ................................................................................................... 76

Resumen ............................................................................................................................... 77


- 4 -

CAPITULO 4 ................................................................................................................... 78

EL MODELO DE PRODUCTOS ......................................................................................... 78

Objetivos del modelo.......................................................................................................... 78

Componentes del modelo ................................................................................................... 80

Productos de Gestión ......................................................................................................... 82

Productos de Soporte ........................................................................................................ 88

Productos Técnicos ............................................................................................................ 96

Resumen ............................................................................................................................. 116

CAPITULO 5 ................................................................................................................. 117

EL MODELO DE ACTORES ............................................................................................ 117

Objetivos del modelo........................................................................................................ 117

Componentes del modelo de actores .............................................................................. 118

Clasificación de Interesado del Blue WATCH .................................................................. 118

Modelo de la Estructura Organizacional del Equipo de Desarrollo .......................... 120

Ejemplos de estructura organizativa ............................................................................. 124

Descripción de roles y responsabilidades del equipo de Desarrollo............................ 125

Resumen ............................................................................................................................. 135

CAPITULO 6 ................................................................................................................. 136

EL MODELO DE PROCESOS .......................................................................................... 136

Objetivos del modelo........................................................................................................ 136

Metáfora del Reloj ........................................................................................................... 137

Procesos de Gestión ......................................................................................................... 144

Procesos de Soporte ......................................................................................................... 172

Resumen ............................................................................................................................. 188

CAPITULO 7 ................................................................................................................. 189

PROCESOS TÉCNICOS .................................................................................................. 189

Procesos Técnicos: Ciclo de la Aplicación....................................................................... 189

Procesos Técnicos: Ciclo de la Versión ........................................................................... 209

Procesos Técnicos: Ciclo del Incremento........................................................................ 227


- 5 -

Resumen ............................................................................................................................. 245

CAPITULO 8 ................................................................................................................. 247

CASO DE ESTUDIO ....................................................................................................... 247

Descripción de los Casos de Estudio ................................................................................ 247

Resultados......................................................................................................................... 254

Resumen ............................................................................................................................. 254

CAPITULO 9 ................................................................................................................. 255

CONCLUSIONES Y RECOMENDACIONES ...................................................................... 255

Recomendaciones .............................................................................................................. 260

BIBLIOGRAFIA ............................................................................................................. 261


- 6 -

INDICE DE FIGURAS

CAPITULO 2: DESCRIPCIÓN DEL PROBLEMA Figura 1 - 1 Metodología de Investigación ..................................................................... 17 CAPITULO 3: EL MÉTODO BLUE WATCH Figura 3 - 1 Meta Modelo del método Blue WATCH ....................................................... 66 Figura 3 - 2 Meta Modelo de Actores del Blue WATCH ................................................... 67 Figura 3 - 3 Meta Modelo de Productos del Blue WATCH ............................................... 69 Figura 3 - 4 Meta Modelo de Procesos del Blue WATCH ................................................. 70 CAPITULO 4: MODELO DE PRODUCTOS Figura 4 - 1 Modelo de Productos del Método Blue WATCH ........................................... 81 Figura 4 - 2 Visión del Producto ..................................................................................... 84 Figura 4 - 3 Plan de Proyecto ......................................................................................... 87 Figura 4 - 4 Matriz de Riesgos ........................................................................................ 90 Figura 4 - 5 Documento de Configuración ...................................................................... 91 Figura 4 - 6 Especificación de Pruebas ........................................................................... 92 Figura 4 - 7 Resultados de la Pruebas ............................................................................ 93 Figura 4 - 8 Modelo de Negocio ..................................................................................... 98 Figura 4 - 9 Documentos de Requisitos ........................................................................ 100 Figura 4 - 10 Documentos de Casos de Uso .................................................................. 104 Figura 4 - 11 Documentos de Diseño ............................................................................ 105 Figura 4 - 12 Arquitectura de la Aplicación .................................................................. 107 Figura 4 - 13 Diseño de Interfaz Web ........................................................................... 108 Figura 4 - 14 Diseño Detallado ..................................................................................... 111 Figura 4 - 15 Diseño de Base de Datos ......................................................................... 113 Figura 4 - 16 Aplicación Empresarial ............................................................................ 115 CAPITULO 5: MODELO DE ACTORES Figura 5 - 1 Clasificación de los roles para actores del Blue WATCH ............................. 119 Figura 5 - 2 Modelo de Actores del Blue WATCH .......................................................... 121 Figura 5 - 3 Tabla de solapamiento de funciones Rol vs Rol .......................................... 123 Figura 5 - 4 Estructura Organizativa completa del Blue WATCH ................................... 124 Figura 5 - 5 Estructura Organizativa mínima del Blue WATCH ...................................... 125 Figura 5 - 6 Roles del Equipo de Desarrollo .................................................................. 126 CAPITULO 6: MODELO DE PROCESOS Figura 6 - 1 Ciclo de la Aplicación ................................................................................. 138 Figura 6 - 2 Ciclo de la Versión ..................................................................................... 139 Figura 6 - 3 Ciclo del Incremento .................................................................................. 140 Figura 6 - 4 Cadena de Valor ........................................................................................ 143 Figura 6 - 5 Ciclo de la Versión ..................................................................................... 143 Figura 6 - 6 Ciclo del Incremento .................................................................................. 144 Figura 6 - 7 Proceso de Gestión del Proyecto................................................................ 147


- 7 -

Figura 6 - 8 Inicio del Proyecto ..................................................................................... 148 Figura 6 - 9 Inicio del Proyecto ..................................................................................... 149 Figura 6 - 10 Planificación del Proyecto ....................................................................... 152 Figura 6 - 11 Planificación de la Aplicación .................................................................. 153 Figura 6 - 12 Planificación de la Aplicación .................................................................. 154 Figura 6 - 13 Planificación del Desarrollo de Requisitos ................................................ 154 Figura 6 - 14 Estimar el Proyecto ................................................................................. 155 Figura 6 - 15 Planificación de la Versión ....................................................................... 156 Figura 6 - 16 Planificación de la Versión ....................................................................... 157 Figura 6 - 17 Planificación del Incremento ................................................................... 158 Figura 6 - 18 Planificación del Incremento ................................................................... 158 Figura 6 - 19 Dirección del Proyecto ............................................................................. 159 Figura 6 - 20 Dirección del Proyecto ............................................................................. 160 Figura 6 - 21 Control del Proyecto ................................................................................ 161 Figura 6 - 22 Control del Proyecto ................................................................................ 162 Figura 6 - 23 Cierre de la Fase ...................................................................................... 165 Figura 6 - 24 Cierre del Incremento .............................................................................. 167 Figura 6 - 25 Cierre del Incremento .............................................................................. 167 Figura 6 - 26 Cierre de la Versión ................................................................................. 168 Figura 6 - 27 Cierre de la Versión ................................................................................. 169 Figura 6 - 28 Cierre del Proyecto .................................................................................. 170 Figura 6 - 29 Cierre del Proyecto .................................................................................. 171 Figura 6 - 30 Procesos de Soporte ................................................................................ 173 Figura 6 - 31 Gestión de la Configuración..................................................................... 175 Figura 6 - 32 Configuración Inicial del Ambiente .......................................................... 175 Figura 6 - 33 Control de la Configuración ..................................................................... 177 Figura 6 - 34 Control de Cambios ................................................................................. 178 Figura 6 - 35 Respaldo de la Configuración .................................................................. 179 Figura 6 - 36 Gestión de Riesgos .................................................................................. 180 Figura 6 - 37 Identificación de los Riesgos .................................................................... 181 Figura 6 - 38 Análisis de Riesgos .................................................................................. 182 Figura 6 - 39 Control de Riesgos ................................................................................... 183 Figura 6 - 40 Gestión de la Calidad............................................................................... 185 Figura 6 - 41 Aseguramiento de la Calidad de los Procesos .......................................... 186 Figura 6 - 42 Revisión del Producto (entre pares) ......................................................... 187 Figura 6 - 43 Revisión del Proceso de Pruebas .............................................................. 188 CAPITULO 7: PROCESOS TÉCNICOS Figura 7 - 1 Procesos Técnicos Ciclo de la Aplicación .................................................... 189 Figura 7 - 2 Modelado de Negocio ............................................................................... 191 Figura 7 - 3 Definición del Sistema de Negocios ........................................................... 193 Figura 7 - 4 Modelado de Objetos de Negocios ............................................................ 194 Figura 7 - 5 Modelado de Procesos de Negocios .......................................................... 194 Figura 7 - 6 Validación del Sistema de Negocios........................................................... 195


- 8 -

Figura 7 - 7 Desarrollo de Requisitos ............................................................................ 198 Figura 7 - 8 Identificación de Requisitos ....................................................................... 199 Figura 7 - 9 Análisis de Requisitos ................................................................................ 200 Figura 7 - 10 Diseño Arquitectónico ............................................................................. 201 Figura 7 - 11 Definición de Metas y Requisitos Arquitectónicos .................................... 202 Figura 7 - 12 Descomposición del Sistema en Subsistemas ........................................... 203 Figura 7 - 13 Elaboración de la Vista Funcional ............................................................ 204 Figura 7 - 14 Elaboración de la Vista Estructural .......................................................... 205 Figura 7 - 15 Elaboración de la Vista de Despliegue ..................................................... 206 Figura 7 - 16 Definición de Versiones ........................................................................... 207 Figura 7 - 17 Validación de la Arquitectura .................................................................. 208 Figura 7 - 18 Procesos Técnicos Ciclo de la Versión ...................................................... 209 Figura 7 - 19 Refinamiento del Modelo de Negocio ...................................................... 210 Figura 7 - 20 Refinamiento del Modelo de Negocio ...................................................... 211 Figura 7 - 21 Revisión de la Arquitectura...................................................................... 212 Figura 7 - 22 Refinamiento de los Requisitos ................................................................ 212 Figura 7 - 23 Establecer Línea Base para la Versión i .................................................... 214 Figura 7 - 24 Diseño Detallado de la Versión i .............................................................. 215 Figura 7 - 25 Diseño del Prototipo de Interfaz Web ...................................................... 216 Figura 7 - 26 Diseño de la BD ....................................................................................... 217 Figura 7 - 27 Diseño conceptual de la BD ..................................................................... 218 Figura 7 - 28 Diseño Físico de la BD .............................................................................. 218 Figura 7 - 29 Especificación de Requisitos de la Versión i ............................................. 220 Figura 7 - 30 Diseño de pruebas de la Versión i ............................................................ 221 Figura 7 - 31 Definición de Incrementos ....................................................................... 222 Figura 7 - 32 Desarrollo de Incrementos de la Versión i ................................................ 223 Figura 7 - 33 Entrega de la Versión i ............................................................................ 224 Figura 7 - 34 Empaquetar la versión de entrega........................................................... 224 Figura 7 - 35 Desplegar la Versión i de la aplicación ..................................................... 225 Figura 7 - 36 Capacitar a los Usuarios .......................................................................... 226 Figura 7 - 37 Desarrollo de Incrementos de la Versión i ................................................ 227 Figura 7 - 38 Refinamiento de los productos de la iteración j-1 .................................... 228 Figura 7 - 39 Diseño Detallado del Incremento j ........................................................... 229 Figura 7 - 40 Especificación de Requisitos del Incremento j .......................................... 230 Figura 7 - 41 Diseño de la Interfaz Web del Incremento j ............................................. 231 Figura 7 - 42 Diseño de Pruebas del Incremento j ......................................................... 232 Figura 7 - 43 Diseño Estructural del Incremento j ......................................................... 233 Figura 7 - 44 Diseño Dinámico del Incremento j ........................................................... 234 Figura 7 - 45 Codificación e Integración del Incremento j ............................................. 235 Figura 7 - 46 Codificación de cada CU del Incremento .................................................. 237 Figura 7 - 47 Codificación de pruebas del Incremento .................................................. 238 Figura 7 - 48 Verificación del programador .................................................................. 239 Figura 7 - 49 Pruebas del Incremento j ......................................................................... 240


- 9 -

Figura 7 - 50 Despliegue para Pruebas del Incremento j ............................................... 241 Figura 7 - 51 Pruebas del Incremento j ......................................................................... 242 Figura 7 - 52 Entrega del Incremento j ......................................................................... 243 Figura 7 - 53 Despliegue del Incremento j .................................................................... 244 Figura 7 - 54 Demostración del Incremento j ................................................................ 245

INDICE DE TABLAS

CAPITULO 2: MARCO TEÓRICO Tabla 2 - 1 Características por tamaño de la empresa .................................................... 27 Tabla 2 - 2 Vista Estructural o de Procesos (Parte 1) ...................................................... 44 Tabla 2 - 3 Vista Estructural o de Procesos (Parte 2) ...................................................... 45 Tabla 2 - 4 Vista Estructural o de Procesos (Parte 3) ...................................................... 46 Tabla 2 - 5 Vista del Dominio de Aplicación .................................................................... 48 Tabla 2 - 6 Vista del Producto ........................................................................................ 49 Tabla 2 - 7 Vista Organizacional .................................................................................... 52 Tabla 2 - 8 Vista Funcional o de Uso (Parte 1) ................................................................ 53 Tabla 2 - 9 Vista Funcional o de Uso (Parte 2) ................................................................ 54 Tabla 2 - 10 Equivalencia de términos ............................................................................ 55 Tabla 2 - 11 Agilidad Versus Disciplina ........................................................................... 60 CAPITULO 8: CASO DE ESTUDIO Tabla 8 - 1 Organización del equipo de desarrollo Proyecto A ...................................... 247 Tabla 8 - 2 Organización del equipo de desarrollo Proyecto B ...................................... 251


- 10 -

INTRODUCCIÓN

Los métodos de desarrollo de software son guías o patrones orientados a

garantizar que los proyectos de esta área puedan llevarse a cabo de manera exitosa,

tratando de asegurar que los productos estarán listos a tiempo y cumplan con los

requisitos básicos de calidad.

Los métodos o marcos metodológicos, generalmente, deben ser instanciados

cada vez que requieran ser utilizados. Esto es, adaptados a la situación real,

empleándose como guías que señalan el proceso a seguir para desarrollar la aplicación

que se desea construir.

En el campo de la Ingeniería de Software existen enfoques distintos de cómo

atacar el desarrollo de una aplicación empresarial. Por un lado, se encuentran las

metodologías tradicionales que se caracterizan por ser rígidas, con procesos más

formales y detallados, donde es necesaria la participación de distintos especialistas para

cumplir con las actividades señaladas por el método. En contraposición, existen las

metodologías ágiles, que permiten un espacio abierto para afrontar los cambios y tomar

decisiones más espontáneas basadas en la experiencia del equipo de desarrollo.

Las metodologías más disciplinadas generalmente se adaptan bien a

organizaciones con gran número de empleados y donde los proyectos de software

pueden ser grandes y complejos. Estos proyectos son abordados por equipos

multidisciplinarios de gran cantidad de integrantes que facilitan cubrir todos los

aspectos del ciclo de vida de software. Afrontar un proyecto con estas características

requiere estructura y claras directrices que permitan alinear las actividades a ejecutar.


- 11 -

Sin embargo, cuando los proyectos de software son ejecutados por equipos

pequeños -como a menudo ocurre en el entorno nacional- el uso de este tipo de

metodologías puede convertirse en un trabajo demasiado tedioso y difícil de cumplir,

imprimiendo lentitud y baja capacidad de respuesta al equipo. Para estas situaciones, es

necesario contar con cierta flexibilidad y menos formalidad, con el fin de que las

actividades del día a día no se vean ahogadas en cantidades de documentos que las

metodologías muy disciplinadas requieren. Esto no significa la ausencia de estructura o

disciplina y mucho menos de documentación, sólo que la misma va a existir de manera

más efectiva, atacando los aspectos realmente necesarios para permitir afrontar el

proyecto de una manera más versátil.

Por otro lado, se conoce, según las encuestas realizadas por Methodius (2008),

que la mayoría de las organizaciones venezolanas que desarrollan software lo hacen de

manera empírica o inapropiada, utilizando métodos de desarrollo que no se adaptan a

sus características sui generis del entorno donde están ubicadas o utilizan métodos

obsoletos o mal implementados. De aquí la necesidad de elaborar métodos y procesos

de desarrollo de software que realmente se ajusten a las realidades de las

organizaciones en nuestro país, colaborando de esta manera a que nuestra industria de

software sea competitiva y cumpla con los requisitos de calidad deseados. El objetivo de

este trabajo es definir y especificar un método que se adapte mejor a las características

de una pequeña empresa ubicada en nuestro entorno nacional, buscando un balance

entre disciplina y agilidad, y que además estén enfocados al desarrollo de sistemas Web.

Esta propuesta forma parte de un conjunto de trabajos realizados en el marco

del Proyecto METHODIUS1, cuyo objetivo es la elaboración de métodos y modelos de

desarrollo de software adaptados al contexto nacional y fundamentados en la Ingeniería

1 Proyecto de Fonacit 2005000165 “Métodos y Modelos de desarrollo de Software para Empresas Venezolanas” en el cual participan el Grupo de Investigación en ingeniería de datos y conocimiento (GIDyC) de la Universidad de los Andes, el Laboratorio de Investigación en Sistemas de Información (LISI) de la Universidad Simón Bolívar y el CEISoft de la Corporación Parque Tecnológico de Mérida (CPTM).


- 12 -

de Software para contribuir a mejorar los procesos productivos de empresas

venezolanas que desarrollan software para uso interno o comercial; y elevar la calidad

de sus productos.

El método WATCH (Montilva J., Barrios. J., 2008), forma parte de este proyecto,

contribuyendo en la consecución de estos objetivos a través de la definición de los

procesos técnicos, gerenciales y de soporte que se deben emplear durante el desarrollo

de software empresarial.

El trabajo a desarrollar forma parte de una de las versiones del método WATCH

orientada a adaptarse a proyectos con características como las anteriormente

mencionadas.

Este trabajo se organiza como sigue: El capítulo 1 contiene los aspectos teóricos

y conceptuales que sirven de marco a esta investigación, así como una breve

introducción a los antecedentes como el método WATCH y otros métodos de desarrollo

existentes en el mercado.

En el capítulo 2 se establecen los requisitos del método a partir de un análisis

comparativo entre distintos métodos agiles existentes y la consulta de otras

investigaciones y bibliografía.

El capítulo 3 presenta el meta-modelo sobre el cual se fundamenta el método

propuesto, a partir de sus tres modelos: actores, productos y procesos. Así mismo, se

expone la evolución del método, desde la versión inicial, a la desarrollada en este

trabajo de investigación.

El capítulo 4 es la descripción del modelo de productos del método Blue WATCH,

a través de la identificación de los objetivos del modelo, la descripción de sus

componentes y de cada uno de los tipos de productos: gestión, soporte técnicos.


- 13 -

El capítulo 5 presenta el modelo de actores del método Blue WATCH,

identificando de los objetivos del modelo, la descripción de sus componentes y los roles

y responsabilidades definidos para los actores del método.

En el capítulo 6 se describe el modelo de procesos, se explica la filosofía del

método y la metáfora sobre la cual está fundamentado su ciclo de vida. De igual manera

se describen los procesos transversales del método que son los procesos de gestión y los

de soporte.

Finalmente, en el capítulo 7 se describen los procesos medulares del método,

que son los procesos técnicos, estructurados dentro de sus tres ciclos: de la Aplicación,

de la Versión y del Incremento.

Durante el capítulo 8 se relata la experiencia del uso del método en dos casos de

estudio, es decir la aplicación del método en un proyecto real y las lecciones aprendidas

generadas por su utilización.

El capítulo 9 presenta las conclusiones y recomendaciones de este trabajo de

investigación.


- 14 -

CAPITULO 1

DESCRIPCIÓN DEL PROBLEMA

El objetivo del presente capitulo es describir el problema que motiva el

desarrollo del trabajo de investigación acá presentado y las razones que justifican su

realización. Así mismo se busca identificar los objetivos deseables a alcanzar como

producto de la ejecución de este trabajo y la metodología de investigación aplicada para

conseguirlos.

Definición del problema

Existe una creciente demanda de desarrollo de software a nivel mundial y

nuestro país no es la excepción. Cada día las necesidades en este sector se incrementan,

en especial, en el área del World Wide Web donde los continuos avances en las

tecnologías relacionadas y los nuevos paradigmas emergentes crean un espacio que

precisa ser atendido (compras electrónicas, búsqueda de información, redes sociales,

blogs, wikis, etc.). Esto hace que el software, en particular las aplicaciones Web, ocupen

un papel muy importante en nuestra sociedad debido a la gran variedad de usos y

aplicaciones que se les puede dar.

Aunado a lo anteriormente expuesto, según estudios y encuestas realizadas por

(Methodius, 2008), un gran porcentaje de las empresas, cooperativas u organizaciones

dedicadas al desarrollo de software en el país son empresas micros o pequeñas las

cuales en general no implementan una metodología acorde a sus capacidades o, en el

peor de los casos, no implementan ninguna metodología. Existe por consiguiente un

problema en el ámbito nacional que debe ser atendido para permitir que nuestra

industria de software sea competente y alcance niveles de calidad en sus productos.


- 15 -

Justificación

Diversos modelos y métodos han aparecido en años recientes, buscando resolver

los problemas que normalmente se enfrentan al momento de realizar un proyecto de

desarrollo de software. Entre los más conocidos y utilizadas podemos nombrar los

métodos ágiles y los modelos de medición de madurez. Estos marcos de trabajo, ofrecen

ciertas estrategias específicas que permiten a los equipos de desarrollo producir

software más robusto, predecible, reutilizable y de fácil mantenimiento. Pero la mayoría

de dichas metodologías y modelos de desarrollo no se adaptan fácilmente a la realidad

de las empresas venezolanas, lo cual ocasiona, al ser utilizadas, retrasos y frustraciones

en los equipos de desarrollo, así como, clientes insatisfechos.

Estos son los motivos por los que, orientados a dar solución a la necesidad de

nuestro país de contar con organizaciones capaces de crear software de calidad y

promover el avance tecnológico e investigativo de nuestra región, se plantea el

desarrollo y definición de un método que se adapte a las verdaderas características de

nuestra realidad, dando a los desarrolladores una herramienta que les permita mejorar

la manera en que realizan su trabajo, ofreciéndoles un marco de referencia y una

estructura clara como guía para desarrollar aplicaciones de altos niveles de calidad con

las particularidades ya comentadas.

El propósito de este trabajo que es diseñar y evaluar un método de desarrollo de

aplicaciones Web que se adapte a las características de las empresas venezolanas y,

particularmente, PYMES, el cual se encuentra justificado por las razones anteriormente

expuestas.


- 16 -

Objetivos

A continuación, se presentan los objetivos de este trabajo de investigación.

Objetivo General

Completar y evaluar el método Blue WATCH de desarrollo de aplicaciones Web

que se adapte a las características de las empresas venezolanas y, particularmente,

PYMES. Para lograr dicho objetivo se parte de una versión previa del método Blue

WATCH, la cual es ampliada y mejorada en este trabajo.

Objetivos Específicos

Comparar diferentes métodos de desarrollo de aplicaciones, existentes

en el mercado, con el fin de identificar las características necesarias que

debe cumplir un método de desarrollo orientado a equipos pequeños.

Identificar las características que debe tener un método para desarrollo

Web según los estándares y procesos existentes.

Identificar las características de las organizaciones que desarrollan

software en nuestro entorno nacional.

Ampliar y mejorar la versión inicial del método Blue WATCH

proporcionado por Methodius, tomando en cuenta los resultados

obtenidos en el estudio realizado.

Proporcionar una guía, en formato electrónico, con la documentación

necesaria para hacer uso del método desarrollado.


- 17 -

Metodología de Investigación

La estrategia de investigación utilizada está basada en la observación, el análisis

documental y la experiencia en el fenómeno o problema, además de la participación

sobre los eventos en nuestro caso de estudio, que es el proceso de desarrollo de

software.

La metodología de investigación que se utilizo durante este trabajo se resume en

la Figura 1 - 1:

analysis Metodologia de Inv estigacion

Rev isión de laLiteratura

Analisiscomparativo

Identificación de losrequisitos del método

Modelado de laestructura del

Método

Definición delMétodo

Validación yVerificación del

Método

«information»Libros,

publicaciones, guias, manaules

«information»Reporte,

Resultados, Recomendaciones

«information»Analisis de Tendencias, Estadisiticas

Identificación delproblema,

Justificación

Figura 1 - 1 Metodología de Investigación

El primer paso, Identificación del problema, Justificación, consistió en

establecer el propósito y alcance de la investigación así como la identificación del

problema y la justificación de la investigación

En una segunda etapa, Revisión de la Literatura, se realizó una revisión

documental tomando en cuenta investigaciones anteriores, trabajos existentes y las

tendencias actuales, a partir de esta revisión se llevo a cabo un Análisis Comparativo de

la información obtenida. La identificación de los requisitos del método se obtuvo a

partir de la observación de estudios pasados y experiencias recolectadas e

interpretando el análisis comparativo realizado.


- 18 -

La quinta etapa es el Modelado de la estructura del método que representa el

esqueleto o esquema en la cual debe estar organizado nuestro método. Esta estructura

se fundamenta en avances previos de trabajo sobre el método Blue WATCH y

considerando la estructura original del método WATCH.

La siguiente etapa fue la Definición del Método que está contenido dentro de la

estructura establecida, aquí se desarrollaron y documentaron los procesos, artefactos,

flujos de de trabajo y productos que tiene el cuerpo de métodos.

Una vez culminado el trabajo de definición, la última etapa fue la validación y

verificación del método donde se probó el método sobre un caso de estudio, es decir se

utilizó el método durante el desarrollo de un proyecto de software con las

características establecidas. El producto final de la investigación es un reporte de

resultados, así como la documentación del método y las recomendaciones finales.

Actividades

Para el desarrollo de este proyecto se siguieron las actividades, en el orden

indicado:

1) Investigación Documental: Revisión de los trabajos y avances logrados en el área

hasta el momento.

2) Especificación de Requerimientos: En esta etapa se realizará una definición

detallada de los requerimientos que la solución propuesta debe cumplir.

3) Elaborar una Ontología de Métodos de Software

4) Analizar y actualizar la estructura del método en EA.

5) Definir y documentar el modelo de Productos.

6) Definir y documentar el modelo de Procesos.

7) Verificar y validar el método.


- 19 -

8) Aplicar y validar el método a un caso real (Caso de estudio).

Alcance

El alcance de este proyecto es completar la definición del método Blue WATCH

de desarrollo de aplicaciones Web a partir de la estructura provista, asegurando que

este método se adapte a las características de las empresas venezolanas, en especifico,

a las microempresas que constituyen un porcentaje importante de las organizaciones

que producen el software que requiere la región. El método formará parte de la Suite de

metodologías WATCH (Montilva & Barrios, 2008), enmarcada en el Proyecto

METHODIUS.

Resumen

Durante este capítulo se realizo la identificación del problema que justifica el

desarrollo de este trabajo de investigación. Así mismo, se describieron los objetivos

generales y específicos que se establecieron para proyecto. Finalmente, se describió la

metodología con la que se ejecuto el trabajo de investigación acá descrito.


- 20 -

CAPITULO 2

MARCO TEÓRICO

En este capítulo, se presenta una breve descripción de los conceptos

relacionados con la investigación en curso. En primer lugar se explican definiciones

básicas como: método, metodología de desarrollo, proceso de desarrollo de software y

se identifican las diferencias entre estos conceptos.

Luego se abordan conceptos relacionados con los actuales estándares o

enfoques usados en el mundo del desarrollo de software como CMMI (Software

Engineering Institute (SEI, 2010) y los procesos de desarrollo ágiles.

Finalmente, se toca el tema objeto de la investigación al describir las

características de los tipos de organizaciones y se realiza un análisis sobre las

características de aplicaciones web y la descripción de algunas prácticas que se usan

para desarrollar este tipo de aplicaciones, como son el patrón MVC o el desarrollo

basado en componentes.

Conceptos Relacionados

1. Método

Etimológicamente, método proviene del latín y éste del griego, significando el

modo de obrar o proceder hacia la consecución de algo (Real Academia Española, 2010).

Un método se puede definir como una manera de proceder de una forma regular y

sistemática para conseguir algo, en el caso del desarrollo de software describe lo que

debe hacer el equipo de desarrollo para elaborar un producto de software. El beneficio

de usar un método radica no sólo en conseguir una manera de llevar a cabo una


- 21 -

actividad si no que esa actividad se convierta en reproducible, comunicable, accesible y

repetible como un resultado óptimo para las personas que lo utilicen.

2. Metodología de Desarrollo

Una metodología comprende el estudio o el análisis de los métodos, reglas y

postulados de una disciplina, la misma se puede ver como el conjunto particular de

métodos o procedimientos que se emplean para tratar un caso o situación.

Dentro de la Ingeniería de Software una metodología se enfoca en el estudio de

técnicas para elaborar estrategias de desarrollo de software que promuevan prácticas

adaptativas y predictivas. Se define, entonces, como el cuerpo de métodos empleados

por la Ingeniería de Software para producir, mantener y operar software.

Los métodos que comprenden una metodología tienen una característica en

común, ellos están diseñados para que los desarrolladores sean capaces de solucionar

los problemas del cliente a través de la ejecución de un proyecto de desarrollo de

software y durante este proceso se presentan situaciones que se deben enfrentar para

garantizar el éxito del proyecto, algunos de estos problemas no tienen nada que ver con

computadoras y puede atribuirse a otros factores como mala comunicación o a cambios

inesperados (Baird, 2002).

3. Proceso de desarrollo de software

Un proceso es un conjunto de actividades o eventos que se realizan o suceden

con un fin determinado para llegar a la solución de un problema u obtención de un

producto, en este caso particular, para lograr la obtención de un producto de software

que resuelva un problema.


- 22 -

Un proceso de desarrollo de software debe reflejar todos los pasos necesarios a

realizar durante todo el ciclo de vida del software, desde el análisis y diseño hasta la

implantación y mantenimiento del mismo.

4. CMMI

Capability Maturity Model Integration -CMMI- (Software Engineering Institute

(SEI), 2010) es una colección de buenas prácticas que responden a las necesidades de las

organizaciones en diferentes áreas de interés. CMMI es el sucesor de CMM (Capability

maturity model) y fue desarrollado por un grupo de expertos de la industria, el

gobierno, y el Software Engineering Institute (SEI) de la Universidad Carnegie-Mellon.

Los modelos CMMI proporcionan orientación para el desarrollo o mejora de los

procesos que se ajusten a los objetivos de negocio de una organización. CMMI también

puede ser utilizado como un marco para evaluar el proceso de madurez de la

organización y proporcionar a las organizaciones los elementos esenciales para la

mejora eficaz de sus procesos. Este modelo ayuda a integrar funciones tradicionalmente

separadas de organización, establecer objetivos de mejora de procesos y sus

prioridades, servir de orientación para los procesos de calidad, y proporcionar un punto

de referencia para evaluar los procesos actuales.

Aunque CMMI se originó en la Ingeniería de Software, ha logrado ser

generalizado a través de los años para abarcar otras áreas de interés, tales como el

desarrollo de productos de hardware, la entrega de todo tipo de servicios, y la

adquisición de productos y servicios.

Este modelo se ha convertido en una referencia necesaria para aquellas

organizaciones que desarrollan software y se encuentran en la necesidad de mejorar los

procesos de su organización, pues, ha demostrado que su implementación ayuda a

incrementar el desempeño y disminuir los costos de sus proyectos, y consecuentemente


- 23 -

elevar la calidad de los productos y servicios que generan. Adicionalmente, contar con

una certificación de un estándar como este le permite a la organización mejorar su

currículo y tener una ventaja competitiva con respecto a otras organizaciones.

5. Procesos de desarrollo Agiles

Así como CMMI emergió de la academia, la programación ágil emergió de las

experiencias de ingenieros veteranos. A diferencia de los modelos de madurez, cuyo

objetivo es controlar, medir y mejorar el proceso, la programación ágil ve al desarrollo

de software como una actividad caótica e irrepetible que requiere medición constante y

control inteligente a través del monitoreo. (Rawson, 2008).

El proceso ágil surgió de varios movimientos dentro del mundo del desarrollo de

software, uno de los más importantes y reconocidos es Scrum, este método no tiene

alto nivel de complejidad, es sencillo y flexible, con pautas básicas definidas. Está basado

en el supuesto de que los miembros del equipo de desarrollo son personas preparadas y

se puede confiar en ellos para llegar a las mejores soluciones. Otro de los método ágiles

más conocido es XP el cual combina adaptabilidad con altos estándares de calidad.

El enfoque ágil para el desarrollo de productos surgió de la necesidad de

mantener a las empresas competitivas y, de hecho, ha inspirado una revolución en el

desarrollo de software. El enfoque parte del principio de que los desarrolladores

necesitan estructura, pero no tanta como para ahogar la creatividad, los equipos gozan

de la confianza de poder auto gestionarse y auto organizarse, así como de afrontar los

inevitables cambios que surgen durante el transcurso del proyecto. Los desarrolladores

fijan sus propias reglas y metas, por lo que la responsabilidad de cumplir esos objetivos

recae plenamente sobre sus hombros. Los clientes son incluidos como miembros

valiosos del equipo de desarrollo, promueve la comunicación continua para que las

metas del proyecto sean constantemente articuladas y definidas con más detalle.


- 24 -

Este enfoque es flexible frente a los cambios en los requerimientos, permitiendo

a las partes interesadas modificar las metas del proyecto y los requisitos al final de cada

una de las iteraciones, esta flexibilidad garantiza que un producto no será obsoleto

porque puede adaptarse a los cambios del mercado.

Los equipos “ágiles” trabajan con iteraciones cortas, como máximo de 4

semanas, implementando piezas de funcionalidad pequeñas. Dentro de cada iteración

se incluye todas las fases del proceso de desarrollo: análisis, arquitectura, diseño,

codificación, pruebas y documentación. El producto, al final de cada iteración, es una

pieza de software completamente funcional.

Sin embargo, la aplicación completa no estará lista hasta realizar numerosas

iteraciones para completarla, pero al tener iteraciones cortas, los objetivos y prioridades

del proyecto son reconsiderados frecuentemente, lo que es muy llamativo desde el

punto de vista del cliente, ya que permite al equipo ser flexible frente al cambio de

requisitos. Así mismo, se consigue la validación y verificación continúa de lo

desarrollado, lo que ayuda a garantizar que el producto se desarrollará con código de

alta calidad.

El proceso ágil es liviano por qué no produce documentación detallada y si bien

hay directrices para el desarrollo, hay pocas reglas estrictas. Entre las criticas del

enfoque ágil está el no tener suficiente estructura, no asignar tiempo suficiente para

establecer la arquitectura del sistema, y el no tener una expectativa realista de que cada

fase de desarrollo puede ser abordado en menos de cuatro semanas. Sin embargo, los

defensores del enfoque dicen que el proceso funciona, y que ha sido validado con gran

aceptación en muchas empresas.

El enfoque ágil descansa en el Manifiesto Ágil (Manifiesto por el Desarrollo Ágil

de Software, 2010) el cual afirma lo siguiente:


- 25 -

“Estamos descubriendo formas mejores de desarrollar software tanto por

nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos

aprendido 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 seguir un plan”

6. PYMES (Pequeñas y Medianas Empresas)

Actualmente, no existe una definición oficial para el término PYME y el concepto

es un poco ambiguo, no existe un método formal de cómo medir el tamaño de una

empresa o una definición comúnmente aceptada pera el término. En el caso de las

pequeñas y medianas empresas, se pueden encontrar distintos puntos de vista; por

ejemplo, para Johnson y Brodman (Johnson & Brodman, 1998) una empresa pequeña

tiene: “menos de 50 empleados con proyectos pequeños de menos de 20

desarrolladores”. Mientras que para Laporte y asociados (Laporte, April, & Renault,

2006) es: “Cualquier ente u organización que preste servicios de TI o proyecto

conformado por 1 a 25 personas”.

Así como podemos definir una PYME desde el punto de vista del número de

empleados, también puede ser medida en términos de las ganancias que obtiene y la

cantidad de productos anuales que genera.

En el caso particular del contexto legal, cada país tiene su propia definición de lo

que es una PYME.

En Europa, por ejemplo, la pequeña a mediana empresa según la Comisión

Europea (European Commission, 2005), está categorizada en tres niveles: La Pequeña-

mediana, Pequeña y Micro. La Pequeña-mediana tiene menos de 250 empleados y la

ganancia anual no excede los 43 millones de euros. La Pequeña es la que emplea menos


- 26 -

de 50 personas y la ganancia anual no excede los 10 millones de euros, y la Micro es

aquella que tiene menos de 10 empleados.

La Organización para el Desarrollo y Cooperación Económica (The Organization

for Economic Co-operation and Development –OECD-) subdivide las PYMES en las

siguientes subcategorías: Micro, 0-9 empleados; Pequeñas, 10-49 empleados; y

Medianas, 50-250 empleados (o 500 en USA).

En el caso particular de Venezuela, que es nuestro objeto de estudio, una forma

para catalogar una empresa como PYME es la propuesta por el Instituto Nacional de

Estadística (INE) de Venezuela, el cual define como empresa pequeña aquella que

cuenta con entre 5 y 20 trabajadores, mediana cuando tienen entre 21 y 100

trabajadores y grande con más de 100 (Bastidas, 2003).

Para efectos del presente trabajo se utilizará la escala definida por el equipo de

trabajo del Proyecto Methodius donde se realizo un estudio para conocer el Estado de la

Industria Venezolana del Software (Rivero, Montilva, Barrios, Granados, & Murúa,

2009), aquí se determina el tamaño de una empresa basado en el número de empleados

de las mismas, bajo los siguientes criterios:

Microempresa: aquella empresa constituida por 1 a 5 trabajadores

Pequeña: aquella empresa constituida por 6 a 10 trabajadores.

Mediana: aquella empresa constituida por 11 a 19 trabajadores.

Grande: aquella empresa constituida por más de 19 trabajadores.

Existe un patrón presente en la mayoría de las PYMES en especial las

microempresas, en ellas funciones completas de la organización están concentradas en

pocas personas y tienen flexibilidad en los roles que ejerce el personal (P. Erard, 1999),


- 27 -

las PYMES no cuentan con departamentos especializados, pero necesitan las funciones

gerenciales de una empresa completa.

Se pueden identificar algunas características comunes en las PYMES, esto nos

puede ayudar a contar con una visión más general del dominio de estudio, algunos

autores (Di Paula, Parada, Pérez, & Mendoza, 2008) proporcionan el siguiente análisis:

Poca especialización de los recursos

Alta competitividad

Pocos recursos financieros

Falta de Herramientas y Tecnología

Procesos Flexibles (Flujos de trabajo)

Gran porcentaje de proyectos pequeños y medianos

Equipos pequeños y medianos de trabajo

Con jerarquía de unidades y cargos de máximo 2 o 3 niveles de jerarquía

Roles intercambiables y flexibles

Algunas diferencias de comportamiento entre las grandes y pequeñas empresas

se puede visualizar en la Tabla 2 - 1 (Laporte, Alexandre, & O’Connor, 2008).

Característica Empresa Pequeña Empresa grande Planificación No estructurada

/Operacional Estructurada/Estratégica

Flexibilidad Alta Estructurada/Estratégica Orientación al Manejo de riesgos

Alta Media

Procesos gerenciales Informal Bajo Capacidad de aprendizaje Limitada Alta Impacto de efectos negativos del mercado

Más profunda Más manejable

Ventaja competitiva Capital Humano Capital organizacional Tabla 2 - 1 Características por tamaño de la empresa


- 28 -

7. Aplicaciones Web

Las aplicaciones Web son aquellas aplicaciones de software cuya interfaz gráfica

está desarrollada en un lenguaje que permite ser accedida a través de Internet, es decir,

que utiliza un lenguaje que puede ser interpretado por un navegador, con el fin de

proporcionar a los usuarios un conjunto de servicios que, generalmente, no se ejecutan

en su estación de trabajo, si no en el servidor donde está alojada la aplicación. Los

navegadores Web son clientes ligeros que realizan peticiones al servidor de la

aplicación, el cual es en última instancia el que procesa estas peticiones.

El beneficio principal de este tipo de aplicaciones es que pueden ser accedidas

desde cualquier lugar que cuente con una conexión dentro del contexto donde está

alojada la aplicación (internet o intranet)

Algunas características que se pueden identificar de una aplicación Web con

respecto a una de escritorio son las siguientes (Bruno, Tam, & Thom, 2005) y (Mendoza,

2004)

Características de una aplicación Web

Se instala una sola vez: Las aplicaciones Web no requieren procesos de

instalación o espacio en disco duro de los clientes que utilizan la aplicación, ya

que al estar alojadas en un servidor significa que en el momento en que sea

desplegada siempre será la última versión.

Se Actualiza una sola vez: En vez de necesitar actualizar cada una de las licencias

existentes de cada usuario, las actualizaciones se hacen una vez en el servidor y

están disponibles en el momento que el usuario despliega la aplicación.

No hay versiones obsoletas: A diferencia de las aplicaciones de escritorio, al

desarrollar una aplicación Web no hay que preocuparse por usuarios que tienen


- 29 -

una versión anterior de la aplicación ya que todos comparten la versión actual

que está desplegada en el servidor de la aplicación.

Contenido descentralizado: Pueden ser accedidas por cualquiera que cuente con

un navegador y conexión en la red donde está alojada la aplicación, lo que

significa que la aplicación está virtualmente en cualquier lugar (de la red) y en

cualquier momento, los usuarios que viajan se benefician especialmente de esta

característica.

Independiente de la plataforma: Son los navegadores Web, las plataformas

sobre las que se despliega la aplicación.

No tienen conflictos con el ambiente: La cantidad de errores debidos al ambiente

se reducen al mínimo puesto que no dependen del ambiente del cliente si no del

servidor.

Permite la comunicación y colaboración: De los usuarios al permitir compartir su

trabajo o información en tiempo real.

Reduce costos de instalación y ventas asociados, los costos de mantenimiento y

soporte son menores que una aplicación de escritorio.

Integrable con el resto de las aplicaciones Web: al estar conectadas en el mismo

contexto pueden comunicarse con el resto de las aplicaciones Web disponibles.

Incrementa los riesgos de seguridad: Siempre se incrementan los riesgos cuando

se trabaja conectados a una red, ejecutar una aplicación conectada a Internet es

mucho más riesgoso que ejecutar una aplicación aislada.

Dependen de la conectividad: Las aplicaciones Web dependen de la continuidad

de la conectividad a Internet. Si no disponen de una conexión o si el servidor no

tiene conexión no se puede tener acceso a la información. Las aplicaciones

críticas y que necesiten la información a tiempo corren el riesgo de quedarse sin

servicio, los cortes de energía pueden interrumpir sus operaciones y acceso a

datos.

Lentitud: Son más lentas que las aplicaciones de escritorio ya que necesitan

transferir datos con mucha mayor frecuencia, la velocidad de respuesta también


- 30 -

puede verse afectada por la cantidad de usuarios accediendo a la aplicación al

mismo tiempo.

8. Practicas para la construcción de una aplicación Web

El paradigma de desarrollo de aplicaciones Web conlleva a la necesidad de

ejecución de actividades características y no triviales que a la larga afectan gran parte

del proceso de desarrollo. Algunos de los aspectos característicos diferenciadores que se

pueden apreciar en la construcción de este tipo de aplicaciones son los relacionados con

el diseño del dominio y la construcción de la interfaz de usuario.

La correcta selección de las tecnologías y decisiones de diseño acertadas pueden

ayudar a que el proceso se ejecuta de manera más fluida al adaptarse de manera

natural al desarrollo de este tipo de aplicaciones, así como facilitar la capacidad de

extensión y reusabilidad en los componentes de la aplicación.

A continuación, se describen algunas de las prácticas más comúnmente usadas

en el desarrollo de aplicaciones Web, debido a que se adaptan a los aspectos especiales

de este tipo de aplicaciones.

Desarrollo basado en componentes: Un componente es una pieza de software que

encapsula alguna funcionalidad y se comunica a través de interfaces de programación

estandarizada. El desarrollo basado en componentes parte de la división del sistema en

subsistemas o sub conjunto de funcionalidades relacionadas que la aplicación debe

suministrar. El desarrollo basado en componentes conduce a la reutilización del

software, lo que permite simplificar otras actividades como son el diseño y ejecución de

pruebas al hacer foco en un conjunto más pequeño, y mejorar la calidad del producto.

Simplifica, también, el mantenimiento, ya que se pueden actualizar y/o agregar

componentes según sea necesario, sin afectar otras partes del sistema. (Pressman,

2002)


- 31 -

Tecnologías basadas en el paradigma orientado a objetos (OO): Las tecnologías con el

enfoque OO facilitan la separación de conceptos y, por tanto, ayuda a extender las

funcionalidades de la aplicación y a la mejor implementación de patrones y

arquitecturas acordes a las tecnologías web.

Desarrollo por capas: El desarrollo por capas tiene por objeto la separación de

conceptos dentro de la arquitectura de la aplicación. La complejidad del desarrollo Web

ocurre en distintos niveles: dominio de la aplicación, navegabilidad e interfaz de

comunicación. En el desarrollo de aplicaciones Web, se requiere que se tomen en

cuenta los aspectos anteriormente explicados. Por un lado, la navegación y el

comportamiento funcional de la aplicación deberían ser integrados. Por otro lado,

durante el proceso de diseño se debería poder desacoplar las decisiones de diseño

relacionadas con la estructura de navegación, de aquellas relacionadas con el modelo

del dominio de la aplicación.

En el desarrollo de aplicaciones Web, la división por capas debe suceder de manera

natural, así el tiempo invertido en el diseño facilitara el trabajo necesario para el resto

de las actividades. (Fowler, 2002).

Patrones de diseño Web: Los patrones son de gran importancia en el mundo de

desarrollo de software, parte de su propósito es contar con una solución que ha sido

practicada en distintos contextos y ha probado ser exitosa, otro beneficio es

implementar un vocabulario que permita a los diseñadores comunicarse de manera

efectiva para dar una idea bastante clara de la arquitectura de la aplicación al hacer uso

de la terminología conocida (Fowler, 2002).

Uno de los cambios de mayor impacto en la construcción de aplicaciones empresariales

nace con el surgimiento de la programación Web. Esto se debe a que las interfaces de

usuarios de este tipo de aplicaciones tienen un paradigma distinto al de las aplicaciones

de escritorio. En consecuencia, algunos de los patrones ya existentes tuvieron que

adaptarse para dar solución a su problemática.


- 32 -

Por ejemplo, a nivel de la vista las aplicaciones Web se manejan naturalmente al

interpretar las peticiones, en cambio del lado del servidor se trabaja la respuesta,

parecía obvio aplicar un patrón ya existente llamado MVC (Fowler, 2002) junto con la

decisión de no agregar lógica a nivel de la presentación para generar una nueva versión

de este patrón ajustada al paradigma Web. El objetivo de usar MVC es asegurar que el

Modelo está completamente separado de la presentación Web, esto hace que sea más

fácil de modificar la presentación y añadir nuevas presentaciones más adelante.

Como vemos, esto es un hibrido entre la programación por capas y el patrón

MVC, dándole independencia a cada uno de los aspectos del diseño, además, el uso de

la OO permite el desacoplamiento con otras áreas de funcionalidad, por ejemplo, las

transacciones con la persistencia de los datos, convirtiéndose esta arquitectura en un

patrón de diseño casi obligatorio en la construcción de aplicaciones Web.

Además del MVC, existen otros patrones para el desarrollo de aplicaciones Web

que están enfocados en la presentación, como son, Page Controller, Front Controller,

Template View, Transform View, Two Step View, Application Controller. Apoyarse en un

patrón conocido facilita la definición de una arquitectura para la aplicación a construir y

garantiza en cierta medida una alta probabilidad de éxito (Fowler, 2002).

Antecedentes

En la literatura se encuentran diversos trabajos que intentan dar respuesta a

definición de métodos que ayuden en el desarrollo de aplicaciones con las

características objetivo, así como algunos otros que pueden ser adaptados para que

cumplan con estas características. Se presenta, a continuación, un resumen y un análisis

comparativo de algunos de ellos, este conjunto de métodos que fueron estudiados se

seleccionó tomando en cuenta el grado de madurez y la cantidad de documentación que

se encontró disponible para cada una de ellas, lo que permite tener información

suficiente para lleva a cabo el análisis y la comparación


- 33 -

1. WATCH

El método WATCH (Montilva C., Barrios A., & Rivero A., 2008), es parte del

Proyecto Methodius, el cual es una iniciativa para incentivar el desarrollo de software de

calidad en el país. WATCH es un marco metodológico que describe los procesos

técnicos, gerenciales y de soporte que deben emplear los equipos de trabajo que

tendrán a su cargo el desarrollo de aplicaciones de software empresarial. Está

fundamentado en las mejores prácticas de la Ingeniería de Software y la Gestión de

Proyectos como son CMMI, RUP y PMBOK.

El método WATCH está compuesto por tres modelos fundamentales:

1) Un modelo de productos que describe los productos intermedios y finales

que se generan, mediante el uso del método, durante el desarrollo de

una aplicación empresarial.

2) Un modelo de actores que identifica a los actores interesados

(stakeholders) en el desarrollo de una aplicación y describe cómo deben

estructurarse los equipos de desarrollo y cuáles deben ser los roles y

responsabilidades de sus integrantes.

3) Un modelo de procesos que describe detalladamente los procesos

técnicos, gerenciales y de soporte que los equipos de desarrollo deberán

emplear para elaborar las aplicaciones.

El método WATCH es un método gráfico, ya que está explicado a través del

modelado de sus procesos usando diagramas de UML 2 (OMG, 2007) y la extensión UML

Business de Eriksson y Penker (2000).

Del lenguaje UML 2, el método WATCH emplea los siguientes tipos de diagramas:


- 34 -

• Diagramas de clases

• Diagramas de casos de uso

• Diagramas de objetos.

• Diagramas de actividad.

De la extensión UML Business, el método usa los tipos de diagramas siguientes:

• Cadena de valor.

• Diagramas de jerarquía de procesos

• Diagramas del proceso

Además, el método propone el uso de estos lenguajes de modelado para ser

empleados durante el propio proceso de desarrollo de software, para modelar todo lo

relacionado con la aplicación empresarial que se desea construir. Este es el caso, por

ejemplo, del proceso de modelado del negocio que está fundamentado en BMM

(Montilva y Barrios, 2004), el cual se diferencia de otros métodos de modelado ya que,

como técnica de modelado, visualiza el dominio de la aplicación como un sistema.

Se pretende a través de este trabajo desarrollar una versión del WATCH que

cumpla los objetivos de la investigación establecidos en el Capítulo 1

2. OpenUP

Open Unified Process (OpenUP, 2008) es una versión libre del proceso unificado

(UP) que implementa el enfoque iterativo e incremental dentro de un ciclo de vida

estructurado. Está basado en casos de uso, gestión del riesgo, y está centrado en la

arquitectura.


- 35 -

OpenUP es parte del marco de trabajo para procesos de Eclipse EPF (Eclipse

Process Framework). Este marco de trabajo es de código abierto y se desarrolla dentro

del Eclipse Foundation (The Eclipse Foundation, 2010)

En OpenUP el proceso de desarrollo de software es de corte minimalista, lo que

significa que sólo se incluye el contenido fundamental, por lo tanto, no proporciona

orientación sobre muchos de los tópicos que un proyecto pudiera enfrentar como

equipos de gran tamaño, niveles de conformidad, situaciones contractuales, seguridad,

guía para la especificación de la tecnología, etc. (Balduino, R. , 2007)

Sin embargo, OpenUp es completo y extensible ya que el proceso tiene todo lo

necesario para construir un sistema y, cuando se presentan situaciones que no son

cubiertas es fácilmente extensible. Se puede usar como base sobre la cual es posible

agregar más contenido o adaptarse al proyecto según sea necesario

Este proceso está caracterizado como ágil. Las prácticas ágiles intentan conseguir

alto grado de comunicación entre los miembros del equipo para producir un

entendimiento compartido del proyecto, poniendo mayor peso en la importancia de la

coordinación y entendimiento, en beneficio de los interesados sobre los entregables

improductivos y la formalidad.

3. MeRinde

MeRinde (Marrero, 2007) es un proyecto de Software Libre desarrollado por el

CNTI (Centro Nacional de Tecnologías de Información) con el objetivo de proporcionar

una metodología que pudiese ser utilizada es los proyectos desarrollados por este

organismo para conseguir estandarización, trazabilidad y calidad en cada uno de estos

desarrollos. MeRinde propone un estándar para el proceso de desarrollo de software

que puede ser empleado y adaptado según los requerimientos de cualquier comunidad


- 36 -

u organización para el desarrollo de sistemas y además para producir y mantener una

librería de plantillas reutilizables para la Ingeniería de Software. Estas plantillas proveen

un punto partida para los documentos utilizados en proyectos de desarrollo de

software, con lo que pueden ayudar a los desarrolladores a trabajar más rápido y evitar

pasar por alto aspectos importantes del proceso de desarrollo.

El proceso de software propuesto por MeRinde se inspira en catorce (14)

mejores prácticas, dirigidas a facilitar el desarrollo colaborativo de software entre

equipos de trabajo de diversa magnitud e índole, con el fin de que se desarrolle

productos de software con alta calidad, aprovechando al máximo los recursos

disponibles de una forma eficaz y eficiente. A continuación, se listan las mejores

prácticas consideradas:

Adaptar el proceso de desarrollo

Alto nivel de abstracción

Centrarse en la arquitectura

Código estándar

Colaboración entre equipo

Demostrar resultados iterativamente e incrementalmente

Dirigido por Casos de Uso

Diseño simple

Enfoque continuo en la calidad

Enfoque en los riesgos

Fomento del aprendizaje de experiencias

Interacción continua con cliente

Modelar el software

Permanecer ágil y esperar los cambios.


- 37 -

4. Scrum

Scrum (Scrum Alliance, 2010) fue desarrollado en la década de los 80s y 90s, por

dos grandes colaboradores del Manifiesto Agil: Ken Schwaber y Jeff Sutherland. Ellos se

inspiraron en el trabajo de Takeuchi y Nonaka, (1986), quienes desarrollaron un proceso

que se despoja del tradicional enfoque secuencial y adopta una estrategia flexible,

holística, orientado al equipo. Una de las ideas más revolucionarias, presentada en este

enfoque, es el proveer estructura al equipo de desarrollo, pero no tanto para que

ahogue su creatividad.

Es un enfoque que enfatiza el “know how” que el desarrollador debe tener para

hacer su trabajo, Scrum reconoce que el proceso de desarrollo de software es una

suerte de proceso caótico, pues el éxito depende de la habilidad del equipo de

desarrollo para adaptarse y controlar este ambiente caótico, y le da la misma

importancia a la velocidad y flexibilidad como a la calidad y bajo costo.

El enfoque reduce el número de fases a solo cuatro -requerimientos, diseño,

prototipo y aceptación- sin eliminar ninguna de las actividades, lo que resulta en una

superposición de las fases en cascada.

Los equipos de Scrum gozan de un alto nivel de libertad, son equipos auto-

organizados y pequeños (entre 5 y 9 integrantes). Las entregas o despliegues son muy

frecuentes como máximo cada 30 días.

5. EssUP

Essential Unified Process (Jacobson, 2010) es una nueva práctica centrada en el

proceso de desarrollo de software cuyas bases descansan sobre prácticas de desarrollo

de software modernas y bien establecidas.


- 38 -

Ivar Jacobson, creador de EssUp, fue también el padre del proceso unificado

(Unified Process) y trabajó para Rational, empresa que elaboró la definición de RUP.

Inicialmente con la intención de crear un proceso para ayudar a desarrollar

software, RUP se convirtió rápidamente en un medio para vender Rational como única

solución de procesos y herramientas, convirtiéndose en un gigante con gran cantidad de

documentación que abrumaba al equipo de desarrollo. Este modelo, encajaba

perfectamente en corporaciones y entes gubernamentales que pretenden certificarse

en CMMI, brindándoles un proceso prescriptivo para construir software donde los

desarrolladores solo tienen que seguir las instrucciones.

EssUP es un esfuerzo para volver a lo esencial de las raíces de este proceso. Esta

vez con una presentación mucho más simple y que permiten las contribuciones de

otros. El método integra prácticas procedentes de los tres principales enfoques de

proceso: proceso unificado, los métodos ágiles y el proceso de madurez. Cada uno de

ellos aporta, a este método, distintas características: estructura, agilidad y mejora de

los procesos.

Las prácticas en EssUP son muy diferentes de otros enfoques o métodos en la

forma en que ellos se presentan. El proceso se basa de muchas maneras, sobre una

nueva idea, la separación de los asuntos o cometidos (SOC o Separation of Concerns).

Esto ayuda a identificar y abordar las situaciones específicas según su prioridad. Al

aplicar esta idea al proceso se simplifica y centra el enfoque, luego es mucho más fácil e

intuitivo seleccionar un proceso de desarrollo de software hecho a la medida, para

satisfacer necesidades específicas.


- 39 -

EssUp propone que se debe proporcionar la esencia de la información de alguna

manera a los integrantes del equipo, en vez de hacerlos leer toda la información del

proceso, esto les da la base para obtener más información cuando sea necesario

El proceso consta de seis prácticas técnicas y cuatro prácticas transversales:

Practicas técnicas esenciales:

Arquitectura: Captura las características esenciales de la arquitectura.

Iteración: Permite adoptar un enfoque iterativo para gestionar y

monitorear el proyecto.

Casos de Uso: Permite capturar los requisitos de una manera ágil.

Componentes: Permite desarrollar el software de forma sencilla,

escalable y guiada por pruebas.

Productos: Captura la esencia de la gestión de productos para acercarse a

los clientes.

Casos de Uso del Negocio: para identificar las necesidades del negocio y

entender la naturaleza del mismo.

Practicas transversales:

Proceso: Asegura la mejora continua del proceso y le ayuda a adoptar y

mejorar la nueva forma de trabajar.

Equipo: Permite al equipo colaborar más efectivamente.

Modelado: Es un enfoque ágil de modelado que le permite adoptar un

nivel de detalle apropiado, mejorar la comunicación del equipo y reducir

el riesgo del proyecto.

Ciclo de vida del proceso unificado: Es un conjunto de fases y etapas para

la planificación y seguimiento de los proyectos iterativos.


- 40 -

Cada práctica es definida por separado y manteniendo su independencia, por lo

que se consigue simplificar la descripción del proceso. Cada una de las prácticas se

puede desarrollar, adoptar y aplicar independientemente de las otras prácticas. Esta es

una gran diferencia con el Proceso Unificado, que se desarrolla con todas sus prácticas

fuertemente integradas.

6. XP

Durante el auge de los métodos agiles a finales de los 90s, Extreme Programming

(XP) fue una de las metodologías que captó más la atención, originada de la comunidad

Smalltak por la colaboración de Kent Beck y Ward Cunningham a finales de los 80s.

(Jeffries, 2010)

Según narra Baird (2002) en su libro, Beck trabajaba para el proyecto de la

Chrysler, Comprehensive Compensation System (C3), la idea principal de esta

metodología era tomar las mejores prácticas a niveles extremos, C3 requería determinar

la mejor manera de usar tecnologías orientadas a objetos utilizando el sistema de

nomina de Chrysler para el desarrollo de la investigación. El enfoque de desarrollo de

software se extendió a un enfoque adaptativo y orientado al equipo.

Beck invitó luego a Ron Jeffries a unirse al proyecto para ayudarlo a refinar los

métodos generados y lograr instituir las prácticas como hábitos en el equipo de C3. El

término Extreme Programming junto con sus principios y prácticas se difundió a través

de discusiones en el wiki original, permitiendo la contribución de un gran número de

personas.

Se podría decir que XP no fue algo que se inventó o se creó, si no que emergió de

una serie de colaboraciones, corrientes y sistemas. En consonancia con este punto de

vista, XP está basado sobre valores y principios guía. Es un método ágil para equipos de


- 41 -

tamaño pequeño a mediano que desarrollan software enfrentados al cambio continuo

de los requerimientos. Esta disciplina está basada en tres áreas esenciales;

comunicación, simplicidad, retroalimentación.

XP ha tenido gran aceptación, ya que hace hincapié en la satisfacción del cliente.

El método está diseñado con el objetivo de entregar el software que el cliente necesita

en el tiempo que es requerido. El método confía en que los desarrolladores puedan

responder a las cambiantes necesidades de los clientes en todas las etapas del ciclo de

vida. XP también hace hincapié en el trabajo en equipo, gerentes, clientes y

desarrolladores, son todos, parte de un equipo dedicado a entregar software de calidad.

7. Crystal Clear

Crystal es una familia de metodologías con características comunes compartidas.

Su fundador, Alistair Cockburn, es conocido por ser uno de los voceros de la comunidad

ágil. La familia Crystal es un conjunto de enfoques que se adaptan a diferentes tamaños

de equipo. Cockburn fundamentó su trabajo en la creencia que el tamaño del equipo es

un factor importante para seleccionar el tipo de metodología que debe ser utilizada.

(Cockburn, 2004).

En 1991, IBM le solicitó a Cockburn que escribiese una metodología para

proyectos en tecnología orientada a objetos. No conociendo mucho sobre desarrollar

metodologías, comenzó a entrevistar equipos de desarrollo y se dio cuenta que había

diferencia entre lo que los desarrolladores pensaban y lo que estaba escrito en los

libros. De inmediato, comenzó a tomar estas ideas como sugerencias para fundamentar

las características de su metodología. Cockburn escribió las lecciones aprendidas

durante las entrevistas, en especial aquellas que no son nombradas por la mayoría de

las metodologías documentadas en ese momento. Estos aspectos o lecciones


- 42 -

aprendidas resultaron ser aquellos puntos claves para lo que se considero el éxito de los

proyectos.

La idea era encontrar la menor cantidad de proceso que sea necesario hacer y

aún así tener éxito en el desarrollo del proyecto. Como resultado, esta metodología se

puede considerar que requiere menos disciplina, pero que reduce de las posibilidades

de fracaso. Crystal hace énfasis en la frecuencia de las entregas, alta comunicación, la

reflexión y mejora. Cada una de las metodologías pertenecientes a Crystal es

diferenciada por un color, Crystal Clear es la específica para equipos de 8 o menos

personas.

Análisis comparativo de métodos de desarrollo ágil

Con el fin de identificar los aspectos característicos de los métodos de desarrollo

con enfoque ágil, se realizó un análisis comparativo del conjunto de métodos existentes

anteriormente mencionados.

El análisis se desarrolló definiendo una serie de vistas a través de las cuales se

puede tener una síntesis de los aspectos importantes de un método. Las vistas

seleccionadas son: Vista Estructural o de Procesos, Vista del Dominio de la Aplicación,

Vista del Producto, Vista Organizacional, Vista Funcional o de Uso.

Cada una de las vistas establecidas se divide en facetas y estas a su vez en

atributos. A cada atributo de una faceta se le asigna un valor único durante la evaluación

de cada método.

Esta técnica de evaluación descrita está basada en la propuesta por Montilva,

Barrios, & Sandia (2002) para evaluar productos instruccionales.

A continuación, se explican cada una de las vistas y los atributos y valores

tomados en cuenta para la comparación:


- 43 -

Vista Estructural o de Procesos

La vista estructural está compuesta por aquellos atributos que describen como

está constituido el proceso de desarrollo de software de los métodos comparados. Ver

Tabla 2 - 2, Tabla 2 - 3 y Tabla 2 - 4.

Características del proceso

Nivel de detalle: El detalle o profundidad de la estructura del proceso

o (Bajo: Un nivel, Medio: 2 niveles, Alto: 3 niveles o más).

Aspectos que cubren: Los aspectos que son cubiertos por el proceso.

o (Técnicos: Análisis de Requerimientos, Especificación, Diseño y

Arquitectura, Programación, Documentación, Mantenimiento, Análisis

de Usuarios, Evaluación. Gestión: Gestión de proyecto, de iteración, de

riesgos, de cambios, calidad, planificación, seguimiento y control.

Soporte: Gestión de configuración, Gestión de Cambios, Pruebas, QA)

Claridad: Claridad del proceso. Artefactos bien definidos, Identifica artefactos

opcionales/necesarios, Estructura bien definida.

Grado de disciplina: El tipo de disciplina que impone el método.

o Disciplinado (es más predecible, menos cambiante), liviano o poco

disciplinado, ágil o adaptativo (se adapta fácilmente a los cambios).

Estándares que usa: De los estándares conocidos en desarrollo de software con

cuales cumple, se basa o se adapta

o IEEE, CMM, CMMI, ISO, etc.

Retroalimentación: Frecuencia de las entregas, reflexión y mejora.

Adaptabilidad: La manera en la cual el método puede ser ajustado según las

necesidades del proyecto o los cambios del mismo durante su ejecución.

Enfoque: En cuál de los enfoques conocidos para abordar proyectos de software,

se fundamenta el método.


- 44 -

OpenUp

EssUp

Xp Crystal

Clear

Scrum

Merinde

Faceta Atributo ValorBajo (1-3) ? ? ? ?

Medio (4-6) ? ?

Alto (>7))

Técnicos

Análisis de RequerimientosEspecificación, Diseño y arquitectura, Programación, Documentación.

Análisis de RequerimientosEspecificación, Diseño y arquitectura, Programación, Documentación, Mantenimiento, Analisis de Usuarios,

Programación, evaluación

Arquitectura, Programación, Documentación, Pruebas unitarias

Programación, evaluación

Análisis de Requerimientos, Especificación, Diseño y arquitectura, Programación, Documentación, Mantenimiento, Analisis de Usuarios, evaluación

GestiónGestión de: proyecto, de iteración, de riesgos, de requerimientos

Gestión de: proyecto, de iteración, de riesgos

Gestión de: proyecto, de iteración

Gestion de: proyecto, de iteracion, de riesgos, planificación, seguimiento y control

Gestión de: proyecto, de iteración, planificación, seguimiento y control

Gestión de: proyecto, de iteración, de riesgos, de cambios, calidad, planificación, seguimiento y control

Soporte Pruebas Pruebas Pruebas Pruebas PruebasGestión de configuración, Pruebas, QA

Artefactos bien definidos

? Opcional ? Sí, pero pocos ?

Identifica artefactos opcionales/necesarios

? ? ? ?

Estructura bien definida ? ? ? ?

Grado de discipl ina

Disciplinado/Liviano/Agil

Agil, liviano Adaptable ??, se adapta según el tamaño del proyecto y equipo

Liviano, Agil Disciplinado

Características del proceso

Nivel de detal le

Aspectos que cubren

Claridad

Tabla 2 - 2 Vista Estructural o de Procesos (Parte 1)


- 45 -

OpenUp

EssUp

Xp Crystal

Clear

Scrum

Merinde

Faceta Atributo ValorIEEE √ √ √

CMM √ √Medianamente, pero pierde algunas de sus propiedades clave

Nivel 2 y 3 √

CMMI √ √ √

ISO √ √ √

Frecuencia de las entregas

Muy frecuente Frecuentes Muy Frecuentes Muy FrecuenteRecomendable entre 2 y 4 semanas

Frecuente, entre 2 y 6 semanas

Reflexión y mejora √ √ √ √ √ Continuo en cada iteración

Extensible √Alta, mediante la definición de nuevas practicas

Si, Orientado a propiedades

No √

Ajustable según la evolución del proyecto

√ Opcional, Usando Procces Essentials

Si, se pueden añadir practicas según evolucione el proyecto

√

Ingeniería (secuencial)

Evolutivo

Formal

Iterativo / Incremental √ √ √ √ √ √

Componente √ √ √

Libre √ √

Reutil ización √ √ √

Prototipos √ √ √ √ √

Cascada

V

Incremental √ √ √

Ágil √ √ √ √

Otros (especificar)UP, RUP, XP, MSF yOpenUP

Ágil √ √ √ √ √

Caracterisiticas del Proceso

Estándares que soporta

Retroalimentación

Adaptabi lidad

Enfoque



- 46 -

OpenUp

EssUp

Xp CrystalClear

Scrum

Merinde

Blue WATCH

Faceta Atributo ValorModelo de Proceso √ √ √ √ √

Modelo de Producto √ √ √ √ √ √

Modelo de Recursos Opcional √

Modelo de Actores √ √ √ √ √ √

Cohesión Alta separación de las practicas

√ √ No No √ √

Descripción del Modelo

Estructura



- 47 -

Descripción del Modelo

Estructura: Se refiere a los componentes de la estructura del método.

o Modelo de Proceso, Modelo de Producto, Modelo de Recursos, Modelo

de Actores

Cohesión: El grado de separación o dependencia que existe entre las practicas

descritas por el método.

Vista del Dominio de Aplicación

Está relacionada con el dominio de aplicación de los métodos que están siendo

comparados. La vista del dominio está descrita en una faceta: Aplicabilidad, la cual

contempla los atributos relacionados con el área de aplicación del método. El detalle se

puede ver en la Tabla 2 - 5.

Aplicabilidad

Alcance del método: Indica si el método puede ser utilizado para proyectos con

características específicas o áreas de desarrollo específicas o si es un método de

alcance general.

Áreas de aplicación: Software del Sistema que es el software de más bajo nivel

requerido para manejar los recursos del computador y la ejecución de otros

programas. Software de programación: se refiere al resto de las aplicaciones que

no son las del sistema. Software de Aplicación: Es el que ejecuta acciones

específicas directamente para el usuario final.

Sub Áreas del Software de Aplicación (Científico, Médico,

Entretenimiento/Videojuegos, Educativo, Embebidos, Industrial (Control de

procesos), CAD/CAM, Utilitarios, Empresarial SI, Empresarial SI/BD, Empresarial

Web.


- 48 -

OpenUp

EssUp

Xp Crystal

Clear

Scrum

Merinde

Faceta Atributo ValorGeneral √ √ √

EspecificoSistemaProgramación √ √ √ √

Aplicación √ √ √ √ √ √

CientíficoMédicoEntretenimiento/VideojuegosEducativo √ √ √ √

Embebidos √ √ √ √ √ √

Industrial (Control de procesos)

√ √ √

CAD/CAM √ √ √

Utilitarios √ √ √ √

Empresarial SI √ √ √ √ √ √

Empresarial SI/BD √ √ √ √ √ √

Empresarial Web √ √ √ √ √ √

Aplicabilidad

Alcance del método

Áreas de aplicación

Sub Áreas del Software de Aplicación

Tabla 2 - 5 Vista del Dominio de Aplicación


- 49 -

OpenUp

EssUp

Xp Crystal

Clear

Scrum

Merinde

Faceta Atributo ValorFormal

(Formulas matemáticas)

Semiformal (gráficos, imágenes)

√ √ √ √

Informal (textual) √ √ √

Objetos √ Recomendado √ Basado en ejemplos √OO y Procesos

Usa UML

Datos

Aspectos

Componentes Recomendado √ √

Servicios √

Procesos de Negocio √

Reutil ización √ √ √

Modular √ √

Agentes √

Independiente de la orientación

√ √ √

Productos Técnicos 5 - 10 15 -20 1 - 5 10 - 15 1 - 5 25 - 30

Productos Gestión 5 - 10 1 - 5 1 - 5 10 - 15 1 - 5 15 -20

Productos Soporte 1 - 5 1 - 5 1 - 5 1 - 5 1 - 5 5 - 10

Descripción del Producto

Notación del Modelo

Orientación del Método

Artefactos producidos

Tipo

Tabla 2 - 6 Vista del Producto


- 50 -

Vista del Producto

La vista del producto describe lo que cada método genera y las características de

lo producido. Ver Tabla 2 - 6

Descripción del Producto

Notación del Modelo: La manera como está documentado o representado el

método.

o Formal (Formulas matemáticas), Semiformal (gráficos, imágenes),

Informal (textual)

Orientación del Método: De los distintos enfoques y paradigmas de desarrollo de

software.

o Objetos, Datos, Aspectos, Componentes, Servicios, Procesos de Negocio,

Reutilización, Modular, Agentes, Independiente de la orientación

Artefactos del Producto

Tipo: Cantidad de artefactos producidos por cada uno de los tipos de productos:

Productos Técnicos, Productos Gestión, Productos Soporte.

Vista Organizacional

La vista organizacional describe los aspectos relativos al tipo organización a la

que está dirigido cada método. Ver Tabla 2 - 7

Roles

Roles Técnicos: Detalla los roles técnicos definidos por el método.

Roles de Gestión: Detalla los roles de gestión definidos por el método.

Roles de Soporte: Detalla los roles de soporte definidos por el método.


- 51 -

Características del grupo de desarrollo

Tamaño del grupo: Se refiere a la cantidad de personas que participan en el

equipo de desarrollo

Distribución del grupo: La manera en cómo se pueden distribuir geográficamente

los participantes del proyecto

Estructura: Estructura organizativa del equipo de desarrollo:

o Jerárquica, Democrática, Definida por el grupo, Ninguna, otra.

Vista Funcional o de Uso

En esta vista se describe el aspecto funcional de cada método evaluado. Las

facetas que se describen son la de uso, documentación, participación del usuario y

aplicabilidad en el desarrollo de la aplicación. Ver Tabla 2 - 8 y Tabla 2 - 9.

Uso

Facilidad: Facilidad para el uso de la metodología.

o Baja, Media, Alta.

Visibilidad: Visibilidad de la información y las decisiones a través del equipo.

o Muestra que hay que hacer

Documentación

Grado: Medida en que está documentado el método, se refiere a la cantidad y

detalle de la documentación.

o Baja, Media, Alta.

Medio: Vía por la cual se realiza la documentación o publicación de la misma.

o Pagina Web, Herramientas especializadas, Documentos digitales, Libre


- 52 -

OpenUp

EssUp

Xp Crystal

Clear

Scrum

Merinde

Faceta Atributo ValorArquitecto de SW Bien definido Definido Bien definido Bien definido

Probador (Testing) Bien definido Definido Bien definido Bien definido Bien definido

Anal ista de SW Bien definido Definido Definido Definido Definido sin detalle

Diseñador de SW Definido Bien definido Definido sin detalle

Diseñador Grafico Definido sin detalle

Desarrollador Bien definido Definido Bien definido Bien definido Bien definido

Gerente de Proyecto Bien definido DefinidoThe Owner y

ScrumMaster

Líder Técnico Definido Definido Bien definido

Cal idad (SQA) No definido Bien definido

Configuración (SCM) No definido Definido sin detalle

Pequeño (1-3) √

Mediano (4-6) √ √ √

Grande (6-10) √ √ √

Indefinido √

Central izado √ √ √ √ √ √

Distribuido √

Sí, pero pierde la propiedad de

comunicación por osmosis

√ √

Jerárquica √ √ no estricta

Democrática √ √

Definida por el grupo

√ √

Ninguna Se define al principio del proyecto

√

Características del grupo de

desarrollo

Tamaño del grupo

Distribución del grupo

Estructura

Roles

Roles Técnicos

Todos los roles tecnicos son auto gestionados, auto

organizados, y transversales

Roles de Gestión Bien definido

Roles de Soporte

Tabla 2 - 7 Vista Organizacional


- 53 -

OpenUp

EssUp

Xp Crystal

Clear

Scrum

Merinde

Faceta Atributo ValorBaja √

Mediana √ √ √ √

Alta √

Visibilidad Muestra que hay que hacer √ √Defini do a l

princi pio del proy. puede variar

√

Baja √ √

Mediana √ √ √ √

Alta √ √

Pagina Web

Herramientas especializadas

Documentos digitales √ √ √

Libre √ √ √

Desarrolladores de Software Pa rti cipaci ón Alta Partici pación Al ta Parti cipaci ón Alta Pa rti cipaci ón Alta Parti ci pación Alta Partici pación Al ta

Diseñadores de páginas Web Particiapción BajaSe define a l pri ncipio

de l proyectoParticia pción Baja Particiapci ón Baja Parti ciapci ón Baja

Promotor Pa rti ciapci ón AltaSe recomienda como

altaParti cipaci ón Alta Particia pción Baja Particiapci ón Baja Partici apción Al ta

Usuarios expertos Particiapción BajaSe define a l pri ncipio

de l proyectoParti cipaci ón Alta Pa rti cipaci ón Alta

Partici apción Medi a

Particia pción Media

Arquitecto de SW Pa rti ciapci ón AltaSe recomienda como

altaPartici apción

Medi aParticiapci ón Baja Partici apción Al ta

Uso

Facilidad

Documentación

Grado

Medio

Participación del usuario

Tipo de usuario

Tabla 2 - 8 Vista Funcional o de Uso (Parte 1)


- 54 -

OpenUp

EssUp

Xp Crystal

Clear

Scrum

Merinde

Faceta Atributo Valor

Anál isis √Recomendado.

Defini do a través de la s pra cti cas

A al to nive l, s e va refi na ndo dura nte

el proceso

Rapi do, Explora tory 360°

A a lto ni ve l, s e va refi na ndo durante

el proces o

Profundo pa ra definir la arqui tectura y mitiga r ri es gos

Diseño √Recomendado.

Defini do a través de la s pra cti cas

Dentro de cada i tera ción

Se des a rrol la un di s eño rá pi do a muy al to nivel

Dentro de cada i tera ción

A a lto nive l

Desarrollo √ √ I tera ciones muy cortas

√ En iteraci ones cortas

Por i tera ci ones

EvaluaciónRepeti da s veces

dentro de una mi s ma i tera ción

√ Dentro de cada i tera ción

√ Dentro de cada i tera ción

Dentro de cada Iteración y val i dación al fi na l de la mis ma

MantenimientoOpcional . Definido

a través de l as practi cas

Se ha ce durante todo el proces o

Se hace durante todo el proces o

Se hace dura nte todo e l proces o

√

Académico √ √

Comercial √ √ √ √ √ √

PublicitarioServicios √ √ √ √ √ √

Uso de técnicas estándares

No está l imitadoOpci onal , s e

defi ne al pri nci pi o del proyecto

√ Refactori ng, Reingeni eria

√

Uso de notaciones estándares

No está l imitadoRecomi enda e l us o

de UML√

No es ta l i mi ta do s e defi ne a l

princi pio del proy.√

Aplicabilidad

Ciclo de Vida

Orientación

Estandarización

Tabla 2 - 9 Vista Funcional o de Uso (Parte 2)


- 55 -

Participación del usuario

Tipo de Usuario: tipos de usuario que se espera que participen y su grado de

participación. (Desarrolladores de Software, Diseñadores de páginas Web,

Promotor, Usuarios expertos, Arquitecto de SW).

Aplicabilidad

Ciclo de Vida (Análisis, Diseño, Desarrollo, Evaluación, Mantenimiento)

Orientación (Académico, Comercial, Publicitario, Servicios)

Estandarización (Uso de técnicas estándares, Uso de notaciones estándares)

Equivalencia de términos

En la Tabla 2 - 10 se puede observar una lista de los términos más comunes

utilizados durante el proceso de desarrollo de software y su equivalente en cada una de

las metodologías estudiadas.

OpenUp

EssUp

Xp Crystal

Clear

Scrum

Merinde

ValorObjetivo Visión Objetivo

Actividad Tarea Actividad Actividad Actividad

Tarea Pasos Tarea Tarea

Actor Actor Miembro de Equipo

Actor

Rol Rol Competencia Rol Rol Rol Rol

Responsabilidad Responsbilidad Responsbilidad Responsbilidad

Restricción Restriccion Valores

Requisito Requisito Requisito User Stories Requisito Requerimiento

Iteración Iteración Iteración Iteración Iteración Sprint Iteración

Objeto Objeto

ProductoProducto de

Trabajo Prducto Entregable Work Products Producto Artefacto

Incremento Incremento Build Incremento

Versión Versión Release Release Entrega Hito

Plan de Proyecto Plan de Proyecto Backlog Backlog Plan de Proyecto

Modelo Modelo Modelo Metafora Modelo Tabla 2 - 10 Equivalencia de términos


- 56 -

Agilidad y calidad

Uno de los aspectos más importantes y deseables buscados durante la

construcción de una aplicación de software es la calidad tanto del producto como del

proceso que se lleva a cabo para construirlo. La calidad es un concepto bastante

abstracto que es difícil de definir y puede ser vista desde distintas perspectivas. Para

algunos la calidad es conformidad con los requisitos y falta de defectos en el producto

(Juran & Gryna, 1988), para otros autores se alcanza la calidad cuando lo desarrollado

aporta valor para alguien (Weinberg, 1991).

La calidad vista desde el enfoque de los métodos disciplinados involucra una

cantidad de procesos que comprenden gran cantidad de actividades y la necesidad de

numerosos recursos para ejecutarlas. En una definición formal de gestión de calidad, las

actividades de aseguramiento de la calidad deben asegurar el cumplimiento de una lista

de parámetros o características con que debe contar la aplicación.

Se listan a continuación una descripción abreviada de estas características

proporcionadas por Meyer (2000):

Correctitud: La capacidad del sistema de funcionar acorde a las especificaciones

definidas.

Robustez: El funcionamiento adecuado del sistema frente a condiciones

extremas, esto complementa la correctitud.

Extensibilidad: Un sistema que permita la adaptación sencilla de nuevas

especificaciones.

Reusabilidad: El Software que está compuesto por elementos que pueden ser

usados para construir diferentes aplicaciones.

Compatibilidad: El Software que está compuesto por elementos que pueden

fácilmente ser combinados con otros elementos


- 57 -

Eficiencia: La habilidad del sistema de solicitar la mínima cantidad de recursos

del computador como son, memoria, ancho de banda, y tiempo de

procesamiento.

Portabilidad: La capacidad de la aplicación de poder ser instalada y funcionar

correctamente sobre distintas plataformas de hardware y software.

Timeliness: La entrega del software antes o exactamente cuándo es necesitado

por el usuario.

Integridad: Que tan bien el software protege sus programas y datos de los

accesos no autorizados.

Verificabilidad: La capacidad del software de permitir ser probado de manera

sencilla.

Facilidad de Uso: La facilidad con que personas con distintos niveles de

conocimiento pueden aprender y utilizar el software.

Desde una perspectiva ágil, la calidad ha sido definida por algunos expertos de la

siguiente manera:

McBreen (2003) define el aseguramiento de la calidad ágil como: “La capacidad

de respuesta al cambio durante el desarrollo de software, como respuesta a las

necesidades del cliente. Esto implica que la entrega frecuente de un software

probado, funcional, y aprobado por el cliente al final de cada iteración es un

aspecto importante del aseguramiento de la calidad desde el punto de vista ágil.”

Ambler (2005) considera la calidad ágil como: “El resultado de prácticas tales

como el trabajo colaborativo eficaz, el desarrollo incremental y desarrollo

iterativo, implementando técnicas como la refactorización, desarrollo basado en

pruebas, modelado y técnicas eficaces de comunicación.”

Se muestra, a continuación, los parámetros de calidad descritos y como ellos son

alcanzados desde el punto de vista ágil:


- 58 -

Correctitud: Se codifica para la menor cantidad de requisitos. El detalle de la

especificación es obtenido por comunicación directa con el cliente. El cliente

puede cambiar las especificaciones sin restricciones. Se usa desarrollo guiado por

pruebas.

Robustez: No directamente manejado desde el punto de vista ágil.

Extensibilidad: Una característica de la mayoría de las aplicaciones OO. Énfasis

en la excelencia técnica y alcanzar un buen diseño así como estar basado en la

mejor arquitectura.

Reusabilidad: Una característica general de la aplicaciones OO.

Compatibilidad: Una característica general de la aplicaciones OO.

Eficiencia: Implementar estándares y buenas prácticas de programación.

Portabilidad: No directamente manejado desde el punto de vista ágil.

Timeliness: Practicar la continua integración y despliegue de la aplicación.

Integridad: No directamente manejado desde el punto de vista ágil.

Verificabilidad: Es una característica general de la aplicaciones OO. Se realiza

programación orientada por pruebas.

Facilidad de Uso: Dado que el cliente está involucrado con el desarrollo de la

aplicación y aporta su punto de vista de manera frecuente es altamente

probable que ellos soliciten un sistema comprensible y fácil de usar.

Como conclusión, se puede observar que la calidad si se toma en cuenta desde la

perspectiva ágil, pero la misma es enfocada de una manera distinta a la tradicional,

haciendo uso de técnicas que permiten alcanzar estos parámetros de la calidad, como

por ejemplo, la programación entre pares, programación orientada a pruebas, la

verificación temprana, entre otras.


- 59 -

Agilidad versus Disciplina

Para resumir la comparación de estos dos enfoques se muestra en la Tabla 2 -

11 los distintos enfoques que tiene cada tendencia para afrontar el proceso de

desarrollo.

Ágil Tradicional Iterativo Busca refinar la solución a medida que se

desarrolla el proyecto de software Pretende plantear la solución completa al comienzo del proyecto

Incremental Busca simplificar el sistema en pequeños subsistemas con funcionalidades relacionadas (cada incremento es completamente funcional)

Los resultados tardan mucho en mostrarse.

Organización Auto-organizados Jerarquías claras

Evolución y flexibilidad

El proceso es un ciclo de aprendizaje para el equipo de desarrollo. Las reglas y procesos se ajustan a las necesidades del proyecto sin que esto implique que se están rompiendo

Las reglas y el proceso están claramente definidos desde el comienzo

Filosofía Inovativo, participativo. Orientado a la vida

Autoritario, Orientado al trabajo

Movilidad y eficiencia

Busca desprenderse de todas las actividades burocráticas que puedan ralentizar el proceso. Se hace solo el trabajo necesario para conseguir el producto final

Sigue el proceso como está definido y no avanza hasta terminar las etapas establecidas

Planificación y manejo del

cambio

Se ataca lo prioritario para el momento por lo que da cabida a cambios en los requisitos

Se planifican en detalle las actividades lo que implica que cambios en los requisitos del cliente afectan el proceso

Comunicación Informal. Formal

Documentación Se enfoca en que el producto final sea funcional sin darle prioridad a la documentación

Los niveles de documentación son lo más detallado posible

Manejo del riesgo

No se atacan los requisitos impredecibles hasta que no se tenga certeza de ellos

Se realiza una abstracción especulativa del problema para definir una solución

Gestión de requisitos

Los requisitos se van detallando de manera gradual, durante el proceso. El cliente y los desarrolladores evolucionan en la compresión de la solución. El proceso permite esta evolución de manera natural

Los requisitos son formulados en las etapas tempranas del proyecto. El costo de permitir cambios en los requisitos aumenta a medida evoluciona el proyecto.

Orientación del Proceso

El proceso se establece en términos de las actividades diarias del equipo

El proceso se formula en término de las etapas del proyecto en el cual cada miembro del equipo tiene un rol definido.


- 60 -

Participación del

cliente

Los clientes se encuentran a disposición para aclaratoria de dudas y validaciones a lo largo de todo el proceso de desarrollo.

El principal contacto con el cliente ocurre en la primera etapa del proceso de desarrollo y al final del proceso para la validación ya aprobación. Los acuerdos se manejan de manera formal

Gestión de Calidad del producto

Todos los miembros del equipo en colaboración son responsables. Durante todo el proceso la calidad es una de las principales preocupaciones. Las actividades de calidad están embebidas dentro de otros procesos

El equipo de QA es el responsable, se ejecuta principalmente durante la fase de pruebas o aseguramiento de la calidad. Las actividades se realizan de manera separada y formalizada

Gestión del conocimiento

Tácita, informal y escrita, es imperativo compartir la información con todo el equipo

Tácita, formal y escrita, es deseable compartir la información con todo el equipo

Tabla 2 - 11 Agilidad Versus Disciplina

Identificación de los requisitos del método

A partir de la información recolectada en el análisis comparativo de las

metodologías existentes, y de los distintos artículos recolectados relacionados con el

tema, en especial el informe de la empresa venezolana de software en Venezuela

(Methodius, 2008), se identificó un conjunto de necesidades que debe satisfacer

cualquier método orientado a las empresas venezolanas de desarrollo de software de

aplicaciones Web.

De esta lista de necesidades se desprende el conjunto de requisitos del método,

tomando en cuenta que está orientado específicamente a empresas venezolanas micros

y pequeñas (entre 3 y 10 empleados) y para desarrollo Web, lo que comprende los

principales requerimientos de nuestra propuesta.

Los requerimientos que se derivan del análisis realizado son:

La metodología debe ser accesible para las PYMES. Según el estudio de

Methodius (2008), más de 20% de las empresas de desarrollo de software en el

país entran en la categoría de microempresa (1-5 trabajadores), y

aproximadamente 30% en la categoría de pequeñas (6-10 trabajadores). Esto

representa el 50% de las empresas de la región. Notamos también, que la


- 61 -

mayoría de los métodos analizados están orientadas a equipos medianos a

grandes (de 4 personas en adelante). Esto deja por fuera los equipos muy

pequeños que deben poder adaptar las metodologías para poder utilizarla. El

método a desarrollar debe estar orientado a ajustarse a las características de la

categoría de microempresa.

El número de personas asignadas a proyectos de software para empresas micro

y pequeñas raramente supera las 5 personas (Montilva, Barrios, & Rivero, 2009),

el método debe estar ajustado a esta realidad.

El desarrollo de aplicaciones Web a la medida y las aplicaciones bajo plataforma

cliente/servidor comprenden casi el 50% del total de servicios prestados en la

región, siendo la primera la más frecuente, además, un 40% de las empresas

utilizan principalmente lenguajes de programación que permiten el desarrollo de

aplicaciones y servicios Web. El método a definir debe dar respuesta a esta

necesidad detectada en la realidad nacional.

Por falta de presupuesto, de recursos o de capacidad de planta, las empresas

venezolanas en el renglón de micro y pequeñas empresas se ven obligadas a

asignar responsabilidades correspondientes a roles distintos a un mismo recurso

(Montilva, Barrios, & Rivero, 2009), el método debe ser flexible para permitir

varios roles definidos puedan ser ejecutados por un mismo recurso, y especificar

cuáles de estos roles no deben ser ejecutados por el mismo recurso para evitar

malas prácticas.

Los Casos de Uso son utilizados por las microempresas venezolanas tanto para la

identificación y elicitación de los requisitos, como para la validación de los

requisitos identificados (Montilva, Barrios, & Rivero, 2009), por lo que se hace

natural orientar la metodología al uso de esta representación.

Más de un 40% de las empresas no realiza control de versiones de los

documentos (Montilva, Barrios, & Rivero, 2009), el método debe definir como

regla el control de las versiones en la documentación.


- 62 -

Casi un 30% de las empresas no realiza control de calidad (Montilva, Barrios, &

Rivero, 2009), también se detectó que entre los métodos estudiadas en general

este aspecto no tiene un peso importante dentro del proceso y los roles

definidos. El método debe contar con procesos para realizar el aseguramiento de

la calidad del producto generado, así como la definición de los roles relacionados

y la participación del usuario necesaria.

Alrededor del 25% de las empresas no realiza seguimiento y control del proyecto

(Montilva, Barrios, & Rivero, 2009), el método debe contar con procesos para

asegurar se lleve a cabo esta práctica que es la que permite que el producto final

no se aleje de lo solicitado por el cliente o no tome en cuenta cambios en los

requerimientos recogidos.

Más del 70% de las empresas no utiliza las técnicas de validación y pruebas,

pruebas unitarias, de integración, caja negra o caja blanca. De igual manera, se

identifica que es sobre el cliente que recae la ejecución final de las pruebas

(Montilva, Barrios, & Rivero, 2009), el método debe dejar claro a través de

directrices que se deben llevar a cabo alguna de estas técnicas.

Por estar orientada a equipos pequeños, el método no debe ser estrictamente

disciplinado. Se debe encontrar en un punto óptimo entre agilidad y disciplina,

que permita a los equipos pequeños implementar un proceso, si bien

estructurado, organizado y bien definido, también flexible y ágil, que no ahogue

a los pocos recursos en pesadas actividades de documentación, ni la burocracia

de los procesos muy disciplinados.

Permitir a la microempresa implementar un método que les proporciones una

manera de ser reconocidos como productores de software de calidad sin el alto

gasto inicial de implementación y mantenimiento de los estándares existentes.

La estructura de la metodología deben estar alineado de ser posible con las

buenas prácticas disponibles procesos Ingeniería de Software reconocidos (ej.

PMBOK, CMMI, ISO, IEEE), para darle la posibilidad a la microempresa de


- 63 -

conseguir una futura certificación cuando consiga crecer e implementar

procedimientos más disciplinados.

Algunos de los métodos analizados (en especial las ágiles) no permiten equipos

distribuidos, lo que representa un obstáculo para una creciente forma de trabajo

que se presenta actualmente a nivel mundial y nacional como es el off-shoring,

la metodología a definir debe tomar en cuenta este factor y permitir realizar el

trabajo aun cuando el equipo no se encuentre localizado en el mismo lugar.

El método debe proporcionar guías que sean fáciles de entender, accesibles y

utilizables por las microempresas: Según el análisis comparativo realizado, los

métodos en estudio muestran tener una mediana facilidad de uso a excepción

de XP, que tiene una alta facilidad de uso y MeRinde que tiene baja facilidad de

uso. Si relacionamos esto con otro atributo como es el grado de documentación

notamos que la mayoría tienen un mediano uso de la documentación a

excepción de XP, que tiene bajo uso de documentación y MeRinde que tiene alto

grado de documentación. Otro factor importante es que solo MeRinde

proporciona formatos o guías claras de lo que debe contener la documentación.

De este análisis se desprende que el método a definir debe promover el uso de

la documentación para que el equipo de desarrollo sienta que esta es una parte

importante del producto a entregar. Así mismo, debe proporcionar

documentación que requiera mínimo esfuerzo de adaptación.

En el análisis de los métodos estudiados se encontró que no todos están

orientadas a la reutilización (en especial, las de enfoque ágil). Esto es un punto

negativo, ya que en muchas ocasiones significa re-trabajo, mayor posibilidad de

fallos, y una baja facilidad de mantenimiento para el sistema desarrollado. El

método a definir debe hacer énfasis en este factor, así como, en las fases de

análisis y diseño que permita identificar aspectos reusables y realizar un mejor

modelado del negocio.

El método debe garantizar que existe una comunicación efectiva con el cliente,

debe encontrar un punto intermedio en los niveles de retroalimentación a saber,


- 64 -

frecuencia en las entregas y reflexión y mejora. La mayoría de los métodos

estudiados hacen énfasis en este punto, que se considera factor crítico para que

un enfoque ágil y orientado a equipos pequeños sea exitoso.

Debido a las deficiencias mencionadas de las organizaciones venezolanas en

cuanto al control de calidad, seguimiento y control del proyecto, control de

versiones, validación y pruebas el método debe ser de fácil uso e instanciación,

para ello es necesario:

o Identificar de manera clara dentro del cuerpo de productos del método

los artefactos esenciales, los deseables y los opcionales.

o Generar plantillas guía para los artefactos esenciales.

o Definir y documentar los procesos y productos.

o Modelar los flujos de trabajo del método.

Resumen

Este capítulo permite tener un contexto de los conceptos básicos, relacionados

con el tema que será abordado en el trabajo de investigación. Como se puede observar

existen diversos aspectos que son importantes y deben ser tomados en cuenta para que

la construcción del método realmente de una respuesta adecuada al problema

planteado. Adicionalmente, se expone el análisis tomando como punto de partida los

conceptos explicados con el objetivo de identificar las características deseables del

método a desarrollar y por lo tanto establecer los requerimientos del método, en

específico los requisitos que permiten satisfacer las necesidades del entorno nacional

como son las PYME venezolanas que realizan desarrollo de software.


- 65 -

CAPITULO 3

EL MÉTODO BLUE WATCH

Este capítulo busca establecer los pilares sobre los que está fundamentada la

construcción del método.

El objetivo es identificar la estructura y los componentes del método para contar

con una representación abstracta del domino de objetos y relaciones sobre la que se

desarrolla el método BLUE WATCH. Se definen, a través del meta-modelo, los términos y

las relaciones básicas que abarcan el vocabulario, los objetos del dominio y las

relaciones existentes entre ellos.

Meta modelo del Blue WATCH

El método WATCH (Montilva C., Barrios A., & Rivero A., 2008) establece tres

modelos sobre los que se fundamenta la estructura del método. Blue WATCH hereda su

fundamentación de esta estructura y adapta ya sea por extensión, modificación o

simplificación cada uno de los modelos planteados. La Figura 3 - 1 muestra los modelos

sobre los cuales como está estructurado el método y sobre los que se definen todos los

aspectos necesarios en el ciclo del desarrollo: Modelo de Actores, Modelo de Productos

y Modelo de Procesos.

Modelo de Productos: Componente del método WATCH que describe, en

términos generales, los diferentes productos intermedios y finales que deben

producirse durante el desarrollo de una aplicación empresarial.


- 66 -

Modelo de Actores: Componente del método WATCH cuya función es describir

los aspectos organizativos de los equipos de trabajo que desarrollarán la aplicación

empresarial.

Modelo de Procesos: Componente del método WATCH que describe los

procesos gerenciales, técnicos y de soporte que deben seguir los equipos de desarrollo

para elaborar una aplicación empresarial.

class Componentes del Método

Método WATCH

Modelo de Productos Modelo de Actores Modelo de Procesos

Figura 3 - 1 Meta Modelo del método Blue WATCH

La implementación de estos modelos se muestra en detalle en los capítulos

siguientes, donde se explica la definición de los modelos para Blue WATCH.

1. El Modelo de Actores

Describe los actores que intervienen durante el proceso del desarrollo así como

la manera en que ellos se relacionan con el proceso de desarrollo y los roles y

responsabilidades de cada uno (Figura 3 - 2).

Actor: Rol o función que ejerce una persona (o sistema) que interactúa con una

aplicación empresarial ó participa, en modo alguno, en su desarrollo. Un actor está

vinculado de alguna manera al desarrollo del Sistema de Información Empresarial


- 67 -

(aplicación empresarial); bien porque participa directamente en su desarrollo o porque

tiene la necesidad de utilizar este sistema.

class Metamodelo de Actores

«actor»Actor

«actor»Rol

«actor»Responsabilidad

«actor,rol»Cliente-Promotor

«actor,rol»Desarrollador

«actor,rol»Usuario

+ejerce

1..*

+ejercido_por

0..*

+tiene_asignado

1..*

Figura 3 - 2 Meta Modelo de Actores del Blue WATCH

Rol: Cargo o función que es ejercido por un actor en el marco del proyecto de

desarrollo de aplicaciones de una aplicación empresarial.

Responsabilidad: Tarea que debe ser ejecutada por el actor que ejerce un rol

determinado.

Cliente-Promotor: Se refiere a la persona que adquiere o está habilitado para

adquirir el producto del proyecto. El generalmente es un usuario del proyecto. Este

actor se encarga de proporciona los recursos financieros para el proyecto, ya sea por

que tenga las facultades dentro de la organización para tomar estas decisiones o porque

lo gestione con la unidad, departamento o persona de la organización que si tiene las

competencias necesarias. A efectos del Modelo, ese actor es quien aprueba la ejecución

del proyecto.


- 68 -

Usuario: Son aquellos que utilizan directamente el producto del proyecto. Es una

abstracción del conjunto de permisos y de funcionalidades a las cuales se tiene acceso.

Es decir, un usuario puede ser tanto una persona como una máquina, un programa, etc.

Desarrollador: Es aquel que diseña, escribe, depura y mantiene el código fuente

de la aplicación a desarrollar. Está compuesto por actores que realizan tareas más

especificas de desarrollo.

2. El Modelo de Productos

Identifica y caracteriza todo lo que el método debe producir o generar durante la

ejecución de los distintos procesos (Figura 3 - 3). Los conceptos de este modelo se

describen a continuación.

Producto: Es cualquier resultado de ejecutar una actividad o proceso del ciclo de

desarrollo de software. Los productos del Blue WATCH se dividen en tres tipos, de

Gestión, de Soporte y Técnicos.

Producto de Gestión: Los productos de gestión son elaborados durante la

ejecución de los procesos de gestión del proyecto y genera elementos como planes e

informes.

Producto Técnico: Los productos técnicos son todos aquellos que se originan

durante la ejecución de los procesos técnicos del desarrollo de la aplicación. El producto

técnico más significativo es el producto final o aplicación junto con su documentación

donde se incluyen modelos, diseño, programa, especificación, base de datos, etc.

Producto de Soporte: Los productos de soporte se originan durante la ejecución

de los procesos de gestión de la configuración, gestión de riesgos y gestión de la calidad.


- 69 -

class Metamodelo de Productos

Producto WATCH

Producto Técnico Producto de Gestión

Producto de Soporte

Plan

Cronograma

Presupuesto

Organigrama

Informe

Documento Técnico

Modelo

Diagrama

Programa (Código)

Repositorio

Documento de Gestión

Documento de Soporte

Librería

Línea de base

Solicitud

Lista de chequeo

Versión

Aplicación

Especificación

Manual

Incremento

Matriz

Contrato

Figura 3 - 3 Meta Modelo de Productos del Blue WATCH


- 70 -

3. El Modelo de Procesos

El Modelo de Procesos refleja cada uno de los componentes, objetos o entidades

que participan durante el proceso y las relaciones entre cada uno de ellos (Figura 3 - 4).

class Modelo de Procesos

Proceso

Proceso Técnico

Proceso de Gestión

Proceso de Soporte

Proyecto

Activ idad

Restriccion Proposito

Ambiente

Producto

Audiencia

Versión

RequisitoIncremento

Iteración

TareaActorEquipo del Proyecto

tiene1..*

integra1..*

produce1..*

se compone 1..*

implementa

1..*

crea 1

persigue

1..*

se desarrol lan en1..*

pertenece1

conformada1..*

satisface1..*

dirigido_a

es regulado0..*

comprende

*

ejecuta1..*

forma parte

1..*

1..*comprende

realiza

1..*

Figura 3 - 4 Meta Modelo de Procesos del Blue WATCH

La siguiente lista enumera los conceptos asociados al modelo de procesos de

nuestro dominio de estudio:

Proceso: Conjunto estructurado de actividades que son ejecutadas por un

conjunto de actores con la finalidad de cumplir con objetivos pre-establecidos. Un

proceso transforma un conjunto de recursos (insumos: energía, información y materia

prima) en un conjunto de productos o servicios.


- 71 -

Proceso Técnico: Los procesos técnicos se relacionan con las actividades de

análisis, diseño, implementación y pruebas de las aplicaciones.

Proceso de Soporte: Los procesos de gestión usados para la gerencia en el

desarrollo de cada aplicación como un proyecto de ingeniería; involucran, por lo tanto,

actividades de planificación, organización, administración, dirección y control del

proyecto.

Proceso de Gestión: Los procesos de soporte complementan los procesos

técnicos y gerenciales con actividades, tales como: el aseguramiento de la calidad, la

gestión de la configuración y la gestión de riesgos del proyecto.

Proyecto: Un esfuerzo temporal que se lleva a cabo para crear un producto,

servicio o resultado único.

Restricción: Una restricción o limitación aplicable, ya sea interna o externa al

proyecto, que afectará el rendimiento del proyecto o de un proceso.

Propósito: Una meta hacia la cual se debe dirigir el trabajo, una posición

estratégica que se quiere lograr o un fin que se desea alcanzar, un resultado a obtener,

un producto a producir o un servicio a prestar.

Audiencia: Hacia quienes va dirigido la aplicación que se va a desarrollar como

propósito del proyecto.

Requisito: Una condición o capacidad que un sistema, producto, servicio,

resultado o componente debe satisfacer o poseer para cumplir con un contrato, norma,

especificación u otros documentos formalmente impuestos. Los requisitos incluyen las


- 72 -

necesidades, deseos y expectativas cuantificadas y documentadas del patrocinador, del

cliente y de otros interesados. También conocido como: Requerimiento.

Iteración: Es un conjunto organizado de procesos de programación e integración

de software que crean un incremento

Incremento: Es una parte de una versión de la aplicación que implementa un

conjunto relacionado de requisitos. Un incremento es una pieza de código que se

desarrolla progresivamente agregando funcionalidad en cada iteración.

Versión: Implementa un conjunto de aspectos relacionados que pueden

pertenecer a uno o más subsistemas de la arquitectura de la aplicación

Ciclo: Es un conjunto organizado de procesos de desarrollo de software cuya

ejecución produce una aplicación o una versión de ella.

Actividad: Conjunto estructurado de acciones o tareas realizadas por uno o más

actores con la finalidad de alcanzar un objetivo predefinido. Una actividad utiliza

recursos (insumos) para generar productos o prestar servicios.

Tarea: Actividad de corta duración que es ejecutada por un actor en el marco de

otra actividad mayor.

Ambiente: Es el lugar físico o virtual donde se llevan a cabo las actividades y

tareas del proyecto.

Equipo de Proyecto: Se refiere a los actores miembros del equipo del proyecto

que se encargaran de la ejecución del proyecto, las actividades técnicas, de gestión y de

soporte y la realización del producto como tal.


- 73 -

Método BLUE WATCH

El método Blue WATCH es una versión del método WATCH orientada a equipos

pequeños de 3 a 10 participantes y para construir específicamente aplicaciones Web.

La filosofía del método es buscar un balance entre agilidad y disciplina en un

intento de conservar las mejores prácticas de la Ingeniería de Software sin perder

velocidad en el proceso de desarrollo, para permitir, a las pequeñas organizaciones,

contar con un marco de referencia con las que puedan alcanzar altos niveles de calidad

sin el sacrificio y esfuerzo que los métodos tradicionales requieren.

Blue WATCH hereda algunas características fundamentales del método WATCH

pero también tiene grandes diferencias para aportar la agilidad deseada al proceso de

desarrollo. De esta manera Blue WATCH pretende conservar las mejores prácticas de los

métodos tradicionales y de los estándares de calidad como CMMI e ISO pero enfocando

el proceso de desarrollo al uso de estrategias y técnicas que le aporten flexibilidad y

agilidad.

Evolución del Blue WATCH

La versión del método, presentada en este trabajo, está fundamentada sobre

una versión inicial proporcionada por el equipo Methodius, con el objeto de ser

completada, mejorada y, en especial, modificada para lograr alcanzar las características

identificadas que debe cumplir para permitir la agilidad deseada, sin abandonar los altos

estándares de calidad.

La versión inicial proporcionada define claramente la estructura del método,

fundamentada en sus tres modelos: productos, actores y procesos. Adicionalmente,

describe los tres ciclos principales que representan el flujo de procesos del método Blue

WATCH: El Ciclo de la Aplicación, Ciclo de la Versión y Ciclo del Incremento.


- 74 -

Así mismo, la primera versión del método comprende una serie de diagramas de

procesos a muy alto nivel donde no hay detalle de las actividades de cada uno de los

procesos, aunque si se encuentran definidas algunas jerarquías de procesos.

Los productos del método, en la versión inicial, no están completamente

identificados y muchos de los existentes no permiten la característica de agilidad por lo

que el modelo de productos sufrió cambios significativos en la versión presentada en

esta tesis. De igual manera, en esta primera versión, los actores no se encontraban

identificados más allá del meta-modelo de actores sobre el cual se constituyo el modelo

propuesto en este trabajo.

Para diferenciar el trabajo realizado durante esta investigación, del método

inicial original, de aquí en más, nos referiremos a la versión desarrollada, producto del

trabajo presentado en este articulo, como Blue WATCH o Blue WATCH V2

indistintamente. Mientras, que a la versión inicial proporcionada por el equipo

Methodius que sirvió como punto de partida para diseñar a Blue WATCH V2, la

denominaremos Blue WATCH V1.

Características del BLUE WATCH

El método Blue WATCH cubre todo el ciclo de vida de las aplicaciones; desde el

modelado del dominio de la aplicación, pasando por la definición de los requisitos de los

usuarios, la gestión del proyecto, el manejo de la configuración y el aseguramiento de la

calidad, hasta la puesta en operación de la aplicación, pero aportando el nivel de detalle

realmente necesario y que represente valor para el proyecto en curso.

El método incluye también procesos de Gerencia de Proyectos a nivel adecuado

para equipos pequeños de desarrollo donde la comunicación y la alineación aportan

gran parte de la gestión tacita del proyecto.

Más específicamente el método cuenta con las siguientes características:


- 75 -

Identifica procesos, productos y actores esenciales para el desarrollo del

proyecto, así como los que se recomiendan y los que se consideran opcionales.

Elimina la redundancia de información en la documentación, estableciendo la

información plasmada de manera formal con la mayor eficiencia posible en

cuanto a nivel de detalle.

Es fácil de usar para una organización pequeña, permitiéndole alcanzar, con un

grado de dificultad manejable, niveles de calidad aceptables.

Es fácil de entender, es fácil de implementar.

Incluye técnicas agiles de planificación y modelado.

El método Blue WATCH es dinámico, esto quiere decir que una vez implantado el

objetivo principal es irlo reevaluando, adaptándolo a las realidades de la

organización y evolucionando de manera alineada con la consecución de las

metas y objetivos de la organización. El proceso de cierre de fase con las

actividades de reflexión del proceso potencian esta característica, en otras

palabras Blue WATCH no pretende ser la solución final si no el primer paso en el

camino a la eficiencia en el desarrollo.

Está fundamentado en WATCH (Montilva C., Barrios A., & Rivero A., 2008), por

lo tanto, toma en cuenta los esfuerzos previos en cuanto a la definición de la

estructura y modelado del método así como estándares, prácticas y modelos

existentes que ayudan a asegurar la calidad del software:

o El modelo CMMI-SW (Capability Maturity Model Integration) del Instituto

de Ingeniería de Software – SEI (CMMI, 2005).

o El cuerpo de conocimientos de la Ingeniería de Software (SWEBOK) de la

Sociedad de Computación de la IEEE.

o El cuerpo de conocimientos PMBOK (Project Management Body of

Knowledge) del Instituto de Gestión de Proyectos (PMI, 2000).

o Estándares de desarrollo de software de la Sociedad de Computación de

la IEEE.

o Las mejores prácticas de la Ingeniería de Software (Krutchen, 2000):


- 76 -

Ingeniería de Requisitos

Arquitecturas basadas en componentes de software

Uso de lenguajes de modelado visual: UML y UML Business

Nace de un estudio de las características de los métodos agiles y del análisis

comparativo de metodologías de referencia (Scrum, Xp, OpenUp, Merinde,

EssUP, Crystal Clear)

Está sustentada sobre investigaciones previas enfocadas a alcanzar un balance

entre agilidad y disciplina.

Toma en cuenta investigaciones de otros autores relacionadas con la aplicación y

uso de métodos desarrollo, estándares, prácticas y modelos aplicados a

pequeñas empresas.

Toma en cuenta patrones, técnicas y estrategias que se han convertido en

esenciales para la construcción de aplicaciones Web.

A pesar de buscar la agilidad en el proceso de desarrollo no deja de lado

prácticas que permiten a asegurar la calidad del software:

o Gestión del proyecto

o Verificación y validación de la calidad de los productos y procesos

o Gestión de la configuración (control de cambios)

Modelos del Blue WATCH

Blue WATCH V1 está compuesto por tres modelos sobre los cuales se definen los

aspectos participantes de la estructura del mismo:

1) Un modelo de productos que describe los productos intermedios y finales que

se generan, mediante el uso del método, durante el desarrollo de una aplicación

empresarial.


- 77 -

2) Un modelo de actores que identifica a los actores interesados (stakeholders) en

el desarrollo de una aplicación y describe cómo deben estructurarse los equipos

de desarrollo y cuáles deben ser los roles y responsabilidades de sus integrantes

3) Un modelo de procesos que describe detalladamente los procesos técnicos,

gerenciales y de soporte que los equipos de desarrollo deberán emplear para

elaborar las aplicaciones.

Blue WATCH V2 conserva la estructura propuesta en esta primera versión.

Resumen

En la primera sección de este capítulo se establecen y definen las bases sobre las

que está fundamentada la construcción del método Blue WATCH, la definición de cada

uno de los elementos del método forma parte de esta estructura, lo que permite tener

un conocimiento de los conceptos necesarios para entender el método diseñado. Luego,

se narra la evolución entre la versión inicial proporcionada y la generada como producto

de este trabajo de investigación, con el objetivo de cumplir con los requisitos

identificados. Por último, se describen las características del método junto con los tres

modelos de los cuales se desprende la descripción de su estructura, la cual será

explicada en detalle en los siguientes capítulos 4, 5 y 6 donde se describe el método

Blue WATCH representado a través de estos tres modelos de actores, productos y

procesos con lo que se consigue documentar de manera formal el método elaborado.


- 78 -

CAPITULO 4

EL MODELO DE PRODUCTOS

El Modelo de Productos es un componente del Blue WATCH V2, que extiende en

su estructura del Blue WATCH V1 y a su vez del Gray WATCH (Montilva C., Barrios A., &

Rivero A., 2008), sin embargo, no deriva en su contenido. En este modelo, se identifican

y describen los distintos productos que deben generarse durante el desarrollo de una

aplicación Web al instanciar el método.

El objetivo esencial de este modelo es establecer y clasificar los distintos tipos de

productos como documentos, modelos, diagramas, código que se deben generar

durante la ejecución de los procesos del método, así mismo, definir cuando deben

generarse estos productos y su responsable directo o colaboradores.

Este modelo da una guía clara y concisa de lo que cada uno de los actores debe

producir según sus funciones en el seguimiento de los procesos definidos en el método.

Objetivos del modelo

El modelo de productos tiene como objetivos los siguientes:

Orientar a los equipos de desarrollo acerca de los productos que deben

elaborarse en cada proyecto de desarrollo de una aplicación empresarial.

Identificar los productos esenciales, recomendables u opcionales para permitir

una más sencilla instanciación del método


- 79 -

Establecer las entradas y salidas de los procesos del modelo, es decir, el valor

agregado que representa seguir cada uno de los flujos de trabajo definidos en los

procesos de desarrollo de la aplicación

Otro objetivo más relacionado con el método como tal, se deriva del objetivo

principal que es contar con un método balanceado en donde no se descuide la calidad

del producto, ni de los procesos necesarios para garantizar la consecución de esta

calidad; pero, que a su vez permita agilidad y fluidez en el proceso. Un poco guiados por

el enfoque de lo que recomiendan los métodos agiles donde la premisa es no producir

nada que no produzca valor, este objetivo enfocado desde el punto de vista de los

productos a generar se logra de dos maneras:

1. Reducción de la cantidad de artefactos o productos: Es necesario durante la

ejecución de un proyecto de software desarrollar una serie de productos

intermedios que darán apoyo al proceso de construcción del producto final, que

es la aplicación empresarial o en nuestro caso la aplicación Web. Este producto

final es lo que el cliente ve como un valor real y beneficio para su organización y

el objetivo principal por el cual se aprueba el proyecto de desarrollo. Sin

embargo, este objetivo no puede ser alcanzado si no hay apoyo en una serie de

productos intermedios, no siendo estos la meta del proceso, los productos

intermedios se convierten en un medio para un fin, aunque también implican

una inversión de tiempo, esfuerzo y dinero. Para obtener un proceso

balanceado, se busca disminuir la demanda de tales productos intermedios al

mínimo posible. Blue WATCH, además, clasifica los productos como esenciales,

recomendables y opcionales de manera de permitir una más fácil instanciación

del método.

2. Minimización del detalle de los productos intermedios: A menudo en un

proyecto de software se producen una gran cantidad de artefactos, con miras a

disminuir el riesgo de encontrar en etapas avanzadas del proyecto que el

producto que se desea construir no está por completo alineado con las


- 80 -

necesidades del cliente, pero a veces la información que, por convención, llevan

estos artefactos hace que se inviertan largas horas en su construcción sin que se

identifique un valor real en el apoyo a la consecución del objetivo final.

Adicionalmente, la información incluida en estos artefactos a menudo no refleja

la realidad del desarrollo; pues, en el momento en que se está plasmando no se

tiene la visión completa o la compresión necesaria del problema que se está

solucionando, por lo que el tiempo invertido en su construcción se podría ver

como una pérdida. Una manera de manejar esta situación es construyendo estos

documentos con el nivel de detalle necesario, sin pretender quitar información si

no detallarla lo suficiente para que sea adecuada a cada una de las etapas en que

se encuentre el proyecto. Esta estrategia permite, en primer lugar, que los

documentos sean digeridos más fácilmente por sus potenciales lectores y, en

segundo lugar, disminuir la inversión de tiempo en su construcción. Si en etapas

siguientes a la construcción inicial de un producto intermedio se identifica que

hace falta añadir más detalle, el mismo se agrega al documento en el momento

que se requiera.

Componentes del modelo

El modelo de productos del Blue WATCH V2 está compuesto por tres tipos de

productos que se refieren a los productos que se generan al utilizar el método: técnicos,

de soporte y de gestión

Los productos de gestión Son elaborados durante la ejecución de los procesos

de gestión del proyecto entre ellos: inicio, planificación, dirección, control y

cierre del proyecto.

Los productos de soporte Se producen durante la ejecución de los procesos de

soporte: gestión de la configuración, gestión de riesgos y gestión de la calidad.


- 81 -

Los productos técnicos Son aquellos artefactos, modelos o documentos que se

generan a raíz de la ejecución de los procesos técnicos del desarrollo de la

aplicación.

Se detallan y explican a continuación cada uno de estos productos los cuales se

reflejan en el diagrama de la Figura 4 - 1: class Modelo de Productos

Producto Técnico Producto de Soporte Producto de Gestión

«doc. técnico»Modelo del Negocio

«doc. técnico»Documentos de

Requisitos

«doc. técnico»Documentos de Diseño

«aplicación»Aplicación Empresarial

«doc. de soporte»Matriz de Riesgos

«doc. de soporte»Documento de Configuración

«doc. de soporte»Especificación de

Pruebas

«doc. de gestión»Visión del Producto

«doc. de gestión»Plan Integral del

Proyecto

Modelo de Productos del Método BLUE WATCH

Producto BLUE WATCH

«doc. técnico»Documento de

Despliegue

«doc. de soporte»Revisión del Proceso

«doc. de soporte»Revision del Producto

«doc. de gestión»Informes de Avance

«doc. de soporte»Resultados de las

Pruebas

«doc. de soporte»Lista de Chequeo del

Código

«código»Programas de Pruebas

«doc. de soporte»Lista de Chequeo del

Proceso

Figura 4 - 1 Modelo de Productos del Método Blue WATCH


- 82 -

Productos de Gestión

Visión del Producto

Prioridad: Esencial

Responsable principal: Líder de Proyecto.

Proceso que lo genera: Inicio del Proyecto.

Este documento es elaborado durante la etapa de “Inicio del Proyecto” como

producto de las discusiones y acuerdos entre el Líder del Proyecto, el Cliente-Promotor

y/o por los actores o involucrados de una o más gerencias de la empresa que tengan

interés en el desarrollo de una nueva aplicación empresarial.

Puede ser utilizado como punto de partida en el proceso de aprobación del

proyecto para convencer a la alta gerencia de la empresa sobre la necesidad de

desarrollar la aplicación y, por tanto, está estrechamente relacionado con el Caso de

Negocio ya que en él se indica por que el desarrollo de la aplicación es necesario, su

justificación, objetivos, que unidades organizacionales se verán beneficiadas, las

necesidades del negocio que se busca satisfacer y los resultados esperados, esto lo

convierte en un indicador contra el cual todas las decisiones futuras que se tomen

deben ser validadas.

Una vez que ha sido aprobado por la gerencia promotora del proyecto, o aquella

a la cual le concierne la aprobación, este documento se constituye en la autorización

formal de inicio del proyecto

El documento de Visión del Producto es un punto de partida y el marco

referencial para cualquier persona que quiera tener una idea de lo que quiere

desarrollar. Es indispensable que toda persona involucrada en el proyecto tenga

conocimiento del contenido del mismo.


- 83 -

Este documento es un resumen ejecutivo y debe contener la siguiente

información (ver Figura 4 - 2):

Descripción del proyecto: Contiene una descripción global del proyecto, su

justificación, objetivos, necesidades de la organización, definición del problema

que se busca solucionar y una visión general de la solución propuesta

Lista de requisitos seleccionados: Es la lista final de los requisitos de la aplicación

Web que se acordó desarrollar. Cada requisito identificado inicialmente se

muestra de forma resumida en este documento de Visión del Producto.

Lista de Involucrados: En esta sección se identifica a los involucrados del

proyecto, sus roles y las responsabilidades que asumen durante el ciclo de vida

de la aplicación. Se identifican aquellas personas de las cuales se obtienen los

requisitos del sistema, así como, los encargados de la validación de los

entregables. También, se identifican aquellas personas responsables de la

gestión, seguimiento y control del proyecto y los responsables de la ejecución

del mismo

Lista de Riesgos: Pretende tomar una posición preventiva de los posibles riesgos

identificados en las etapas iníciales y que pueden desviar las metas del proyecto.

Limitaciones y Restricciones: Describe la lista de ocurrencias que limitan la

ejecución del proyecto y las restricciones sobre las que se debe adaptar la

solución.


- 84 -

composite structure Visión del Producto


«doc. de gestión»Lista de Necesidades de la

aplicación

«doc. técnico»Lista de requisitos

seleccionados

«doc. de gestión»Lista de Objetiv os del

Proyecto

«doc. de gestión»Descripción del Proyecto

«doc. de gestión»Lista de Inv olucrados

«doc. de gestión»Lista de Riesgos

«doc. de gestión»Limitaciones y Restricciones

Figura 4 - 2 Visión del Producto

Plan del Proyecto

Prioridad: Esencial


Proceso que lo genera: Planificación de la Aplicación

El Plan de Proyecto es un documento utilizado para la gestión del proceso de

desarrollo de la aplicación. El “Líder de Proyecto” es el encargado de generar este

producto, partiendo de una visión de alto nivel y documentando en él la organización de

los recursos utilizados en el proyecto en base a acciones, tiempo y sus derivados (costos,

riesgos, entre otros).

Partiendo de los objetivos enunciados en Gray WATCH (Montilva C., Barrios A.,

& Rivero A., 2008) para el Plan de Proyecto, se identifica como meta de este producto

establecer e identificar los siguientes aspectos:


- 85 -

El alcance del proyecto, expresado en términos de sus productos y los procesos

necesarios para elaborar estos productos.

Las actividades que el equipo de trabajo debe ejecutar para desarrollar la

aplicación Web.

Los recursos necesarios para ejecutar las actividades del proyecto.

El estimado de tiempos de las actividades del proyecto y sus fechas de inicio y

terminación.

La estimación de costos del proyecto.

Los hitos del proyecto.

Los productos intermedios que se deben generar para construir la aplicación

empresarial.

Los estándares y procedimientos de aseguramiento de la calidad del sistema.

Los procesos y procedimientos para la gestión de la configuración del sistema.

Las revisiones técnicas que se realizarán para verificar y validar los productos del

proyecto.

Las pruebas que se llevarán a cabo para verificar y validar el sistema.

Este producto está compuesto por las siguientes secciones (ver Figura 4 - 3):

Definición del Alcance: Identifica el alcance del proyecto (lo que está y lo que no

está incluido en el proyecto). Identifica la Estructura de Desglose de Trabajo EDT

y el alcance de los productos que se deben generar, incluyendo los productos

intermedios.

Presupuesto de Costos: Enfocado en el costo que implica el uso de recursos en el

transcurso del tiempo, se realizan las estimaciones para asegurar el completo

desarrollo del proyecto dentro del presupuesto.

Equipo de Desarrollo: Incluye la estructura organizacional del proyecto y los roles

y responsabilidades identificadas para los participantes del mismo.

Criterios de Aceptación:


- 86 -

Plan de Calidad: En esta sección se establecen las diferentes revisiones del

proceso a realizar durante el ciclo de vida del proyecto. Contiene la

programación de actividades necesarias para dar cumplimiento a la verificación,

validación y mejora de procesos del proyecto.

Cronograma del Proyecto: El cronograma del proyecto es una herramienta de

gestión que identifica y organiza las actividades del proyecto en función de sus

fechas de inicio y culminación. Se establecen los responsables de las actividades

así como el orden cronológico de las actividades, asociándoles las respectivas

prelaciones. Establece, también, la entrega de productos (hitos del proyecto), la

ruta crítica de actividades y el esfuerzo requerido para realizar cada actividad,

por lo que debe hacerse natural su continuo seguimiento y consulta por todo el

equipo de trabajo.

El Plan de Calidad es un plan subsidiario que se considera opcional, más adelante

se explicará los motivos para no incluir este plan en un proyecto especifico.

El Plan de Proyecto es revisado y validado por los miembros del equipo, en

especial en las áreas de conocimiento que más les concierne. Para establecer los

estimados y actividades, el “Líder de Proyecto” se apoya en el conocimiento del resto

del equipo de manera que el producto final debe ser un plan consensuado, donde los

integrantes adquieren un nivel de compromiso en cuanto a las fechas de entrega y las

actividades a realizar, producto de haber participado en el proceso de planificación.

Es importante tomar en cuenta que el Plan del Proyecto debe verse como un

documento de planificación inicial y que el detalle de las actividades se irá actualizando

y especificando en el “Cronograma del Proyecto” a medida que se avance en las etapas

del proyecto. El proceso de “Planificación del Proyecto” se descompone en tres sub-

procesos que permiten realizar esta actividad de manera iterativa e incremental:

Planificación de la Aplicación, Planificación de la Versión, Planificación del Incremento,


- 87 -

la idea es identificar, en cada etapa del desarrollo de la aplicación, las actividades a

ejecutar durante esa fase y especificar las tareas relacionadas. Además, se debe acotar

que esta planificación se debe ir actualizando y modificando como consecuencia del

seguimiento y control del proceso y de los eventos que vayan afectando las actividades

establecidas. Por esta razón, el detalle de la planificación no debería convertir este

proceso en un esfuerzo excesivo, la experiencia y la práctica siempre ayudarán a generar

mejores planes con menor esfuerzo.

composite structure Plan Integral del Proyecto

«doc. de gestión»Definición del Alcance

«cronograma»Cronograma del Proyecto

«doc. de gestión»Alcance del Proyecto

«modelo»Estructura de Desglose del

Trabajo

«doc. de gestión»Plan de la Calidad

«doc. de gestión»Plan de Aseguramiento de

la Calidad

«doc. de gestión»Plan de Pruebas

«organigrama»Estructura Organizacional

del Proyecto

«presupuesto»Presupuesto de Costos

«doc. de gestión»Plan del Proyecto

«doc. de gestión»Alcance de Productos del

Proyecto

«doc. de gestión»Criterios de Aceptación

«doc. de gestión»Equipo de Desarrollo

«doc. de gestión»Roles y Responsabilidades

Figura 4 - 3 Plan de Proyecto

Informes de Avance

Prioridad: Opcional


Proceso que lo genera: Control del Proyecto.

Estos informes sirven para reflejar el estado del proyecto en un momento dado,

presentando los alcances obtenidos, las faltas y fallas, a fin de establecer no solo el


- 88 -

estatus actual del proyecto, sino también presentar los acuerdos y compromisos que se

desencadenan para resolver los contratiempos ó mejorar en las próximas actividades. El

“Informe de Avance” es el producto del proceso de “Control del Proyecto” y puede

quedar reflejado en las minutas de las reuniones de seguimiento o de una manera más

formal haciendo uso de alguna plantilla definida. De igual manera, es apropiado

establecer tiempos continuos para realizar las reuniones para recoger la información de

la que se generan estos informes.

Es importante que en estos informes se refleje la realidad del proyecto, para lo

que se requiere mantener la comunicación con los colaboradores e involucrados. De

igual manera, es importante registrar las eventualidades encontradas en el proceso de

desarrollo que pudiesen ocasionar retrasos en las entregas, para establecer las acciones

correctivas a tiempo e impedir retrasos en el proyecto.

El responsable de validar que esta información este quedando evidenciada es el

“Líder de Proyecto”, pero su ejecución puede ser delegada en alguno de los miembros

del equipo. Si el tamaño del proyecto es mayor, se considera que estos informes se

vuelven más relevantes y se recomienda que se realicen.

Productos de Soporte

Matriz de riesgos

Prioridad: Recomendado


Proceso que lo genera: Identificación y Análisis de los Riesgos.

La matriz de riesgos constituye una herramienta útil para el control y gestión de

los riesgos del proyecto. El uso correcto de la matriz de riesgo permite hacer

comparaciones objetivas entre proyectos, áreas, productos, procesos o actividades.


- 89 -

Gestionar eficazmente los riesgos ayuda a garantizar resultados concordantes

con los objetivos estratégicos de la organización. Desde este punto de vista, la gestión

integral de los riesgos se vuelve parte fundamental de la estrategia y factor clave del

éxito del proyecto. En este sentido, es imprescindible contar con una herramienta que

permita:

Identificar los riesgos del proyecto

Monitoreo y medición de los riesgos.

Establecer las actividades preventivas y correctivas

Esta matriz contiene la identificación de los riesgos asociados al desarrollo del

proyecto y su análisis respectivo (Figura 4 - 4). La Identificación de los riesgos exige la

participación activa de los involucrados en el proyecto para lograr reflejar los

potenciales peligros que pudiesen poner en riesgo el éxito del proyecto.

Se identifica para cada riesgo: Categoría, descripción, consecuencia, Impacto,

probabilidad, exposición, estrategia para atacarlo

Es importante establecer las acciones de:

Mitigación: Acciones para evitar que se presente el evento. Disminuir la

vulnerabilidad del proyecto hacia el riesgo

Contingencia: Actividades para lograr disminuir el impacto sobre el proyecto una

vez ocurrido el evento de riesgo. Es el plan de respuestas a la ocurrencia de un

evento

La identificación de los riesgos se realiza en el ciclo de la aplicación durante el

proceso de “Identificación y Análisis de los Riesgos” y es responsabilidad principalmente

del “Líder de Proyecto” pero todo el equipo debe colaborar en el hallazgo de los

mismos para que sean manejados apropiadamente. Los riesgos serán monitoreados a

través de todo el proceso de desarrollo en el proceso identificado como “Control de

Riesgos” que también es ejecutado por el “Líder de Proyecto”.


- 90 -

composite structure Matriz de Riesgos


Lista de riesgos identificados

Acciones de Mitigación Acciones de contingencia

Figura 4 - 4 Matriz de Riesgos

Documento de Configuración

Prioridad: Recomendado.

Responsable principal: Líder de Desarrollo.

Proceso que lo genera: Gestión de la Configuración.

Este documento contiene los elementos de configuración del proyecto, se refiere

a todos los elementos que intervienen o participan, y que son necesarios para la

elaboración del mismo. Incluye configuración del hardware, software, repositorios, base

de datos entre otros. Este informe se realiza en el ciclo de la aplicación durante el

proceso de “Gestión de la Configuración” y es ejecutado por el “Líder de Desarrollo” y se

actualiza cada vez que sea necesario hacer una re-planificación o modificación del

proyecto por cambios significativos en las condiciones de configuración, este proceso se

le denomina “Control de configuración” y se realiza periódicamente normalmente en el

cierre de las etapas o como consecuencia de algún evento que afecte la configuración

del proyecto.

Tal como se visualiza en la Figura 4 - 5, en él se describen:

Recurso de Hardware y Software del Proyecto

Herramientas de tracking o seguimiento usadas en el proyecto


- 91 -

Repositorios y sistemas de control de versiones

Procesos de manejo de petición de cambio

Procesos de manejo de petición de alcance

Plan de Configuración

Matriz de Configuración

composite structure Documento de Configuración

«doc. de soporte»Documento de Configuración

«doc. de soporte»Lista de Roles y

Responsabilidades de Configuración

«doc. de soporte»Repositorio de los

Elementos

«doc. de soporte»Herramienta de Tracking

«doc. de soporte»Procedimiento de Control

de Cambio

«doc. de soporte»Matriz de configuración

«doc. de soporte»Herramientas de Soporte

Figura 4 - 5 Documento de Configuración

Especificación de Pruebas

Prioridad: Esencial.

Responsable principal: Especialista de Pruebas.

Proceso que lo genera: Diseño de Pruebas del Incremento j.

Incluye especificación de pruebas funcionales y no funcionales, para lo que se

toman en cuenta los “Casos de Uso” modelados anteriormente; en base a estos Casos

de Uso se diseñan los distintos tipos de pruebas: Validación de datos, Pruebas de

Integración, Pruebas de Estrés, Pruebas de seguridad, entre otros.


- 92 -

Para cada prueba, él (o los) Especialista de Pruebas establecerá todos los

posibles casos presentables en la ejecución de cada funcionalidad. Se realiza el

respectivo diseño a través de la especificación de las entradas y salidas de la prueba,

para luego programar (en caso de pruebas automatizadas) los scripts de prueba.

La ejecución de las pruebas diseñadas se realiza al cierre de cada fase y antes del

despliegue de la aplicación en el ambiente del cliente, de acuerdo a los resultados

obtenidos durante la ejecución se emiten reportes de las fallas encontradas para su

corrección y monitoreo.

Al finalizar la etapa de resolución de fallas, se realiza un despliegue de la

aplicación para proceder a otro ciclo de prueba con el objetivo de corroborar que los

errores reportados fueron corregidos y su corrección no generó algún desajuste en las

funcionalidades.

El proceso de ejecución de pruebas debe ser ejecutado por alguien ajeno a las

partes del producto revisado, pues debe ser lo más objetivo posible para obtener el

mayor grado de integridad.

composite structure Especificación de Pruebas

«especificación»Especificación de Diseño

de Pruebas

«especificación»Especificación de Casos

de Prueba

«especificación»Especificación de

Procedimiento de Pruebas

«código»Especificación de

Pruebas

Figura 4 - 6 Especificación de Pruebas


- 93 -

Resultado de Pruebas


Responsable principal: Especialista de Pruebas.

Proceso que lo genera: Pruebas del Incremento.

Durante la ejecución de las pruebas, se realiza el registro de resultados de las

mismas, donde se establece el estatus de cada una de ellas como exitoso en caso de

haber cumplido con el comportamiento esperado o falla en caso contrario. Al culminar

el proceso de pruebas del la aplicación, se procede a realizar un informe que resuma el

resultado de las mismas con la idea de generar métricas y estadísticas para su uso

futuro.

Este Informe de Resultados es generado por el “Especialista de Pruebas” al final

del proceso de “Pruebas del Incremento”. Al finalizar la etapa de resolución de fallas, se

realiza un despliegue de la aplicación para proceder a otro ciclo de prueba con el

objetivo de corroborar que los errores reportados fueron corregidos y su corrección no

generó algún desajuste en las funcionalidades. En esta etapa debe realizarse

nuevamente el reporte de fallos, en espera de encontrar un número menor significativo

de correctivos a aplicar.

composite structure Resultados de las Pruebas

«doc. de soporte»Resultados de las Pruebas

«doc. de soporte»Informe de Resultados

«doc. de soporte»Reporte de Incidencias

Figura 4 - 7 Resultados de la Pruebas


- 94 -

Lista de Chequeo del Código



Proceso que lo genera: Revisión del Producto (entre pares)

Se establece una lista de pautas con que debe cumplir el código desarrollado,

estándares y buenas prácticas de desarrollo. Estos estándares pretenden evaluar el

contenido técnico y la calidad del código, dándole al equipo de revisión una herramienta

que les permita realizar el debido chequeo del cumplimiento en los mismos.

Adicionalmente, el equipo de desarrollo podrá hacer uso de esta lista para asegurarse

de dar cumplimiento a las pautas impuestas al momento de codificar la aplicación

empresarial.

La responsabilidad de generar esta lista recae sobre el Líder de Desarrollo, pero

debe formar parte de los estándares utilizados a nivel operativo en la organización y no

se recomienda enfocarlo solamente como algo relacionado directamente al proyecto, si

no, mas bien, como parte del proceso usado en la organización.

Revisión del Producto



Proceso que lo genera: Revisión del Producto.

Por medio de pautas en áreas de evaluación ó revisión, se valora la acertividad

en las metas previamente establecidas y el cumplimiento de las pautas. El objetivo es

evaluar el producto desarrollado en el seguimiento de los lineamientos que deben

cubrirse y bajo los que debe desarrollarse el software.

Existe un mínimo de requisitos a cumplir bajo ciertos lineamientos, que le dan

valor agregado a la calidad del producto. Estos lineamientos deben ser conocidos por el


- 95 -

grupo de desarrolladores y el equipo involucrado en el proyecto, con el fin de construir

el producto bajo estas pautas establecidas desde su inicio.

La revisión del producto se hace sobre la Lista de Chequeo del Código, donde se

refleja cada uno de los aspectos técnicos que se evalúan al realizar la revisión.

Generalmente incluye ítems relacionados con el cumplimento de la arquitectura,

estándares de codificación y buenas prácticas conocidas.

Este documento es desarrollado por el “Líder de Desarrollo” en colaboración con

el “Especialista de Calidad” y el “Arquitecto Diseñador”.

Lista de Chequeo del Proceso

Prioridad: Opcional.

Responsable principal: Especialista de Calidad.

Proceso que lo genera: Planificación de aseguramiento de la Calidad.

Se establece una lista de chequeo que contiene los procesos y actividades que

comprenden el proyecto, con el objetivo de comprobar la ejecución correcta del

proceso. Adicionalmente, se pueden añadir indicadores de gestión, cuyo principal

objetivo es brindarle a la actividad de Revisión del Proceso una guía fundamentada en el

uso de esta herramienta, bajo un patrón establecido, que permitan dar una evaluación

estandarizada a cada proceso.

Revisión del Proceso

Prioridad: Opcional.

Responsable principal: Especialista de Calidad.

Proceso que lo genera: Planificación de aseguramiento de la Calidad.

La revisión del proceso busca asegurar que se siguen las pautas establecidas para

el proceso de desarrollo, el “Especialista de Calidad” es el encargado de definir la


- 96 -

manera en que desarrollará esta actividad por medio de la ejecución del proceso de

“Planificación de Aseguramiento de la Calidad”.

La revisión del proceso, generalmente, se realiza por medio de la Lista de

Chequeo del Proceso que permite la comprobación de la ejecución correcta del proceso.

Debido a que este proceso comprende un conjunto de herramientas de chequeo

y revisión de los procesos, se incluyen medidas de control por cada actividad y, por

ende, de los procesos. La lista de chequeo lleva un orden que permite evaluar de

manera progresiva y organizada, facilitando, a quien realiza la revisión, tener visión y

control sobre la totalidad de los procesos.

Esta actividad de revisión es conocida como auditoria de calidad y se ejecuta a

través del proceso de “Monitoreo de la Calidad de los Procesos”

Productos Técnicos

Modelo del Negocio


Responsable principal: Analista.

Proceso que lo genera: Modelado de Negocio.

Una vez que se haya culminado la ejecución del proceso de gestión "Inicio del

Proyecto" y se cuente con la "Visión del Producto" se lleva a cabo la ejecución del

primer proceso a nivel técnico definido por el método, el "Modelo de Negocio". El

objetivo principal es asegurar que el equipo de desarrollo tenga un conocimiento

adecuado del dominio de la aplicación, de manera tal que se facilite, en los procesos

siguientes, describir apropiadamente los requisitos de la aplicación. Este modelo es una

herramienta importante que se utilizará para aumentar las posibilidades de éxito del

proyecto, contando con una forma idónea de comunicación entre los participantes de

todos los niveles.


- 97 -

El modelado de negocio ayuda a asegurar que tanto la solución que se pretende

construir, así como los que participan en su desarrollo, se encuentran alineados con las

estrategias de la organización u organizaciones a la cual se les presta el servicio. Una

buena manera de lograr esto, es plasmar de manera gráfica los procesos que forman

parte de la solución, y a los cuales la misma debe dar soporte, así como los elementos

que participan en ellos y las relaciones e interacciones entre estos procesos y

elementos, es decir, la secuencia de ejecución de estos procesos y los mensajes que

fluyen entre los diferentes elementos participantes.

Los elementos y procesos que se deben plasmar en el modelo de negocio son los

que afectan directamente la construcción de la solución, la información contenida en el

documento se debe limitar a elementos y procesos significativos, simplificando la

descripción de los flujos de trabajo que se detallaran más adelante en etapas más

avanzadas del proceso durante el diseño detallado de la aplicación.

En este documento, se describe el Sistema de Negocios al identificar claramente:

Los objetivos del sistema de negocios donde estará ubicada la aplicación

empresarial.

Los procesos de negocio que permiten alcanzar dichos objetivos y las actividades

que integran estos procesos (flujos de trabajo).

Los actores de la empresa que ejecutan estos procesos de negocio y las unidades

a las cuales estos actores están adscritos.

Los objetos de negocio que intervienen, en modo alguno, en la ejecución de los

procesos de negocio.

Las reglas del negocio que los procesos de negocio emplean para ejecutar sus

actividades.


- 98 -

Las siguientes interrogantes son el principal objetivo de plasmar el Modelo del

Negocio: ¿Cuál es el sistema de negocios (o procesos de negocio) que será apoyado por

la aplicación? ¿Qué unidades organizacionales requieren la aplicación? ¿Quién requiere

la aplicación? ¿Quiénes son los interesados (stakeholders) del proyecto?

class Modelo del Negocio

«modelo»Modelo de Procesos

del Negocio

«modelo»Modelo de Objetos del

Negocio

«doc. técnico»Lista de Reglas del

Negocio

«doc. técnico»Lista de Actores (roles)

«modelo»Estructura Organizativa

del SN

«doc. técnico»Glosario de Términos

«diagrama UML»Diagrama de Clases de

Objetos del Negocio

«doc. técnico»Descripción del Sistema

de Negocios

«diagrama UML»Cadena de Valor

«diagrama UML»Descripcion de

Procesos

«diagrama UML»Diagrama de Actividades

«doc. técnico»Lista de Objetivos del

SN


«doc. técnico»Lista de Procesos del Negocio/Actividades

«doc. técnico»Lista de Objetos del

Negocio

1 1

1

0..1

0..1

0..1

1..*

1

1

1

1

0..*

0..*

1

Figura 4 - 8 Modelo de Negocio


- 99 -

Documentos de Requisitos

Los requisitos representan las características o condiciones que debe cumplir el

sistema. Su gestión se debe hacer durante todo el proyecto, inicialmente, para su

descubrimiento y definición y, luego, para su análisis y control.

Una apropiada gestión de los requisitos ayudará a garantizar el éxito del

proyecto de desarrollo, así como a disminuir el tiempo del proyecto y el número de

errores de la aplicación.

Durante el proceso de "Inicio del Proyecto" se identifican los requisitos iníciales a

alto nivel, que nacen de la lista de necesidades establecida por el Cliente y se reflejan

en la “Visión del Producto”. Luego, durante el proceso de "Desarrollo de Requisitos", el

"Líder de Proyecto" los identifica de manera más detallada para plasmarlos en la "Matriz

de Requisitos", artefacto que permitirá realizar una gestión continua de los mismos

durante todo el ciclo de desarrollo de la aplicación.

Los requisitos identificados y plasmados en estos documentos incluyen tanto las

necesidades de carácter funcional como no funcional que la aplicación empresarial debe

satisfacer. Los requisitos funcionales se analizan para definir la manera en que serán

implementados dentro de la aplicación.

El análisis de los requisitos realizado por el "Analista-Diseñador" produce entre

otros los "Documentos de Casos de Uso (CU)". Estos documentos describen en detalle

cada una de las funcionalidades relacionadas con un requisito, y contra estos

documentos el "Cliente-Promotor" y/o los "Representantes de Usuario" validarán la

información levantada y la correcta comprensión del requisito.


- 100 -

El paso final es la realización de los CU en el diseño detallado expresados en

modelos dinámicos (diagramas de secuencia y de estado) donde se reflejará el

comportamiento de los CU. Este último paso es aconsejable pero se puede obviar para

aportar agilidad al proceso. Se recomienda realizar los modelos dinámicos siempre que

las características del proyecto así lo exigen para aquellos CU que lo ameriten (casos de

uso complejos, con largos flujos de comunicación, o nivel de dependencia con otros CU

muy altos) o exigencia de alto nivel de documentación por alta necesidad de contar con

una aplicación mantenible.

class Documento de Requisitos de la Aplicación

«modelo»Analisis de Requisitos

«doc. técnico»Matriz de requisitos

«doc. técnico»Documento de Casos de

Uso

«doc. técnico»Lista de requisitos

seleccionados

«doc. técnico»Descripciones textuales


Requisitos

«doc. técnico»Especificaciones

Funcionales

«diagrama UML»Diagramas de CU (Detallado)

«modelo»Modelo Funcional

Figura 4 - 9 Documentos de Requisitos

Lista de Requisitos seleccionados



Proceso que lo genera: Inicio del Proyecto.


- 101 -

Es una lista de alto nivel donde se enumeran las necesidades convertidas en

requisitos; proviene de las solicitudes realizadas por el cliente y negociadas durante la

etapa de Inicio del Proyecto. Esta lista se documenta en la Visión del producto.

Especificaciones Funcionales


Responsable principal: Analista.

Proceso que lo genera: Identificación de Requisitos.

Partiendo inicialmente de las necesidades del sistema y de la lista de requisitos

seleccionados, se realiza el desglose escrito de los procesos que va a apoyar la aplicación

empresarial. Dicha descripción escrita en palabras de los “Representantes de Usuario”

tiene como objetivo plasmar la información recabada durante el levantamiento de

requisitos.

El Analista se encarga de levantar esta información durante la ejecución del

Proceso de Identificación de Requisitos. Este proceso se puede ejecutar en paralelo al

Modelado del Negocio ya que ambos implican obtención de información de parte de los

Representantes de Usuarios.

Es en este documento donde se detalla de manera descriptiva cómo funciona el

negocio, orientado a las áreas que serán automatizadas por la aplicación, detallando

qué procesos se ejecutan y qué actores participan en dichos procesos, entre otros. A

partir de este levantamiento inicial, se comienza el análisis de los requisitos del

proyecto y representa la fuente principal de información para la creación del modelo de

negocio, el cual es refinado a través de diversas validaciones con el cliente, pudiendo

representar más reuniones de levantamiento de información. Partiendo de estas

especificaciones funcionales se establecen de manera detallada los requisitos y, en

consecuencia, los Casos de Uso a desarrollar y de allí se diseña la solución que más se


- 102 -

adapte al producto deseado, por lo cual este documento está dirigido a los miembros

del equipo de desarrollo, en especial, a los que participan en el análisis y diseño de la

aplicación empresarial, así como a los responsables por parte del cliente.

Matriz de requisitos



Proceso que lo genera: Identificación de Requisitos.

La matriz de requisitos refleja en mayor detalle cada uno de los requisitos de la

aplicación así como los Casos de Uso que aportan su solución. Dicha matriz contiene el

responsable (por parte del cliente y del equipo de desarrollo) del requisito, estado de

cada uno de ellos, así como otra información relevante relacionada con los requisitos.

Esta matriz es generada por el “Líder del Proyecto” durante el Proceso de

“Identificación de Requisitos” y utilizada principalmente por él mismo como

herramienta para la gestión y seguimiento de los requisitos, además el equipo de

desarrollo debe consultarla como referencia principal de la aplicación que se desea

construir. Los documentos de CU deben mantener consistencia en estructura y

contenido con lo reflejado en esta matriz. Cualquier cambio identificado durante el

análisis de los requisitos debe ser actualizado en la matriz para mantener el tracking

necesario para la gestión del proyecto.

Documento de Casos de Uso

Prioridad: Esencial

Responsable principal: Equipo de Desarrollo.

Proceso que lo genera: Especificación de Requisitos.


- 103 -

Estando establecidos los requisitos por parte del cliente y organizados para el

manejo del equipo de desarrollo, es necesario desarrollar ó describir cada funcionalidad.

Es en la etapa de “Especificación de Requisitos” donde los encargados del Análisis y

Diseño, mediante los documentos de Caso de Uso, expresan las necesidades a ser

validadas posteriormente por medio de mecanismos eficientes de comunicación que

tanto el cliente como el equipo de desarrollo entiendan. De allí que los Casos de Uso no

se consideran parte del diseño sino parte del análisis de los requisitos, pues describen lo

que el sistema debe hacer, a manera de secuencia de pasos, desde el punto de vista del

usuario, es decir, describen el uso del sistema y cómo este interactúa con el usuario.

Adicionalmente, en cada CU se incluye el respectivo diagrama UML, pues

representan gráficamente cada una de las acciones que el usuario puede realizar. Esto,

junto con la descripción textual necesaria y en lenguaje natural, complementa y aclara

las especificaciones técnicas.

Estos documentos, además de usarse como herramienta de validación y

aprobación por parte del cliente, están orientados a guiar y dirigir posteriormente el

proceso de implementación del sistema propuesto. De igual manera estos documentos

darán el debido soporte al equipo de pruebas para, de acuerdo a lo detallado, realizar el

diseño de las mismas, dándole valor agregado como documento de soporte a la

verificación del sistema.


- 104 -

class Documento de Diseño Detallado


Uso


«diagrama UML»Diagramas de CU

(Detallado)


Figura 4 - 10 Documentos de Casos de Uso

Documentos de Diseño

De mayor detalle técnico, estos documentos contienen los detalles asociados a la

arquitectura del sistema y los componentes que estén relacionados; su principal

finalidad es traducir el análisis de los requisitos realizado previamente, a su

implementación en código.

En las actividades de diseño, se involucra a los analistas-diseñadores del equipo

de desarrollo, quienes establecerán marcos de referencia a seguir en el proceso de

creación del producto, y está dirigido a cualquiera de los miembros del equipo de

desarrollo así como también a los responsables por parte del cliente.

En este modelo se establecen como documentos de diseño:

El Documento de Arquitectura, que contiene las especificaciones relacionadas a

la arquitectura establecida para el desarrollo del software.


- 105 -

Diseño de Interfaz Web, plasmado a nivel de código para la aplicación.

Diseño Detallado, comprendido por un conjunto de documentos, que

corresponden al detalle a un nivel más bajo de cada caso de uso.

Diseño de la Base de Datos, en el que se presenta el modelo de los datos,

debidamente documentado para mantener el soporte del mismo.

class Documento de Diseño

«doc. técnico»Documentos de Diseño

«doc. técnico»Arquitectura de la Aplicación

«código»Diseño de Interfaz Web

«doc. técnico»Diseño de la Base de Datos

«doc. técnico»Diseño Detallado

Figura 4 - 11 Documentos de Diseño

Arquitectura de la Aplicación


Responsable principal: Arquitecto Diseñador.

Proceso que lo genera: Diseño Arquitectónico.

Provee una visión de alto nivel de la arquitectura del sistema, estableciendo la

funcionalidad de cada componente. Proporciona los lineamientos que darán apoyo al

desarrollo de la solución requerida detallando las pautas que caracterizan a cada una de

las funcionalidades a través de un conjunto de vistas que representan el sistema.


- 106 -

Por medio de este documento, se puede dar a conocer las decisiones de

arquitectura más significativas que fueron tomadas para la estructuración del sistema y

presenta los aspectos que se consideran relevantes para la comprensión de la

estructuración funcional del mismo, como metas, restricciones, vistas arquitectónicas,

etc.

El Arquitecto Diseñador se encarga de establecer estos parámetros basado en la

información obtenida del cliente y sus necesidades y limitaciones tecnológicas, el

proceso se llama Diseño Arquitectónico y en el puede colaborar también el Líder de

Desarrollo u otros miembros del Equipo de Desarrollo que aporten en la definición de la

solución.

El principal objetivo de este documento es describir los objetivos del proyecto en

cuanto a los requerimientos arquitectónicos que brinde a la aplicación características

deseables, como permitir el escalamiento y mantenimiento de la misma y que sirva

como marco de referencia para todo el equipo de desarrollo.

El documento de arquitectura está constituido por tres tipos de elementos:

Metas y restricciones de la arquitectura.

Representación arquitectónica. Aquí se puede mostrar un modelo de

componentes (o módulos) combinado con otros estilos arquitectónicos, en el

que se establece de manera general las funcionalidades de cada componente

Un conjunto de vistas que describen los aspectos más importantes de la

arquitectura de software, como son: la vista funcional y la vista estructural.


- 107 -

class Documento de Diseño Arquitectónico

«modelo»Vista Estructural

(Lógica)

«modelo»Vista Funcional (de

Uso)

«modelo»Vista de Despliegue

«modelo»Estructura del

sistema (subsistemas y

relaciones)

«diagrama UML»Diagramas de Casos de

Uso (Alto Nivel)

«diagrama UML»Diagramas de Clases

«diagrama UML»Diagramas de

Componentes (Alto Nivel)

«diagrama UML»Diagramas de

Despliegue

«modelo»Lista de metas y

requisitos arquitectónicos

«doc. técnico»Arquitectura de la

Aplicación

«modelo»Vista de Datos

Figura 4 - 12 Arquitectura de la Aplicación

Diseño de la Interfaz Web


Responsable principal: Diseñador Web.

Proceso que lo genera: Diseño del Prototipo de Interfaz Web.

La interfaz presenta la cara visible de la aplicación Web, está constituida por una

serie de elementos, como menús, formularios, tablas e iconos, que permiten la

interacción del usuario con las funcionalidades implementadas.

Siendo este el medio de comunicación entre el usuario y la aplicación, requiere

de la aprobación del Cliente-Promotor y de los Representantes de Usuario. El Diseñador

Web debe contar con los requisitos de interfaz establecidos por el cliente Durante la

Etapa de Desarrollo de Requisitos para luego realizar el Diseño de Interfaz Web durante

el Diseño Detallado de la Versión.


- 108 -

El objetivo del diseño gráfico de la interfaz no es sálo lograr una aplicación

visiblemente agradable, sino también añadir eficiencia, comodidad y manejabilidad,

mejorando así la interacción humano-máquina.

El diseño de la interfaz Web incluye tanto el grafo de navegación a través de la

aplicación, como el prototipo de la interfaz.

class Documento de Diseño de Interfaz

«código»Grafo de navegación a través de la aplicación

«código»Prototipo de la interfaz

«código»Diseño de Interfaz Web

Figura 4 - 13 Diseño de Interfaz Web

Grafo de Navegación

Está compuesto por cada una de las páginas que conforman el sitio web de la

aplicación, basándose en la estructura previamente modelada. Dicha estructura

tiende a cumplir con los requisitos del cliente y debe darle la mayor

funcionalidad en cuanto a la navegación, para lo que se recomienda organizar las

funcionalidades por módulos, teniendo en cuenta las características comunes de

usabilidad.

Prototipo de la interfaz

A modo de plantilla, se diseñan los principales secciones que contendrá la

aplicación WEB, incluyendo ejemplos de los elementos más comunes. Este


- 109 -

prototipo es evaluado por el cliente para obtener una retroalimentación, de la

que se puede obtener una aprobación directa ó la necesidad de ajuste en los

requisitos que debe cubrir la aplicación.

Dichos prototipos están construidos en base a hojas de estilos que contienen:

Plantillas de la estructura de la página.

o Cabecera

o Menús horizontales

o Menús laterales

o Pie de página

o Secciones establecidas

Plantillas de los distintos elementos de las páginas

o Formularios

o Tablas

o Listas

o Botones

Diseño Detallado



Proceso que lo genera: Diseño Detallado.

Para cada Caso de Uso definido y modelado previamente, se diseña la solución

estableciendo las funcionalidades internas de cada módulo, los flujos de datos entre las

capas definidas y la interacción tanto de los actores con las funcionalidades, como de las

funcionalidades entre sí. Esto es, la especificación de las características que tiene cada

componente arquitectónico de la aplicación: la interfaz usuario/sistema, la lógica del

negocio y el componente de persistencia. Estos tres elementos deben ir acompañados

de las descripciones textuales necesarias que complementan y aclaran las

especificaciones técnicas.


- 110 -

En cada incremento de la aplicación, se debe actualizar el diseño detallado de

cada caso de uso incluyendo el detalle de lo codificado y actualizando la información de

lo que fue implementado en iteraciones anteriores.

Diseño Detallado de la Versión

Es el detalle del diseño a nivel de la versión, elaborado por los programadores

bajo supervisión y revisión del analista diseñador responsable. Este documento está

compuesto por:

1) Modelo Estructural: establece las clases definidas, sus atributos y relaciones,

como modelo estructural del producto; no detalla que ocurre ni en que

momento. Para este modelo se incluye el Diagrama de Clases, que debe ser

desarrollado como diagrama básico para diseño detallado.

2) Modelo Dinámico: incluye los diagramas que definen las acciones, tiempos,

relaciones. Para ello se realiza:

Diagrama de Estados: refleja los estados por los que pasa un objeto,

entidad o componente y los eventos que activan los cambios estado y las

respuestas o salidas de los procesos. Su realización se considera

opcional, son útiles para diseñar procesos complejos donde las entidades

cambian varias veces de estado durante su ejecución

Diagrama de Secuencias: contiene la interacción de los objetos de una

funcionalidad o caso de uso. Este diagrama sirve para modelar detalles de

implementación de la aplicación y de la lógica de las transacciones entre

sus objetos. Son recomendables cuando las transacciones modeladas son

complejas o siguen un camino que no es el común dentro de la

aplicación, no se consideran necesarios para modelar la lógica de

aquellos casos de uso del sistema con un bajo nivel de complejidad.


- 111 -

class Especificación Detallada de la Iteración

«doc. técnico»Diseño Detallado

«modelo»Modelo Dinámico

«diagrama UML»Diagrama de Estados

«diagrama UML»Diagrama de Secuencias

«diagrama UML»Diagramas de clases


«diagrama UML»Diagramas de CU

(Detallado)

«modelo»Modelo Estructural


Uso


«doc. técnico»Documento de Diseño

Detallado de la Versión i

Figura 4 - 14 Diseño Detallado

Diseño de Base de Datos

Prioridad: Esencial

Responsable principal: Líder de Desarrollo y Arquitecto Diseñador.

Proceso que lo genera: Diseño de la BD.

Las Bases de Datos son repositorios donde se almacenan los datos que usa la

aplicación empresarial.

Este documento pretende dar una visión clara del modelo de Base de Datos y de

todo lo que tiene que ver con la persistencia (repositorio de datos) del proyecto y su


- 112 -

implementación física, representada a partir de la identificación y modelado de las

entidades que participan dentro de la aplicación y las relaciones entre ellas.

El objetivo principal de este documento es:

Identificar las entidades que hacen vida dentro de la base de datos (Lista de

entidades).

Modelar las entidades que hacen vida dentro de la base de datos y la relación

entre ellas (Diagrama ER).

Para cada entidad representada en el diagrama ER, describir el propósito, los

atributos y las relaciones entre las mismas, así como las características físicas y

lógicas de cada uno de ellos.

Descripción de las funciones y procedimientos que ejecuta el SMDB (Bases de

datos dinámicas)

Proveer la información técnica necesaria para que los equipos de desarrollo

puedan acceder a la BD de la aplicación empresarial.

Documentar cada una de las entidades con sus atributos y relaciones, las

funciones y los procedimientos

Se lleva la información desde una idea conceptual, tomando en cuenta su uso en

las distintas áreas de aplicación, a un plano lógico para finalmente plasmarlo en un

plano físico. Es ideal que la persona que realice esta actividad tenga los conocimientos

técnicos asociados así como una visión clara del modelo de negocios para lograr obtener

una solución que soporte el comportamiento deseado del software. El Analista-

Diseñador realiza este diseño en colaboración con el Líder de Desarrollo y se irá

refinando progresivamente durante el proceso en colaboración con el resto del Equipo

de Desarrollo.

El contenido de la base de datos se describe a través de dos tipos de esquemas:


- 113 -

class Documento de Diseño de la Base de Datos

«doc. técnico»Diseño de la Base de

Datos

«modelo»Esquema Relacional

Lógico

«modelo»Esquema Físico

«doc. técnico»Restrcciones explicitas

«doc. técnico»Diccionario de Datos

«código»Scripts de Creación

«código»Scripts de Datos

Figura 4 - 15 Diseño de Base de Datos

1) Esquema Relacional Lógico

Es una descripción de la estructura lógica que tendrá la BD expresada en

términos del Modelo de Datos Relacional. Es independiente del DBMS que se

usará, pero depende del modelo de datos que este DBMS soporta.

Dicho diseño describe el conjunto de tablas que integrarán la BD, cada

uno de los elementos de las tablas (claves, atributos, dominios, restricciones,

etc.) y las relaciones entre tablas. En otras palabras describen los datos, sus

restricciones, las clases en que se componen y sus relaciones según los procesos

de negocios.

2) Esquema Físico

El diseño físico depende totalmente del DBMS que se usará para

implementar la BD. Describe como la BD se implantará en el DBMS. Su principal

elemento es el esquema físico que describe las estructuras de almacenamiento y


- 114 -

los métodos de acceso que se utilizarán para acceder a los datos contenidos en

las tablas de la BD.

Aplicación Empresarial



Proceso que lo genera: Codificación e Integración del Incremento j.

Es el producto final y el objetivo real del proyecto. Su construcción está en

manos del equipo de desarrollo y se realiza durante la ejecución de los distintos

procesos técnicos que se realizan durante el ciclo de la Versión y del Incremento.

Comprende los siguientes entregables:

Aplicación WEB: la solución con la que interactuará el usuario final, compuesta

por un conjunto de programas o aplicaciones, y representada a través de código,

por los componentes de Interfaz WEB, de Lógica de Negocios y de Persistencia.

Repositorio de Base de Datos: representa la persistencia de datos de la

aplicación, abarca el esquema físico de la BD y el repositorio como tal.

Manuales: documentos de soporte al usuario que permiten comprender la

manera en que se presenta la solución. Se desglosan en:

o Manual de Instalación: Contiene las especificaciones técnicas necesarias

para la puesta en marcha de la aplicación está compuesto por el

documento de despliegue.

o Manual de Uso de la aplicación: está dirigido a los usuarios y contiene la

descripción, de cada una de las funcionalidades incluidas en la aplicación,

sus módulos, la manera en cómo se accede y la interacción que tendrá el

usuario para obtener las respuestas deseadas por parte de la aplicación.


- 115 -

composite structure Aplicación Empresarial

«código»Aplicación Web


«repositorio»Base de Datos

«doc. técnico»Manual de Instalación

«doc. técnico»Manual de Uso

«código»Componente de Interfaz

Web

«código»Componente de Lógica de

Negocios

«código»Componente de

Persistencia

«doc. técnico»Documento de Despliegue

Figura 4 - 16 Aplicación Empresarial

Documento de Despliegue



Proceso que lo genera: Entrega del Incremento j.

Contiene las especificaciones técnicas necesarias para el despliegue de la

aplicación, así como los pasos que se deben seguir para lograrlo.

El Líder de Desarrollo es el responsable de realizar o de coordinar la realización

de este documento que está dirigido a la persona encargada de realizar el despliegue;

Esta persona puede no contar con conocimientos técnicos y, en ese caso, su contenido

debe estar expresado de manera sencilla y detallada para facilitar la instalación exitosa

de la aplicación.


- 116 -

Programa de Pruebas


Responsable principal: Equipo de Desarrollo y Especialistas de Pruebas.

Proceso que lo genera: Codificación e Integración del Incremento j.

Comprende el código de las pruebas realizadas a la aplicación, esto incluye los

scripts de pruebas, los scripts de datos, conductores de las pruebas, el código de las

pruebas unitarias y todo el resto del código necesario para su ejecución. Estos

Programas de Pruebas son escritos por los Programadores y por los Especialistas de

Pruebas durante el proceso de Codificación e Integración del Incremento.

Resumen

El presente capitulo es la descripción de los productos que se generan al hacer

uso del método Blue WATCH para el desarrollo de una aplicación Web. Más adelante, en

los capítulos 6 y 7, se describe cada uno de los procesos del método, así como, los

actores que llevan a cabo estos procesos. Esto nos da el contexto completo del ciclo de

vida del método Blue WATCH, donde la ejecución, por parte de los actores del método,

de cada uno de los procesos da como resultado la construcción los productos aquí

descritos para la consecución del producto final que es la construcción de una aplicación

Web.


- 117 -

CAPITULO 5

EL MODELO DE ACTORES

El modelo de actores es la representación de los participantes de un proyecto de

software junto con los roles y responsabilidades que ellos deben asumir.

Los actores del Blue WATCH se dividen en 3 tipos, los actores de gestión, los

actores de soporte y los actores técnicos. Cada uno de ellos ejecuta los procesos

correspondientes para cada categoría.

Estos tres tipos de actores cubren los distintos roles que deben desempeñarse

para que se lleve a cabo el ciclo de vida del desarrollo de software, donde es necesaria

la participación de un conjunto de personas con conocimientos en distintas

especialidades que lleven a cabo las diferentes actividades relacionadas con las áreas o

departamentos interesados en llevar a cabo el proyecto.


Los objetivos de este modelo se enumeran a continuación:

Identificar los interesados del proyecto (stakeholders).

Establecer los roles que típicamente deben se desempeñarse en

proyectos de esta naturaleza

Identificar las responsabilidades de cada rol.

Establecer la organización general del equipo de desarrollo que permita

ser adaptable según las circunstancias.

Identificar los Actores Esenciales, Recomendables y Opcionales que debe

tener el equipo de trabajo.


- 118 -

Identificar los roles que pueden ser desempeñados por la misma persona

a la vez y el solapamiento entre las actividades que debe ejecutar.

Identificar los procesos en los cuales participa cada actor y los productos

de los cuales es responsable.

Componentes del modelo de actores

Al igual que Gray WATCH (Montilva, Barrios, & Rivero, 2008) El Modelo de

Actores en Blue tiene tres componentes relacionados:

La Clasificación de Interesados que identifica a los tipos de los actores que están

relacionados con el desarrollo de aplicaciones empresariales.

El Modelo de la Estructura Organizacional de referencia que sirve de modelo

para la organización de los equipos de desarrollo de aplicaciones y

Los Roles y Responsabilidades que describen las funciones y tareas que deben

ejecutar los actores que participan en proyectos de desarrollo de aplicaciones.

Clasificación de Interesado del Blue WATCH

El equipo de desarrollo debe estar conformado por una combinación de actores

que desempeñen roles que cubran todos los aspectos relacionados con la ejecución de

un proyecto de desarrollo de una aplicación Web. La combinación ideal para cada

proyecto debe establecerse tomando en cuenta las características del mismo que

incluye, las limitaciones actuales de recursos, los aspectos ambientales, externos entre

otros.

Blue WATCH, identifica tres tipos principales de actores que participan en el

desarrollo del proyecto Cliente-Promotor, Usuario y Desarrollador. La tipificación de


- 119 -

roles que desempeñan estos actores se desprende del meta-modelo explicado en el

capitulo anterior, y se encuentra representado en la Figura 5 - 1.

class Metamodelo de Actores

«actor»Equipo de Desarrollo

«actor»Actor

«actor»Rol

«actor»Responsabilidad


«actor,rol»Representante de

Usuarios{1..*}


«actor,rol»Usuario

«actor»Comite Directiv o del

Proyecto

«actor»Equipo del Proyecto

1

1..*

1

+ejerce

1..*

+ejercido_por

0..*

+tiene_asignado

1..*

1..*

1..*

Figura 5 - 1 Clasificación de los roles para actores del Blue WATCH

Representante de Usuarios: Es un usuario o interesado quien tiene

conocimientos detallados sobre el área o el negocio para la cual se desarrolla la

aplicación, o en su defecto es el que gestiona con los expertos del área para aclarar los

requisitos al equipo de desarrollo. Además, es el encargado de validar y aprobar el

producto durante las distintas fases del proceso.

Equipo de Desarrollo: Los miembros del equipo del proyecto que se encargarán

de la ejecución del proyecto, las actividades técnicas y la realización del producto.


- 120 -

Comité Directivo del Proyecto: Los miembros del equipo del cliente que se

encargarán de aprobar la contratación, validar la aplicación Web y la aprobación final de

la aplicación. Además, todo lo concerniente al proyecto, tanto administrativamente

como conceptualmente.

Equipo del Proyecto: Agrupa los equipos de desarrollo y el Comité Directivo del

Proyecto. Conforma todos los actores que juegan algún rol durante el ciclo de desarrollo

de la aplicación Web.

Modelo de la Estructura Organizacional del Equipo de Desarrollo

La estructura del equipo de desarrollo representa la asignación de las personas a

sus roles y responsabilidades, se identifican en este modelo los actores esenciales que

requiere un proyecto para poder ser ejecutado, los actores recomendables que serán de

mucha ayuda para alcanzar el éxito del proyecto y los actores opcionales de los cuales

pudiese prescindirse si las limitaciones o las características del proyecto lo ameritan.

En el modelo se refleja, además, otra categorización que depende del tipo de

decisiones y líneas de comunicación que los actores ejercen. Los actores estratégicos

quienes toman decisiones fundamentales que marcan el rumbo del proyecto, más que

todo relacionadas con los requisitos funcionales y no funcionales de la aplicación, la

planificación y la coordinación de actividades. Luego, las decisiones de análisis y diseño

son tomadas por un subconjunto de actores técnicos y de soporte, quienes plantean los

pilares fundamentales a nivel técnico del producto, arquitectura del producto,

estándares de calidad e instanciación del método. Finalmente, las decisiones técnicas de

implementación que son tomadas por otro subconjunto de actores quienes son los que

en definitiva construyen la aplicación empresarial.

Estas líneas de comunicación describen las líneas de autoridad dentro del

proyecto, los actores de implementación rinden cuenta a los actores de análisis y estos a

su vez a los actores de gestión.


- 121 -

composite structure Modelo de Actores

Actores de Implementación

Actores de Análisis y DiseñoActores Estrategicos

«actor,rol»Especialista en Pruebas

«actor,rol»Líder del Proyecto

«actor,rol»Programador

{1..*}

«actor,rol»Analista


«actor»Actor

«actor»Actor de Gestión

«actor»Actor de Soporte

«actor»Actor Técnico

«actor,rol»Especialista de Calidad

«actor,rol»Representante de Usuarios

{1..*}

«actor,rol»Diseñador Web

«actor,rol»Líder de Desarrollo

«actor,rol»Arquitecto Diseñador

Figura 5 - 2 Modelo de Actores del Blue WATCH

La configuración o modelo propuesto como equipo de desarrollo para Blue

WACTH es bastante sencilla. Seis roles son esenciales, dos de parte del cliente que son

el Cliente-Promotor el cual aprobará el desarrollo del proyecto y gestionará los recursos

necesarios para ejecutarlo y el (los) Representante(s) de Usuarios, quien(es) debe(n)

tener conocimiento suficiente para aclarar al equipo de desarrollo cómo funciona el

negocio para el cual se está desarrollando la aplicación.


- 122 -

Luego en el equipo de desarrollo son fundamentales el Líder de Desarrollo, los

Programadores, el Diseñador Web y el Especialista en Pruebas

Se recomienda contar en el equipo con un Líder de Proyecto, un Analista, un

Arquitecto Diseñador y un Especialista en Calidad, pero si el proyecto es relativamente

sencillo y pequeño estos actores pueden no ser necesarios ya que los procesos que sean

necesarios llevar a cabo, relacionados con estos roles, pueden ser asumidos por otro de

los integrantes del equipo.

Es importante notar, además, que varios roles de los aquí descritos pueden ser

ejecutados por una misma persona, por lo que, el numero de roles no define el número

de personas que participan en el proyecto. Más delante se detallaran cuales roles

pueden ser ejecutados por la misma persona.

Como se puede observar en la Figura 5 - 2, los actores se caracterizan por el tipo

de procesos que ejecutan en actores de gestión, de soporte y técnicos.

Los actores de gestión se dedican a las actividades estratégicas del proyecto,

toman decisiones gerenciales y marcan el rumbo que debe seguir el equipo de

desarrollo, estos actores no participan en la construcción de la solución como tal.

Los actores de soporte realizan actividades que son necesarias si se desea

desarrollar un producto de alta calidad ya que se hacen cargo principalmente de los

procesos para asegurar las características requeridas del producto.

Por último, los actores técnicos son los que como tal diseñan y construyen el

producto siguiendo los parámetros establecidos por los actores de gestión y de soporte.

Esta sencilla y flexible estructura permite contar con un equipo versátil que

ejecuta los procesos esenciales del ciclo de desarrollo de un proyecto de software, la

definición de la estructura del equipo debe estar acorde a los procesos que se hayan


- 123 -

seleccionado ejecutar y los productos que se hayan decidido generar cuando se

instancia el método Blue WATCH, de manera de evitar la sobrecarga de trabajo.

La decisión final de cómo estará conformado el equipo de desarrollo se debe

tomar al principio del proyecto cuando se esté instanciando el método, los factores que

influirán para tomar esta decisión se basan en aspectos tales como el tamaño y

complejidad del proyecto, así como el presupuesto asignado al mismo y las necesidades

de documentación exigida por el cliente.

Se debe tomar en cuenta cuando se conforme el equipo de desarrollo que un

actor puede asumir uno o más roles siempre y cuando no exista solapamiento entre las

funciones asignadas, la figura siguiente (Figura 5 - 3) muestra cuales roles pueden ser

ejecutados por un mismo actor.

Figura 5 - 3 Tabla de solapamiento de funciones Rol vs Rol


- 124 -

Ejemplos de estructura organizativa

A continuación, se muestran dos modelos organizativos del equipo de desarrollo

producto de instanciar el modelo de actores representado en la Figura 5 - 2.

analysis Estructura Organizativa completa del Blue WATCH

Equipo del Proyecto

Cliente

Comite Directivo

Equipo de Desarrollo



Usuarios{1..*}









{1..*}

Figura 5 - 4 Estructura Organizativa completa del Blue WATCH

La estructura organizativa representada en la Figura 5 - 4 representa la

instanciación completa del Modelo de Actores y es necesaria la participación de

aproximadamente 10 personas donde uno o más ejerzan el rol de Programador. En este

caso de ejemplo, los procesos del Blue WATCH pueden ser ejecutados plenamente,

aunque tal vez sea necesario que un actor asuma más de un rol.


- 125 -

class Estructura Organizativ a Minima

Equipo del Proyecto

Cliente

Comite Directivo

Equipo de Desarrol lo



Usuarios{1..*}





{1..*}

Figura 5 - 5 Estructura Organizativa mínima del Blue WATCH

La estructura organizativa de la Figura 5 - 5 representa una instanciación mínima

del Modelo de Actores donde es necesaria la participación al menos 3 personas y donde

los actores en ocasiones deberán asumir funciones de otros roles. En el caso específico

del ejemplo, Un programador o el Líder de Desarrollo podrían ejercer el rol del

Diseñador Web. Además, el Líder de Desarrollo necesitaría ejercer algunas funciones del

rol de Líder de Proyecto (como la planificación), pero la ejecución de procesos

relacionados con los actores que no se reflejen en la estructura organizativa debería ser

mínima.

Descripción de roles y responsabilidades del equipo de Desarrollo

La Figura 5 - 6 muestra la representación grafica de los roles identificados para el

equipo de desarrollo en Blue WATCH. Seguidamente, se detallan cada uno de estos

roles, identificando sus responsabilidades y la manera en que participan durante el

desarrollo del proyecto.


- 126 -

class Desarrollador




{1..*}


«actor,rol»Especialista en

Pruebas

«actor,rol»Especialista de

Calidad




Figura 5 - 6 Roles del Equipo de Desarrollo

Líder del Proyecto

Es el responsable de la ejecución de los procesos de gestión, le rinde cuentas al

Cliente-Promotor. Participa en el levantamiento de necesidades y requisitos del sistema.

Colabora en la definición de los Objetivos del Negocio.

Colabora en la definición de los Requisitos de la Aplicación.

Gestionar los requisitos junto con el Analista.

Evalúa los riesgos relacionados con la ejecución del proyecto.

Elaborar el Plan del Proyecto

Gestiona los riesgos del proyecto.

Dirige la ejecución del Plan del Proyecto.

Hace seguimiento y control de las actividades del proyecto.

Reportar al Cliente-Promotor el progreso del proyecto.

Cierra administrativa y técnicamente el proyecto.

Es responsable directo de los siguientes productos:


- 127 -

Visión del Negocio.

Plan de Proyecto.

Cronograma del Proyecto.

Informes de Avance.

Matriz de Riesgos.

Matriz de Requisitos.

Realiza, colabora en la realización o aprueba de los siguientes productos:

Especificaciones Funcionales

Líder de Desarrollo

Es responsable de las actividades técnicas del proyecto, colabora en la definición

de las necesidades técnicas, diseño y arquitectura inicial. El Líder de Desarrollo asume

algunas responsabilidades gerenciales convirtiéndose en los ojos y oídos del Líder de

Proyecto para los aspectos técnicos de la aplicación. Así mismo, es responsable de

ejecutar las actividades de gestión de la configuración del software, que incluyen:

identificación de la configuración, supervisión y control de la gestión de la configuración

del software y gestión y entrega de versiones. Controla los productos que se generan

durante el desarrollo de la aplicación

Colabora en la gestión de los Requisitos de la Aplicación.

Responsable de la Calidad Técnica del producto.

Colabora en la definición de los riesgos relacionados con la ejecución del

proyecto.

Colabora en los estimados de desarrollo de las funcionalidades.


- 128 -

Colabora en la definición de responsables de las actividades técnicas del

proyecto.

Dirige las actividades del equipo de desarrollo.

Reporta al Líder de Proyecto el progreso del desarrollo del proyecto.

Sirve de enlace entre los usuarios y el Equipo de Desarrollo.

Sirve de enlace entre el Líder de Proyecto y el Equipo de Desarrollo.

Despliega o supervisa el despliegue de la aplicación en la plataforma en el

ambiente del cliente.

Gestionar las versiones e incrementos de la aplicación a través de los

repositorios y sistemas de control de versiones.


Aplicación (Código).

Revisión de calidad del producto.

Documento de Configuración.

Documento de Despliegue.


Cronograma del Proyecto.

Matriz de Riesgos.


Documentos de CU.

Diseño Detallado.

Diseño de la BD


- 129 -

Analista

Responsable del levantamiento de necesidades y requisitos del sistema y de la

comunicación con los responsables del proyecto. Es responsable directo de:

Descubrir, analizar, especificar y documentar los Objetivos del Negocio.

Modelar el dominio de la aplicación empresarial.

Descubrir, analizar, especificar y documentar los requisitos de la aplicación.

Gestionar los requisitos junto con el Líder de Proyecto

Servir de enlace entre los representantes de usuario y el equipo de

desarrollo.

Asegurar que los productos del desarrollo de la aplicación estén alineados al

sistema de negocios que actúa como dominio de la aplicación.

Validar, en conjunto con los usuarios, los requisitos establecidos.

Colaborar en la realización o aprobación de los CU.


proyecto.


Modelo de Negocio.

Especificaciones Funcionales.

Matriz de Requisitos (Junto con el Líder de Proyecto)


Visión del Negocio.

Documento de CU.


- 130 -

Diseño de la IW (Interfaz Web)

Matriz de Riesgos.

Documentos de CU.

Arquitecto Diseñador

Responsable del Diseño Arquitectónico y de la realización o aprobación del

Diseño Detallado de la aplicación se encarga de:

Asegurar que la solución a implementar este alineada al sistema de negocios

que actúa como dominio de la aplicación.

Identificar las metas y requisitos arquitectónicos del sistema.

Realizar modelos de diseños arquitectónicos a un alto nivel de abstracción

(diseño conceptual).

Seleccionar la arquitectura más adecuada para la aplicación que cumpla con

las metas y requisitos arquitectónicos establecidos.

Diseñar y evaluar la arquitectura de la aplicación.

Especificar cada una de las vistas arquitectónicas.

Diseñar las Bases de Datos y los Componentes de Software de la aplicación.

Colabora en la evaluación los productos técnicos a través de revisiones de

software del producto.


proyecto.

Prestar asistencia técnica a los miembros del equipo de desarrollo en la fase

de construcción



- 131 -

Documento de Arquitectura.

Diseño de la BD.


Diseño de la IW (Interfaz Web)

Matriz de Riesgos.

Documentos de CU.

Diseño Detallado.

Revisión de calidad del producto

Programador

Sobre este rol recae la responsabilidad de codificar y/o adaptar los diferentes

componentes que integran la aplicación. Más específicamente, el programador debe:

Codificar, documentar y probar los componentes de software de la

aplicación.

Codificar y ejecutar las pruebas unitarias de cada funcionalidad

Corregir los errores encontrados durante las pruebas funcionales;

Integrar los incrementos y versiones de la aplicación

Elaborar los manuales de instalación, uso y mantenimiento.

Crear la base de datos de la aplicación junto con sus datos iníciales.

Colaborar con el Diseño de la IW.


Aplicación (Código).


- 132 -

Documentos de CU.

Diseño Detallado.

Revisión de código.

Especificación de Pruebas Unitarias.

Colabora en la realización de los siguientes productos:

Matriz de Riesgos.


Diseño de la BD

Documento de Despliegue

Diseño de la IW

Diseñador Web

El diseñador Web es un programador experto en la codificación de la parte visual

o interfaz con el usuario o en su defecto un diseñador grafico con conocimientos Web,

sobre él recae la responsabilidad de codificar y/o adaptar los diferentes componentes

relacionados a la Interfaz Web IW de la aplicación. El diseñador Web es responsable de:

Diseñar los detalles de la Interfaz IW,

Codificar, documentar y probar los componentes de la IW software de la

aplicación.

Generar Plantillas para los distintos elementos de la IW

Generar la hoja de estilos a ser aplicada a la IW



- 133 -

Diseño de la IW.

Hoja de estilos

Plantillas de la IW

Especialista en Pruebas

Es responsable de las actividades de pruebas de la aplicación empresarial

Realización de las actividades de diseño y ejecución de las pruebas

funcionales.

Colabora con el Grupo de Desarrollo en el diseño de las pruebas de unitarias

Colaborar en la elaboración del Plan de Pruebas junto con el Especialista de

Calidad y el Líder del Proyecto.


Documento de Especificación de Pruebas

Documento de Resultados de las Pruebas

Reporte de Pruebas


Pruebas Unitarias

Especialista de Calidad

Es responsable de la establecer los estándares de análisis de calidad

Capacitación del personal en los procesos de desarrollo,


- 134 -

Seguimiento del plan de calidad,

Definir las actividades de aseguramiento de la calidad

Evaluar los procesos de revisiones y auditorias de los productos, de los

procesos de desarrollo y de los procesos de soporte.

Organización y dirección de las auditorias.

Prepara los reportes de auditoría con los informes de cumplimientos y no

cumplimientos,

Verificar los productos de cada proceso del desarrollo.

Definir los estándares y procedimientos de aseguramiento de la calidad del

software

Asegurar la calidad del proceso de desarrollo de software ejecutado por el

equipo de desarrollo

Velar que los grupos empleen apropiadamente los procedimientos y,

particularmente, el proceso de desarrollo de aplicaciones instanciado a partir

del Método Blue WATCH


Definir el proceso de desarrollo a partir de la instanciación del Método esto

incluye:

- Definir el equipo de desarrollos (Roles que se deben ejecutar)

- Definir los productos que se deben realizar.

- Definir los procesos que se deben ejecutar.

Revisión del Proceso.


Documento de Especificación de Pruebas


- 135 -

Documento de Resultados de las Pruebas

Resumen

En este capítulo se llevo a cabo una descripción de los actores que deben

participar en un proyecto de desarrollo al utilizar el método Blue WATCH. De igual

manera, se identifican los roles y responsabilidades de cada uno de ellos y la estructura

organizativa que determina la jerarquía y distribución del grupo de desarrollo. Para cada

rol se identifican los productos de los cuales son responsables, o en los cuales tienen

algún tipo de participación, ya sea de verificación, validación o como entrada para

realizar el trabajo requerido. Los actores acá descritos son los que llevan a cabo los

procesos del método, los cuales serán descritos en los capítulos 6 y 7.

El ciclo de vida del desarrollo que comprende la ejecución de los procesos del

método, marcará la pauta para establecer en qué momento los actores participantes

deben generar los productos descritos en el capítulo 4.


- 136 -

CAPITULO 6

EL MODELO DE PROCESOS

El modelo de procesos del Blue WATCH es la descripción y representación gráfica

de los procesos y flujos de actividades que se deben llevar a cabo para desarrollar un

proyecto de Aplicación Web empleando este método.

En esta versión del WATCH, los procesos se adaptan para permitir una mayor

agilidad necesaria en proyectos ejecutados por equipos de pocos participantes, la idea

no es simplificar los procesos del WATCH si no adecuar el método y definir actividades

que permitan alcanzar esta agilidad. Adicionalmente, se incluyen actividades o procesos

que reflejen las particularidades en el desarrollo de aplicaciones Web.

En este capítulo se describe el modelo de procesos del método Blue WATCH, se

explica la metáfora en la cual está fundamentado el modelo, su estructura y cada uno de

sus componentes. Adicionalmente, se muestran los conceptos fundamentales para la

comprensión del modelo y la notación empleada para describir sus procesos.


Los objetivos de este modelo se enumeran a continuación:

Identificar los procesos que intervienen en el ciclo de desarrollo de una

aplicación Web.

Establecer las relaciones y grados de dependencia entre los procesos del

método.

Definir los productos de entrada y de salida como consecuencia de la ejecución

de un proceso dado.


- 137 -

Metáfora del Reloj

El orden en que los procesos del método se ejecutan está inspirado en la

metáfora del reloj basada en el método Gray WATCH (Montilva, Barrios, & Rivero,

2008) donde se explica de la siguiente manera:

“El proceso de desarrollo de software es visto como un reloj, cuyo motor son los

procesos de gestión y soporte y cuyos diales constituyen los procesos técnicos.”

Para ser más específicos, los procesos medulares o técnicos giran en torno a los

procesos de soporte y de gestión quienes dan el apoyo necesario para no perder de

vista los aspectos importantes durante la ejecución del proyecto como son, la calidad, el

cumplimiento de los objetivos, las fechas de entrega, la completitud del producto entre

otros; todos orientados a lograr la satisfacción del cliente.

Una diferencia clara del Blue WATCH es que se establecen tres ciclos dentro del

flujo de ejecución de los procesos. Estos ciclos permiten agregar mayor flexibilidad y

claridad para entender los aspectos de iterativo e incremental durante la ejecución del

método, la idea es plasmar niveles de detalle para cada uno de los productos durante

cada uno de estos ciclos que lo que representa es el grado de avance del proceso.

Los procesos del primer ciclo del método se enfocan en describir con detalle de

alto nivel las características del proyecto y la organización que lo requiere, se le

denomina Ciclo de la Aplicación y los productos generados durante este ciclo son en su

mayoría de interés gerencial (estratégico) y de análisis del problema junto con una

propuesta de la solución. La Figura 6 - 1 nos muestra los procesos que se deben ejecutar

durante este ciclo, los productos relacionados con este ciclo son entonces: Visión del

Proyecto, Plan de Proyecto, Modelo de Negocio, Matriz de Requisitos y Diseño

Arquitectónico.


- 138 -

class Metáfora del Reloj (Blue WATCH)

Procesos Transversales

Modelado delNegocio

Desarrollo deRequisitos

DiseñoArquitectonico

Desarrollo deVersiones

Procesos deGestión

Inicio

Procesos deSoporte

Figura 6 - 1 Ciclo de la Aplicación

Dentro del Ciclo de la Aplicación se realiza el proceso de Desarrollo de Versiones

que son ciclos internos que se ejecutan una o más veces según sea necesario y permiten

la construcción de versiones funcionales del producto final que es la Aplicación

Empresarial Web. Estos ciclos, denominados Ciclo de la Versión, pretenden establecer

ya de manera más específica la solución propuesta con mayor nivel de detalle en cuanto

al diseño de la aplicación para la versión específica. También, se refinan y actualizan los

productos generados durante la etapa anterior, como por ejemplo el plan de proyecto el

cual contendrá estimaciones más precisas y actividades mejor especificadas. Se realiza

el desarrollo de incrementos hasta completar todas las piezas de la versión y,

finalmente, se obtiene el producto y se realiza la entrega de la Versión i que es una

parte funcional de la aplicación que puede ya ser utilizada por los usuarios mientras se

realizan las siguientes versiones. Se puede observar, en la Figura 6 - 2, los procesos que

se llevan a cabo en cada uno de los ciclos de la versión, los productos que se generan


- 139 -

durante esta fase son: Prototipo de Interfaz Web, Diseño de la Base de Datos,

Especificación de los CU, Versión de la Aplicación Web.

dm Método WATCH Versión


Procesos de Gestión

Revis ión de losProductos del

Proceso

Diseño Detallado dela Versión i

Desarrollo deIncrementos de la

Versión i

Entrega de la Versión i

Procesos de Soporte

InicioCiclo

Figura 6 - 2 Ciclo de la Versión

Así como el ciclo principal está compuesto de ciclos internos (donde se

desarrollan las versiones), el Ciclo de la Versión se encuentra a su vez compuesto por la

ejecución de otra serie de ciclos iterativos internos denominados Ciclo del Incremento.

Es durante la ejecución de este Ciclo donde se refina el diseño y finalmente se

construye, por partes, la Aplicación Web a partir de la especificación y diseño detallado

de cada uno de los Casos de Uso identificados. Cada uno de los incrementos generados

son porciones de funcionalidad que conforman la versión, que aún cuando pueden ser

ejecutados, no definen una pieza completa que puede ser utilizada por el usuario. El

objetivo de realizar estas iteraciones es ir mostrando al cliente el producto que se ha

construido hasta el momento. Realizar esto en varias iteraciones incrementales permite


- 140 -

validar el avance que se tiene para obtener la retroalimentación u observaciones

pertinentes y de esta manera identificar a tiempo posibles desviaciones de lo diseñado

con la solución que se está construyendo. Otro objetivo de realizar incrementos es

permitir trabajar con subconjuntos más pequeños y, por lo tanto más manejables, de la

aplicación de manera de enfocar el diseño y la implementación a conjuntos

funcionalidades estrechamente relacionados. Finalmente, observamos en la, Figura 6 -

3, los procesos relacionados con cada uno de los ciclos del incremento. Durante la

ejecución de cada iteración se producen para cada uno de los Casos de Uso que

componen el incremento: Documentos de los Casos de Uso, Diseño Estructural y

Dinámico, Diseño de Pruebas, Codificación los Casos de Uso, Codificación de las

Pruebas, Incremento de la Versión de la Aplicación Web.

class Método WATCH Incremento


Pruebas delIncremento j


Diseño Detallado delIncremento j

Codificación eIntegración delIncremento j

Entrega delIncremento j

Procesos de Soporte

InicioCiclo

Refinamiento de losproductos de la

iteración j-1

Figura 6 - 3 Ciclo del Incremento


- 141 -

Esta visión general del método se puede apreciar que la estructura del mismo

expresada a través de una serie de ciclos internos iterativos e incrementales son los que

aportan al método la agilidad buscada sin perder de vista elementos importantes como

son la calidad del producto y la buena gestión de los recursos y procesos que permitan

cumplir con los ofrecido al cliente.

Relaciones entre los procesos

Los procesos del Blue WATCH están definidos de manera tal que puedan

identificarse las prelaciones sugeridas en la ejecución de los procesos. Los procesos de

gestión y de soporte son transversales y se ejecutan a través del ciclo de vida del

proyecto, mientras que los procesos técnicos son medulares y su ejecución corresponde

al estado de definición o detalle de la especificación o construcción de cada parte de la

aplicación.

Sin embargo, por ser un método iterativo e incremental algunos procesos al ser

alimentados por la información del proceso anterior puede resultar en la necesidad de

“re-especificar” lo expresado en el proceso que lo precede. De hecho algunos procesos

se consideran que pueden ser ejecutados en paralelo. Durante la explicación del ciclo de

vida del método se definirá más en detalle las prelaciones y dependencias entre cada

uno.

Componentes del Modelo de Procesos

El método Blue WATCH está conformado por una serie de procesos clasificados

según su objetivo como, procesos de gestión, de soporte y técnicos.

Los procesos de gestión ayudan a coordinar todos los elementos que confluyen

durante la ejecución del proyecto, son necesarios para conservar el orden y para

recordar el norte de lo que se está construyendo.


- 142 -

Los procesos de soporte se deben ejecutar para asegurar la construcción de la

aplicación bajo ciertos parámetros de calidad y completitud.

Los procesos técnicos o medulares se orientan a la construcción de la solución

en sí. Son los más importantes ya, que conllevan a la obtención producto final que es el

que en realidad aporta valor a la persona que contrató el proyecto.

Procesos del Método Blue WATCH

Los ciclos expresados con la metáfora del reloj pueden ser visualizados como una

cadena de valor de procesos, en esta vista es más fácil apreciar la naturaleza transversal

de los procesos de soporte y gestión a través de todo el ciclo de vida del desarrollo,

como se aprecia en la Figura 6 - 4, Figura 6 - 5 y Figura 6 - 6, que corresponden al Ciclo

de la Aplicación, Ciclo de la Versión y Ciclo del incremento, respectivamente.

Los procesos expresados en la primera fila son los procesos medulares o técnicos

que en buena manera se ejecutan de forma secuenciales salvo algunas excepciones, los

procesos de la segunda fila reflejan los procesos de gestión y, por último, los procesos

de la fila inferior son los procesos de soporte. En ambos se detallan cuales sub procesos

se aplican a cada uno de los ciclos.


- 143 -

analysis Cadena de v alor WATCH

Procesos de Soporte

Gestión del Proyecto

Modelado delNegocio

Desarrollo deRequisitos

DiseñoArquitectonico

Desarrollo deVersiones

Planificación de laAplicación

Inicio del Proyecto

Planificación deaseguramiento de la

Calidad

Identificación yAnálisis de los

Riesgos

Figura 6 - 4 Cadena de Valor

analysis Jerarquía de procesos DV

Procesos de Soporte

Diseño Detallado dela Versión i

Desarrollo deIncrementos de la

Versión i

Entrega de laVersión i


Planificación deVersión

Control del Proyecto

Gestión de la Calidad

Revisión de losProductos del

Proceso

Cierre del la Fase

Gestión de laConfiguración

Figura 6 - 5 Ciclo de la Versión


- 144 -

analysis Jerarquía de procesos DI

Procesos de Soporte

Diseño Detallado delIncremento j

Codificación eIntegración del

Incremento j

Entrega delIncremento j

Pruebas delIncremento j


Planificación deIncremento

Seguimiento del Proyecto

Monitoreo de la Calidad

Dirección del Proyecto

Identificación y Análisisde los Riesgos

Refinamiento de losproductos de la

iteración j-1

Gestión de laConfiguración

Figura 6 - 6 Ciclo del Incremento


La Gestión del Proyecto en Blue WATCH comprende el conjunto de procesos que

se llevan a cabo para asegurar la ejecución exitosa del proyecto de desarrollo en el

tiempo estimado; los procesos de gestión comprenden la planificación y monitoreo de la

ejecución del resto de los procesos técnicos y de soporte con el objetivo de identificar a

tiempo posibles desviaciones de lo establecido en la planificación inicial y tomar las

acciones correctivas en el tiempo justo.

Estas actividades se realizan buscando garantizar que la aplicación desarrollada

satisfaga las necesidades del cliente, es decir, que la aplicación se entregue en el tiempo

requerido y con los estándares de calidad adecuados.

Los procesos de gestión se ejecutan a lo largo de la duración del proyecto y en

Blue WATCH se adaptan para que puedan ser ejecutados por equipos de desarrollo

pequeños. En este caso, la comunicación y la alineación son elementos claves para una


- 145 -

gestión exitosa, permitiendo que exista la formalidad, pero evitando altos niveles de

protocolo y burocracia.

Durante la ejecución de un proyecto de software los aspectos que se gestionan

son los siguientes:

En primer lugar el Equipo de Desarrollo, es decir, aquellas personas que son las

que realizarán las actividades del proyecto y que necesita un alto grado de

comunicación y de coordinación. Se refiere específicamente a los actores que están

reflejados en el modelo de actores.

Luego tenemos el producto, aquello que se va a generar. Debe existir un

conocimiento o noción bastante clara de lo que se desea construir, un proyecto cuyos

objetivos no están claros está ciertamente condenado al fracaso. Algunos aspectos del

producto pueden variar, como el alcance y los requisitos, pero si los objetivos no están

claros ningún tipo de gestión puede ser lograda.

Luego, se debe gestionar el proceso, lo que nos permite definir cómo llevar a

cabo el proyecto, las actividades a ejecutar y las competencias necesarias para lograrlo.

Por último, se gestiona el proyecto, que es la sumatoria de los anteriores,

dirigiendo y adaptando durante todo el ciclo las actividades a ejecutar.

De estos aspectos a gestionar, el primero, las personas, es altamente

impredecible y es afectado por los acontecimientos ocurridos durante el proyecto. Por

esta razón, la gestión de un proyecto de software requiere competencias a nivel de

liderazgo, para lograr cuatro aspectos fundamentales que son de peso a la hora de

aumentar las posibilidades de éxito de un proyecto:

Motivación, coordinación, resolución de conflictos y comunicación.


- 146 -

Pero no es suficiente que el Líder de Proyecto tenga competencias de liderazgo,

también, se recomienda que tenga competencias en el resto de los aspectos

significativos de un proyecto de software, como, por ejemplo, los aspectos técnicos, de

manera que pueda comprender las situaciones que se presenten y tomar las decisiones

apropiadas para generar un planes de acción y afrontar con éxito las situaciones que se

presenten. Un buen Líder de Proyecto se involucra en el proceso completo y tiene

niveles de conocimiento y comprensión del producto que se está construyendo.

El PMBOK (PMI, 2000) resume todo lo descrito de la siguiente manera: "La

gestión de proyectos es la aplicación de los conocimientos, habilidades, herramientas y

técnicas a las actividades del un proyecto con el fin de satisfacer y superar las

expectativas y necesidades de los interesados y de un proyecto."

Entre las actividades más importantes de este proceso se encuentra la

planificación del proyecto y la organización del equipo de actores que desarrollará la

aplicación empresarial. Así mismo, e incluye la dirección y control de las actividades que

ejecuta este equipo de desarrollo y el cierre del proyecto

La jerarquía de procesos en la gestión de proyecto se puede ver en detalle en la

Figura 6 - 7 y son las siguientes:

- Inicio del Proyecto.

- Planificación del Proyecto.

- Dirección del Proyecto.

- Control del Proyecto

- Cierre del Proyecto

En Blue WATCH, la Gestión del proyecto se inicia con la elaboración del

documento de Visión del Proyecto durante el Ciclo de la Aplicación documento que,


- 147 -

generalmente, se realiza con gran acompañamiento del Promotor o Cliente, quien

conoce las necesidades y forma de trabajo de su organización. Si el inicio del proyecto es

autorizado, se designa formalmente al Líder del Equipo de Desarrollo, el Analista y el

Diseñador, quienes tienen la responsabilidad de ejecutar las actividades iníciales del

Proyecto, durante este ciclo de la aplicación, y quienes además asumen las

responsabilidades técnicas del mismo.

analysis Jerarquía de procesos GP


Dirección del Proyecto Control del ProyectoPlanificación del ProyectoInicio del Proyecto Cierre del la Fase

Figura 6 - 7 Proceso de Gestión del Proyecto

1. Proceso: Inicio del Proyecto

El paso inicial que se debe realizar para comenzar un proyecto de software, es

llegar a acuerdos y alcanzar consenso con los interesados del proyecto acerca de los

objetivos del mismo. Para ello es necesario, a través de discusiones entre las partes,

definir las necesidades de la organización y los requisitos a alto nivel para poder

establecer el alcance del proyecto.

Los interesados del proyecto de software deben aprobar principalmente 4

aspectos:


- 148 -

Los objetivos del proyecto

Las necesidades a satisfacer

El alcance del proyecto

Las limitaciones del proyecto

Con esto se determina la viabilidad del proyecto, que se inicia con una idea o

petición que puede venir desde el cliente o como una oportunidad de negocio

identificada por el equipo de desarrollo o finalmente de cualquier fuente que identifique

la necesidad. El objetivo final es justificar la inversión de tiempo y dinero en el proyecto

para conseguir la aprobación del proyecto y, así, poder comenzar a detallar los

requisitos, organizar el equipo de proyecto y realizar una planificación más detallada.

analysis Inicio del Proyecto

Inicio del Proyecto



Necesidades de la Organización

Contrato


Procesos y Reglas del Negocio

«objetivo»Obtener la Aprobación y

alcance del Proyecto


Usuarios{1..*}

«regla»Normas para la

Contratación


«colabora»

«apoya»

«controla»

«ejecuta»

«persigue»«regula»

«ejecuta»

Figura 6 - 8 Inicio del Proyecto


- 149 -

En el método Blue WATCH, el producto que se debe generar, como consecuencia

de los acuerdos alcanzados para establecer de estos aspectos, se reflejan en la Visión

del Producto y el respectivo contrato que de aquí se genere. El diagrama del proceso

Inicio del Proyecto se puede visualizar en la Figura 6 - 8. Las actividades que se deben

llevar a cabo para ello se muestran en la Figura 6 - 9.

Manteniendo la filosofía del método, donde se busca un balance entre disciplina

y agilidad, a este nivel se pretende definir lo suficiente y necesario para poder realizar

una planificación y realizar los estimados iniciales del proyecto. De esta manera, las

necesidades de la aplicación se detallan como requisitos a alto nivel de los cuales se

desprenden los requisitos específicos que se detallarán más adelante si el proyecto es

aprobado.

act Inicio del Proyecto

Proceso: Inicio del Proyecto

Inicio

Fin


IdentificarOportunidades de

Negocio

Realizar reunionesformales/informales

IdentificarNecesidades del

Negocio

EstablecerObjetivos del

Proyecto

Describir elProyecto

Establecer la listainicial de requisitos

(Alto Niv el)

Identificacion deInvolucrados

(stakeholders) yusuarios

Identificar laslimitaciones yrestricciones

Validación de laVisión del Producto

con el Cliente

Necesidades de la

Organización

Contrato

Figura 6 - 9 Inicio del Proyecto


- 150 -

2. Proceso: Planificación del Proyecto

La Planificación del Proyecto es un proceso iterativo y simplificado con respecto

a las versiones más disciplinadas del WATCH.

Este proceso es simplificado para aportar agilidad y, aunque involucra la

planificación de un conjunto amplio de parámetros relacionados con el alcance, las

actividades, los tiempos, los costos, el personal, los recursos, la calidad del producto,

configuración entre otros, el nivel de detalle de esta planificación es limitado durante las

etapas tempranas del proceso, pudiéndose extender cuando las necesidades del

proyecto lo ameriten. Es iterativo porque sus planes van evolucionando o

perfeccionándose en la medida que avanza el proyecto.

Es difícil reducir el proceso de desarrollo a una receta exacta a ejecutarse sin

variaciones, por eso el nivel de detalle de la planificación es útil para aportar flexibilidad

dentro del proceso, además por ser iterativo, el nivel de detalle se irá adaptando según

se necesite, durante este proceso de detallar la planificación se encuentran 3 fases

importantes:

- La planificación Inicial o planificación de la aplicación: los aspectos importantes que

se deben tomar en cuenta durante esta planificación son: alcance del proyecto,

estimados detallados de tiempo y de costos de las etapas iníciales (Análisis y Diseño

de la Arquitectura), identificación de los responsables de las etapas iníciales del

proyecto, identificación de los riesgos del proyecto, los estimados iníciales de

tiempo y de costos de las funcionalidades (holgados para mitigar el error en las

estimaciones).

- La planificación de la versión: Esta planificación es más detallada puesto que ya se

tiene un mejor conocimiento de los requisitos y casos de uso a desarrollar, esto


- 151 -

permite generar mejores estimados. Los aspectos importantes que se deben tomar

en cuenta durante esta planificación son: estimados de tiempo de las actividades de

diseño y desarrollo de los casos de uso que participan en la versión, coordinación y

responsables de las actividades a nivel de Versión, definición del número de

incrementos y sus componentes.

- La planificación del incremento: Esta planificación es detallada a nivel del

incremento y de los CU que se desarrollarán en ese momento. Los aspectos

importantes que se deben tomar en cuenta durante esta planificación son:

estimados de tiempo, coordinación y responsables de las actividades a nivel del

Incremento, planificación del diseño detallado, la codificación y las pruebas del

incremento.

Un aspecto importante de la planificación del proyecto es la instanciación del

método, es decir, la identificación de los procesos, actores y productos a ser utilizados

en un proyecto dado.

Una correcta instanciación del método ayudará a que el proceso de desarrollo se

ejecute de manera más fluida. Esto, se alcanza más fácilmente si la persona que

instancia el método es experimentada y posee un alto nivel de claridad en la Visión del

Producto que se desea desarrollar.

A menudo al inicio del un Proyecto no se tiene claro por completo el contexto de

la aplicación, por esta razón, la selección de los procesos, actores y productos pudiese

también cambiar en etapas más avanzadas del proyecto sin que esto deba significar un

impacto considerable sobre el desarrollo de la aplicación.

La jerarquía de Procesos de la Planificación del Proyecto, comprende tres sub-

procesos, como se puede observar en la Figura 6 - 10.


- 152 -

act Planificación del Proyecto

Planificación del Proyecto


Planificación de Versión Planificación deIncremento

Figura 6 - 10 Planificación del Proyecto

2.1. Planificación de la aplicación

Incluye las actividades de planificación del alcance, tiempos, recursos humanos,

otros recursos y servicios que requiera el desarrollo de la aplicación, este proceso se

ejecuta al inicio del Ciclo de la Aplicación y debe ser parte de los acuerdos contractuales

con el cliente ya que aquí se especifican en detalle los productos a ser generados.

Para ejecutar estos procesos de planificación se recomienda contar a nivel

organizacional con técnicas para medir la magnitud de un proyecto de manera de poder

identificar más fácilmente el numero de versiones e incrementos así como la cantidad

de recursos tanto humanos como económicos que harán falta para el desarrollo de la

aplicación Web. El diagrama de proceso de Planificación de la Aplicación se muestra a

continuación en la Figura 6 - 11.


- 153 -

analysis Planificación del Proyecto



«doc. de gestión»Visión del Producto Planificación de la Aplicación




«objetivo»Establecer el Plan Inicial de

ejecución del Proyecto

Herramienta de Planificación


«apoya»

«aprueba»«persigue»

«ejecuta»

«audita»

Figura 6 - 11 Planificación de la Aplicación

Este proceso da como resultado el Plan de Proyecto este documento incluye:

Descripción del proyecto

Alcance del proyecto

Productos a ser generados

Criterios de aceptación

Factores que impactarán el éxito del proyecto

Organización del equipo de desarrollo

Plan de proyecto inicial

Seguimiento y control del proyecto (Gestión de alcance, Gestión de

requisitos, Control de tiempos, Control de calidad, Gestión de riesgos,

Gestión de configuración, Gestión de compras y adquisiciones, Pruebas)

La planificación de la aplicación se desprende en dos subprocesos (ver Figura 6 -

12).


- 154 -

analysis Planificación de la Aplicación


Planificación delDesarrollo de Requisitos

Estimar el Proyecto

Figura 6 - 12 Planificación de la Aplicación

act Planificacion del Desarrollo de Requisitos

Proceso: Planificación del Desarrollo deRequisitos

Analizar lamagnitud del

proyecto

Inicial

Decidir quenecesidades del

negocio sedeben atendercon prioridad

Establecer la prioridad de

cada requisito (Alto Niv el)

Actualizar el plan Inicial del

Proyecto


Fin

«doc. técnico»Matriz de requisitos «doc. de gestión»

Plan del Proyecto


Figura 6 - 13 Planificación del Desarrollo de Requisitos


- 155 -

En el primero se realizan las actividades relacionadas al manejo de los requisitos.

Este subproceso se denomina Planificación del Desarrollo de Requisitos, el detalle se

puede visualizar en la Figura 6 - 13.

El segundo subproceso tiene que ver con los estimados iníciales de las

funcionalidades a desarrollar y la definición de las actividades del ciclo de la aplicación,

referirse a la Figura 6 - 14.

act Estimar el Proyecto

Proceso: Estimar el Proyecto

Estimar losTiempos de losrequisitos a alto

nivel

Identificar losriesgos

Instanciar elmétodo

Decidir cual v a aser la organizacion

del equipo

Decidir queProductos se v an a

generar

Decirdir queprocesos se v an a

ejecutar

Definir tiempo y costo del proyecto

Analizar el alcance del

proyectoInicio

Fin

Actualizar el plan Inicial del Proyecto



Validación del PlanInicial con el

Cliente

Establecer lasActiv iadesIniciales

Definir equipo de trabajo

Establecer Resonsables de

las etapas iniciales

Figura 6 - 14 Estimar el Proyecto


- 156 -

2.2. Planificación de la Versión

Al comienzo del ciclo de la versión, se lleva a cabo este proceso en donde se agrega

detalle a nivel de las actividades de la versión y al Cronograma del Proyecto. El

diagrama del proceso se puede ver en la Figura 6 - 15.

analysis Planificación de la Versión

Planificación de Versión«doc. técnico»Documentos de Requisitos



Refinar los estimados y cronograma a niv el de las activ idades del ciclo

de la versión





«apoya»

«aprueba»

«ejecuta»

«persigue»«audita»

Figura 6 - 15 Planificación de la Versión

Entre las actividades que se ejecutan en este proceso, se definen en el numero

de incrementos y las funcionalidades que en cada una se desarrollará, así mismo se

refinarán los estimados de las actividades de la versión y sus responsables (ver Figura 6 -

16).


- 157 -

act Planificación de Versión

Proceso: Planificación de la Versión

Inicio

Definir las activ idades para

el diseño preliminar


Requisitos


Establecer responsables

de las activ iades de

la Version

Rev isar estimaciones de tiempo y

costos

Ejecutar proceso"Planificación deaseguramiento de

la Calidad"

Definir lasactiv idades dediseño de la IW

Establecer losIncrementos de

la v ersion

Rev isar yactualizar losprductos de laFase anterior

Establecer lasactiv idades dela versión del

proyecto

Validar el plancon el cliente

Fin

«cronograma»Cronograma del

Proyecto

Definir lasactiv idades deconfiguración

inicial

Figura 6 - 16 Planificación de la Versión

2.3. Planificación del Incremento

Por último, antes de cada ciclo del incremento, se realiza la Planificación del

Incremento (Figura 6 - 17), durante este proceso se agrega detalle a las actividades a

nivel del Incremento al Cronograma del Proyecto, se especifican las funcionalidades o

CU a ser desarrollados y las acciones relacionadas a su implementación, también, se le

asignan responsables a cada una de las actividades. El detalle de las actividades de este

procese se muestra en la Figura 6 - 18.

Se recomienda usar como guía, para estos procesos de planificación, la plantilla

de Cronograma del Proyecto que provee el método, ya que en ella se encuentran

establecidas las actividades definidas para el método Blue WATCH.


- 158 -

analysis Planificación del Incremento

Planificación de Incremento


Requisitos



«cronograma»Cronograma del

Proyecto


Refinar los estimados y cronograma a nivel de las activ idades del ciclo del

incremento


«audita»

«apoya»

«aprueba»

«ejecuta»

«persigue»

Figura 6 - 17 Planificación del Incremento

act Planificación de Incremento

Proceso: Planificación del Incremento

Establecer lasactiv idades parael incremento del

proyecto

Para cada CUIdentificar las

accionesrelacionadas

Para cada CUIdentificar elresponsable

Para cada CUrev isar los

estimados detiempo

Definir lasactiv iades dev alidación del

cumplimeinto delas activ iades deaseguramiento de

la calidad

Inicio

Establcer lasactiv iadades de

entrega delIncremento

Fin

«doc. técnico»Documentos de Requisitos


Actualizar elcronograma del

Proyecto

Figura 6 - 18 Planificación del Incremento


- 159 -

3. Proceso: Dirección del Proyecto

Tal y como se puede observar en la Figura 6 - 19 el objetivo que persigue este

proceso es mantener al equipo de trabajo motivado, alineado y capacitado. Agrupa las

actividades de conformación del equipo de trabajo, capacitación del personal que

integra estos equipos, administración de contratos a terceros, coordinación de la

ejecución de las actividades del proyecto y administración de los recursos asignados al

proyecto, entre otros.

Aun cuando se ha dejado claro que la gestión de proyectos requiere

competencias relacionadas con el manejo de personas y equipos, el método no

pretende dar una guía de cómo realizar esta gestión si no, en todo caso, definir cuáles

son los aspectos importantes de la misma que deben existir durante el proyecto y que

permita: contratar, capacitar, compensar, evaluar, o entrenar personas.

analysis Dirección del Proyecto


Equipo de trabajo motiv ado, entrenado y alineado para

alcanzar las metas del proyecto

Técnicas de Dirección de

Proyectos


Información de la organización,

Misión, Visión, Objetivos


Rendimiento del equipo de desarrollo

Gerencia de Operaciones de la

Organización


«ejecuta»«apoya»

«persigue»«controla»«audita»

Figura 6 - 19 Dirección del Proyecto


- 160 -

La dirección del proyecto es un proceso transversal que se ejecuta durante todo

el ciclo de vida del proyecto, además, se considera un proceso operativo inherente a

todos los proyectos que ejecuta la organización. La jerarquía de procesos de la Dirección

de Proyectos se puede observar en la Figura 6 - 20.

Para encontrar más detalle de estas actividades se recomienda la lectura de

otros estándares, modelos o practicas existentes y probadas como es el PMBOK-Guide

to the Project Management Body of Knowledge- (PMI, 2000). El PMBOK una guía para

el manejo de la gestión de proyectos desarrollada bajo la supervisión del Project

Management Institute (PMI) y aprobada y adoptada por el Estándar IEEE.

analysis Dirección del Proyecto


Organizar el equipo detrabajo

Coordinar las activ idadesdel Equipo de Trabajo

Coordinar activ iades decapacitación

Ev aluar el Equipo deTrabajo

Motivar al Equipo deTrabajo

Motivar la comunicaciónentre el Equipo de Trabajo

Figura 6 - 20 Dirección del Proyecto

4. Proceso: Control del Proyecto

La Figura 6 - 21 muestra el diagrama del proceso Control del Proyecto, el detalle

de las actividades se puede visualizar en la Figura 6 - 22 y está compuesto por las


- 161 -

actividades necesarias para lograr supervisar y controlar el alcance, tiempos, costos,

riesgos, y demás recursos que han sido asignados al proyecto.

analysis Control del Proyecto

Control del Proyecto


«cronogram...Cronograma del

Proyecto



Plan de Proyecto Actualizado

«objetivo»Conocer el avance del proyecto

para corregir desv iaciones de lo planificado

Acciones correctiv as y preventiv as para las

situaciones presentadas


«doc. de gestión»Informes de Av ance


«participa»ejecuta

«persigue»«audita»

Figura 6 - 21 Control del Proyecto

Durante la ejecución del proyecto, el Líder de Proyecto debe contar con algunas

herramientas que le permitan monitorear el avance del proyecto. El producto principal,

definido en Blue WATCH, como apoyo a esta actividad es el Cronograma del Proyecto.

En el, se pueden encontrar el detalle de las actividades a ejecutar, permite además,

actualizar el avance de cada una de las actividades para que el Líder de Proyecto

conozca en qué punto se está con respecto a lo estimado. En caso encontrarse retrasos

significativos se debe hacer una revisión del "que" está afectando el proyecto y definir

estrategias para solventarlo.

El seguimiento continuo del proyecto permitirá identificar problemas en etapas

tempranas y ejecutar medidas correctivas antes que puedan afectar en un alto grado la

ejecución del proyecto.


- 162 -

act Control del Proyecto

Proceso: Control del Proyecto

Ej ecutar elproceso "Control

de Cambios"

Control de Tiempo

Control deAlcance

Ejecutar elproceso "Control

de Riesgos"

DetectarRestrasos oSituaciones

Ciriticas

ActualizarDocumentos

Realizar reuniónde Seguimiento

Control deConfiguración

Inicioidentificar el

avance de lasactiv idades



Detectar sicambiaron

elementos en laconfiguración



Fin

Figura 6 - 22 Control del Proyecto

Otra herramienta que permiten controlar el proyecto es la matriz de requisitos

donde se puede visualizar:

1. Los requisitos con sus CU y el nivel de avance que tiene cada uno

2. La prioridad e impacto de cada uno de estos CU.

3. El estado en el proceso en que se encuentra cada uno

También, es adecuado apoyarse en la matriz de riesgos para monitorear cada

uno de los aspectos que puedan causar ruido dentro del proceso.

Las actividades de seguimiento producen la revisión y posible actualización de los

productos mencionados.


- 163 -

5. Proceso: Cierre de la Fase

Cuando se ejecuta un proceso de cualquier tipo es necesario al culminar cada

fase establecer un punto final que identifique el fin de la misma y que determine por

tanto el comienzo de la siguiente fase o eventualmente el fin del proceso.

En el desarrollo de software iterativo e incremental suelen existir varias fases,

etapas o ciclos según defina el método empleado, que se retroalimentan entre ellas. Lo

complicado en un método con estos enfoques es determinar en qué punto acaba una

fase y comienza la siguiente, porque, en caso contrario, se caería en un ciclo

interminable dentro de la misma fase.

Blue WATCH identifica como cierre de una fase dos aspectos importantes, el

cierre administrativo y el cierre operativo.

El cierre administrativo ocurre, por lo general, al final del proceso de desarrollo

de la aplicación, es decir, cuando el proyecto ha culminado, mientras que el cierre

operativo al ser visto como una transición y no como un cese de actividades puede

comprenderse como la identificación de término de la fase. La actividad que

indiscutiblemente identifica el cierre de una fase, en el presente método, es la entrega

de la aplicación en alguno de sus estados, entrega del incremento, entrega de la versión

o entrega de la aplicación Web.

A nivel operativo (técnico), esto se traduce en el despliegue y entrega de los

productos desarrollados y probados en la fase. A nivel de gestión, además de hacer el

control respectivo de las actividades inherentes, también, se identifica la necesidad de

la reflexión del proceso ejecutado hasta el momento.

Una de las actividades más importantes, a nivel de mejora de los procesos son

las reuniones postmorten que permiten analizar la manera en que se llevó a cabo el

proyecto tratando de identificar aspectos mejorables del proceso y realizar la reflexión


- 164 -

necesaria del proceso ejecutado para así poder evolucionar y madurar como

organización. En su libro sobre RUP para pequeñas empresas (Pollice, Augustine, Lowe,

& Madhu) identifican los beneficios de este tipo de reuniones como sigue:

Ayuda a que los miembros del equipo comprendan mejor su función dentro del

grupo de desarrollo, específicamente, cómo deben trabajar como parte del

equipo

Ayuda a identificar fortalezas y debilidades del grupo e individuales en las

distintas aéreas para determinar donde se debe mejorar.

Permite al equipo identificar mejoras en el proceso

Además, se pueden identificar otros beneficios como:

Aprender de los problemas ocurridos y de los éxitos alcanzados, reforzando esas

actividades que se ejecutaron

Identificar que se hizo de manera correcta y debe repetirse en los siguientes

proyectos

Identificar que se fue mal y debe evitarse en los siguientes proyectos

Identificar las eventualidades surgidas y como fueron manejada de manera de

agregarlas a la lista de riesgos identificados y/o agregar actividades nuevas al

proceso de desarrollo

Pero en Blue WATCH se define un proceso de cierre no sólo para el proyecto si

no para cada una de las fases (ver Figura 6 - 23). Esto comprende las reuniones de

reflexión para cada cierre de cada fase y adicionalmente el cierre administrativo para el

cierre del proyecto.


- 165 -

analysis Cierre del la Fase

Cierre del la Fase

Cierre del incremento Cierre de la Versión Cierre del Poryecto

Figura 6 - 23 Cierre de la Fase

Las reuniones de reflexión a diferencia de las reuniones de seguimiento se

centran no en el seguimiento de lo que está ocurriendo y los avances o resolución de

conflictos, si no al contrario en análisis de lo ya ejecutado, el hecho de ejecutar estar

reuniones para cada fase y no una única al final del proyecto permite alcanzar beneficios

adicionales:

- Identificar actividades mejorables y alternativas para aplicarlas en el proceso en

curso.

- Incorporar al proceso aquellas actividades que se ejecutaron (aunque no se

planificaron) y se entiendan como necesarias o imprescindibles en el proceso pero

no se tenían identificadas.

Las reuniones de reflexión pueden resultar en una pérdida de tiempo si no son

llevadas de manera correcta. Smith & Sidky (2009) identifican las posibles causas de que

esto suceda:


- 166 -

La reunión se realiza de manera tardía y los participantes olvidan eventos

ocurridos.

Los participantes no tienen claros los objetivos de la reunión

Se confunden los problemas personales o de rendimiento con problemas del

proceso.

Los participantes no se les da el tiempo adecuado de poner en orden sus

pensamientos y observaciones.

Los aspectos encontrados en las reuniones no son bien documentados y no se

les lleva un seguimiento adecuado.

Es importante tener en cuenta que las reuniones de reflexión sirven para hacer

una revisión del proceso que se ha estado siguiendo y no para identificar si el proyecto

ha sido exitoso, efectivo o rentable. Tampoco sirven para identificar si se está siguiendo

un método establecido. A medida que se ejecuten este tipo de reuniones se realizaran

de manera más efectiva ya que el equipo se debe inclinar mas a realizar discusiones que

aporten valor de manera constructiva para mejorar el proceso.

A continuación, describimos los distintos tipos de cierres de fase y el objetivo de

las reuniones de reflexión en cada uno de estas etapas.

5.1. Cierre del Incremento

Implica la reunión de reflexión y la identificación de aspectos a mejorar o

incorporar en el proceso en curso, normalmente estas mejoras son a nivel técnico y a

veces del proceso. La Figura 6 - 24 muestra el proceso del Cierre del Incremento.


- 167 -

analysis Cierre del Incremento

Cierre del incremento





«doc. de soporte»Resultados de las Pruebas

Mejorar el proceso de desarrollo dentro del

proyecto

Lista de activ iades para mejoras del proceso

Información de lo acontecido durante el

desarrollo del Incremento

Entregables del Incremento


«participa»«ejecuta»

«persigue»

«audita»

Figura 6 - 24 Cierre del Incremento

Las actividades a realizar para el cierre se muestran en la Figura 6 - 25.

act Cierre del incremento

Proceso: Cierre del Incremento

Inicio

Realizar reunión dereflexión

Identificaraspectos

mejorables

Tomar decisionespara introducircambios en el

proceso en cursoFin



Pruebas

Entregables del Incremento



desarrollo del Incremento

Figura 6 - 25 Cierre del Incremento


- 168 -

5.2. Cierre de la Versión:

Implica la reunión de reflexión para la identificación de aspectos a mejorar o

incorporar en el proceso en curso. Las lecciones aprendidas tienen un punto de vista

más general y pueden abarcar decisiones gerenciales y del proceso.

El diagrama de procesos del Cierre de la Versión se muestra en la Figura 6 - 26 y

las actividades a realizar para el cierre de esta fase se muestran en la y Figura 6 - 27.

analysis Cierre de la Versión




Cierre de la Versión

Mejorar el proceso de desarrollo dentro del

proyecto




Pruebas

Entregables de la Versión


desarrollo de la Versión

«actor,rol»Especialista de

Calidad

«persigue»


«audita»

Figura 6 - 26 Cierre de la Versión


- 169 -

act Cierre de la Versión

Proceso: Cierre de la Versión

Realizar reuniónde reflexión

Inicio

Identificaraspectos

mejorables

Tomar decisionespara introducircambios en el

proceso en cursoFin



PruebasEntregables de la

Versión

Lista de activ iades para mejoras del

proceso



Figura 6 - 27 Cierre de la Versión

5.3. Cierre del Proyecto:

Implica la reunión de reflexión para la identificación de aspectos a mejorar en el

proceso que ha culminado, las lecciones aprendidas son de carácter, gerencial, técnico o

de soporte, o cualquier otro que aplique y que se considere para incorporar en el

proceso del la organización para el desarrollo de proyectos de software. También,

incluye el cierre administrativo del proyecto, asegurando que todas las actividades de

los procesos técnicos, de gestión y de soporte del proyecto o sub-proyecto, que se

cierra, hayan concluido y la transferencia y entrega formal de la aplicación empresarial

al cliente.

En la descripción del método WATCH (Montilva, Barrios, & Rivero, 2008)

encontramos la descripción del proceso de Cierre del Proyecto consiste en: (1) La

transferencia y entrega formal de la aplicación empresarial a los promotores o clientes

del proyecto y (2) el cierre de todas las actividades administrativas del proyecto,


- 170 -

incluyendo la terminación de los contratos que se tengan con empresas o contratistas

externos.

La versión Blue del método WATCH contempla actividades similares pero dentro

de un proceso único y, adicionalmente, incluye actividades de reflexión y mejora que se

llevan a cabo a través de la reunión de reflexión que, anteriormente, se ha explicado.

En la Figura 6 - 28 se muestra el diagrama del proceso Cierre de Proyecto.

analysis Cierre del Proyecto




Cierre del Proyecto

Entregables del Proyecto



Identificar mejoras del proceso de desarrollo para proximos proyectos

Lista de lecciones aprendidas y activ idades correctiv as y de mejoras


«persigue»


«audita»

Figura 6 - 28 Cierre del Proyecto

Las actividades del Cierre del Proyecto (Figura 6 - 29) comprenden:

• El cierre operativo: Recopilar, analizar y almacenar información sobre el

proyecto que pueda ser útil para proyectos posteriores. Particularmente, la información

sobre lecciones aprendidas, las métricas obtenidas durante la ejecución de los procesos


- 171 -

del proyecto y los productos intermedios elaborados durante todo el proyecto o fase

deben ser organizado y almacenados para su uso futuro.

• El cierre administrativo: Cierre de aspectos contractuales, cuya actividad se

encarga de finiquitar legal y administrativamente cada uno de los contratos que se

hayan realizado en el proyecto. Verificar que cada producto o servicio contratado haya

sido entregado de acuerdo a lo establecido en el contrato correspondiente. Verificar

que cada producto o servicio contratado haya sido entregado de acuerdo a lo

establecido en el contrato correspondiente. Cancelar a cada contratista el monto

establecido en el contrato. Cerrar administrativa y legalmente cada contrato.

act Cierre del Proyecto

Proceso: Cierre del ProyectoVerificar que el

productoacordado hayasido entregado

Formalizar laentrega del

proyecto

Validar que elproducto

completo hayasido entregado

Consultar alcliente su gradode satisfaccion

Identificaraspectos a

mejorar en elproceso

Inicio

Realizar cierreadministrativ o

Concretar cierre deaspectos contractuales

con prov eedores,contratados y resto de

compromisos asumidos

Realizar cierreoperativ o

Fin

Realizar reuniónde reflexión


Entregables del Proyecto

Lista de lecciones aprendidas y

activ idades correctiv as y de mejoras

Información de lo acontecido durante el desarrollo de la

Versión

Contrato

Finiquitar pagos acontratistas yproveedores

Figura 6 - 29 Cierre del Proyecto

revencyt-redidiciencia.métodos de desarrollo de

Documents