REVENCYT-RedidiCiencia.Métodos de desarrollo de ...
Transcript of 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?
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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).
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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),
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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)
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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)
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Tabla 2 - 3 Vista Estructural o de Procesos (Parte 2)
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Tabla 2 - 4 Vista Estructural o de Procesos (Parte 3)
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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)
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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)
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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,
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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):
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 84 -
composite structure Visión del Producto
«doc. de gestión»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
Responsable principal: Líder de Proyecto.
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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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,
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Responsable principal: Líder de Proyecto.
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Responsable principal: Líder de Proyecto.
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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”.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 90 -
composite structure Matriz de Riesgos
«doc. de soporte»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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 93 -
Resultado de Pruebas
Prioridad: Recomendado
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 94 -
Lista de Chequeo del Código
Prioridad: Recomendado.
Responsable principal: Líder de Desarrollo.
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
Prioridad: Recomendado
Responsable principal: Líder de Desarrollo.
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Prioridad: Esencial.
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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»Modelo del Negocio
«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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«doc. técnico»Documentos de
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
Prioridad: Esencial.
Responsable principal: Líder de Proyecto.
Proceso que lo genera: Inicio del Proyecto.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Prioridad: Recomendado.
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Prioridad: Esencial.
Responsable principal: Líder de Proyecto.
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 104 -
class Documento de Diseño Detallado
«doc. técnico»Documento de Casos de
Uso
«modelo»Modelo Funcional
«diagrama UML»Diagramas de CU
(Detallado)
«doc. técnico»Descripciones textuales
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Prioridad: Esencial.
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Prioridad: Esencial.
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Prioridad: Recomendado
Responsable principal: Equipo de Desarrollo.
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«modelo»Modelo Funcional
«diagrama UML»Diagramas de CU
(Detallado)
«modelo»Modelo Estructural
«doc. técnico»Documento de Casos de
Uso
«doc. técnico»Descripciones textuales
«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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Prioridad: Esencial.
Responsable principal: Equipo de Desarrollo.
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 115 -
composite structure Aplicación Empresarial
«código»Aplicación Web
«aplicación»Aplicación Empresarial
«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
Prioridad: Recomendado.
Responsable principal: Líder de Desarrollo.
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 116 -
Programa de Pruebas
Prioridad: Recomendado
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
Objetivos del modelo
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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»Cliente-Promotor
«actor,rol»Representante de
Usuarios{1..*}
«actor,rol»Desarrollador
«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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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,rol»Cliente-Promotor
«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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«actor,rol»Cliente-Promotor
«actor,rol»Representante de
Usuarios{1..*}
«actor,rol»Analista
«actor,rol»Arquitecto Diseñador
«actor,rol»Diseñador Web
«actor,rol»Especialista de Calidad
«actor,rol»Especialista en Pruebas
«actor,rol»Líder de Desarrollo
«actor,rol»Líder del Proyecto
«actor,rol»Programador
{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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 125 -
class Estructura Organizativ a Minima
Equipo del Proyecto
Cliente
Comite Directivo
Equipo de Desarrol lo
«actor,rol»Cliente-Promotor
«actor,rol»Representante de
Usuarios{1..*}
«actor,rol»Diseñador Web
«actor,rol»Especialista en Pruebas
«actor,rol»Líder de Desarrollo
«actor,rol»Programador
{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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 126 -
class Desarrollador
«actor,rol»Analista
«actor,rol»Líder del Proyecto
«actor,rol»Programador
{1..*}
«actor,rol»Desarrollador
«actor,rol»Especialista en
Pruebas
«actor,rol»Especialista de
Calidad
«actor,rol»Líder de Desarrollo
«actor,rol»Diseñador Web
«actor,rol»Arquitecto Diseñador
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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
Es responsable directo de los siguientes productos:
Aplicación (Código).
Revisión de calidad del producto.
Documento de Configuración.
Documento de Despliegue.
Realiza, colabora en la realización o aprueba de los siguientes productos:
Cronograma del Proyecto.
Matriz de Riesgos.
Matriz de Requisitos.
Documentos de CU.
Diseño Detallado.
Diseño de la BD
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
Colabora en la definición de los riesgos relacionados con la ejecución del
proyecto.
Es responsable directo de los siguientes productos:
Modelo de Negocio.
Especificaciones Funcionales.
Matriz de Requisitos (Junto con el Líder de Proyecto)
Realiza, colabora en la realización o aprueba de los siguientes productos:
Visión del Negocio.
Documento de CU.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
Colabora en la definición de los riesgos relacionados con la ejecución del
proyecto.
Prestar asistencia técnica a los miembros del equipo de desarrollo en la fase
de construcción
Es responsable directo de los siguientes productos:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 131 -
Documento de Arquitectura.
Diseño de la BD.
Realiza, colabora en la realización o aprueba de los siguientes productos:
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.
Es responsable directo de los siguientes productos:
Aplicación (Código).
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
Matriz de Requisitos.
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
Es responsable directo de los siguientes productos:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
Es responsable directo de los siguientes productos:
Documento de Especificación de Pruebas
Documento de Resultados de las Pruebas
Reporte de Pruebas
Colabora en la realización de los siguientes productos:
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,
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Es responsable directo de los siguientes productos:
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.
Colabora en la realización de los siguientes productos:
Documento de Especificación de Pruebas
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
Objetivos del modelo
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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 Transversales
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Procesos Transversales
Pruebas delIncremento j
Procesos de Gestión
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Gestión del Proyecto
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Gestión del Proyecto
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
Procesos de Gestión
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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,
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
Gestión del Proyecto
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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«actor,rol»Líder del Proyecto
«actor,rol»Cliente-Promotor
Necesidades de la Organización
Contrato
«doc. de gestión»Visión del Producto
Procesos y Reglas del Negocio
«objetivo»Obtener la Aprobación y
alcance del Proyecto
«actor,rol»Representante de
Usuarios{1..*}
«regla»Normas para la
Contratación
«actor,rol»Analista
«colabora»
«apoya»
«controla»
«ejecuta»
«persigue»«regula»
«ejecuta»
Figura 6 - 8 Inicio del Proyecto
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«doc. de gestión»Visión del Producto
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 152 -
act Planificación del Proyecto
Planificación del Proyecto
Planificación de laAplicación
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 153 -
analysis Planificación del Proyecto
«actor,rol»Líder del Proyecto
«doc. técnico»Matriz de requisitos
«doc. de gestión»Visión del Producto Planificación de la Aplicación
«actor,rol»Cliente-Promotor
«cronograma»Cronograma del Proyecto
«doc. de gestión»Plan del Proyecto
«objetivo»Establecer el Plan Inicial de
ejecución del Proyecto
Herramienta de Planificación
«actor,rol»Especialista de Calidad
«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).
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 154 -
analysis Planificación de la Aplicación
Planificación de laAplicació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
«doc. de gestión»Visión del Producto
Fin
«doc. técnico»Matriz de requisitos «doc. de gestión»
Plan del Proyecto
«cronograma»Cronograma del Proyecto
Figura 6 - 13 Planificación del Desarrollo de Requisitos
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«doc. de gestión»Visión del Producto
«doc. de gestión»Plan 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«doc. técnico»Modelo del Negocio
«cronograma»Cronograma del Proyecto
Refinar los estimados y cronograma a niv el de las activ idades del ciclo
de la versión
«actor,rol»Líder del Proyecto
«actor,rol»Cliente-Promotor
Herramienta de Planificación
«actor,rol»Especialista de Calidad
«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).
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 157 -
act Planificación de Versión
Proceso: Planificación de la Versión
Inicio
Definir las activ idades para
el diseño preliminar
«doc. técnico»Documentos de
Requisitos
«doc. técnico»Modelo del Negocio
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 158 -
analysis Planificación del Incremento
Planificación de Incremento
«doc. técnico»Documentos de
Requisitos
«actor,rol»Líder del Proyecto
«actor,rol»Cliente-Promotor
«cronograma»Cronograma del
Proyecto
Herramienta de Planificación
Refinar los estimados y cronograma a nivel de las activ idades del ciclo del
incremento
«actor,rol»Especialista de Calidad
«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
«cronograma»Cronograma del Proyecto
Actualizar elcronograma del
Proyecto
Figura 6 - 18 Planificación del Incremento
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
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
«actor,rol»Líder del Proyecto
Información de la organización,
Misión, Visión, Objetivos
«doc. de gestión»Plan del Proyecto
Rendimiento del equipo de desarrollo
Gerencia de Operaciones de la
Organización
«actor,rol»Especialista de Calidad
«ejecuta»«apoya»
«persigue»«controla»«audita»
Figura 6 - 19 Dirección del Proyecto
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«actor,rol»Líder del Proyecto
«cronogram...Cronograma del
Proyecto
«doc. de soporte»Matriz de Riesgos
«doc. técnico»Matriz de requisitos
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
«actor»Equipo de Desarrollo
«doc. de gestión»Informes de Av ance
«actor,rol»Especialista de Calidad
«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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«doc. de gestión»Plan del Proyecto
«doc. técnico»Matriz de requisitos
Detectar sicambiaron
elementos en laconfiguración
«doc. de gestión»Informes de Av ance
«doc. de soporte»Matriz de Riesgos
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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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:
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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.
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 167 -
analysis Cierre del Incremento
Cierre del incremento
«actor,rol»Líder del Proyecto
«actor»Equipo de Desarrollo
«aplicación»Aplicación Empresarial
«doc. de gestión»Informes de Av ance
«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
«actor,rol»Especialista de Calidad
«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
«doc. de gestión»Informes de Avance
«doc. de soporte»Resultados de las
Pruebas
Entregables del Incremento
Lista de activ iades para mejoras del proceso
Información de lo acontecido durante el
desarrollo del Incremento
Figura 6 - 25 Cierre del Incremento
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«actor,rol»Líder del Proyecto
«actor»Equipo de Desarrollo
«aplicación»Aplicación Empresarial
Cierre de la Versión
Mejorar el proceso de desarrollo dentro del
proyecto
Lista de activ iades para mejoras del proceso
«doc. de gestión»Informes de Avance
«doc. de soporte»Resultados de las
Pruebas
Entregables de la Versión
Información de lo acontecido durante el
desarrollo de la Versión
«actor,rol»Especialista de
Calidad
«persigue»
«participa»«ejecuta»
«audita»
Figura 6 - 26 Cierre de la Versión
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«doc. de gestión»Informes de Avance
«doc. de soporte»Resultados de las
PruebasEntregables de la
Versión
Lista de activ iades para mejoras del
proceso
Información de lo acontecido durante el
desarrollo de la Versión
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,
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«actor,rol»Líder del Proyecto
«actor»Equipo de Desarrollo
«aplicación»Aplicación Empresarial
Cierre del Proyecto
Entregables del Proyecto
Información de lo acontecido durante el
desarrollo de la Versión
Identificar mejoras del proceso de desarrollo para proximos proyectos
Lista de lecciones aprendidas y activ idades correctiv as y de mejoras
«actor,rol»Especialista de Calidad
«persigue»
«participa»«ejecuta»
«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
MÉTODOS DE DESARROLLO DE APLICACIONES WEB PARA PYMES
- 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
«aplicación»Aplicación Empresarial
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