W_Watch:
Método Watch para el desarrollo de Proyectos Pequeños de Software
(Prof. J. Barrios y J. Montilva - Versión 1 – febrero 2009)
1. Introducción
El método W_Watch es la versión ligera del método Watch, es un marco metodológico
que describe, el conjunto estructurado de actividades necesarias para producir un
producto de software sencillo y pequeño con documentación precisa.
En esta versión se trata de disminuir la elaboración detallada de documentos y/o
especificaciones que actúan como instrumentos de apoyo parcial al proceso de desarrollo,
permitiendo, a un grupo de desarrollo pequeño (2 o 3 personas), dedicar más tiempo a
actividades de implementación e implantación de versiones operativas y evolutivas del
producto. Es por ello que las actividades gerenciales, de control de calidad y
configuración, necesarias en todo proyecto de desarrollo, se limitan a prescribir
actividades esenciales de control de cambios, validación y verificación de
especificaciones y productos. El rol de líder del proyecto puede ser llevado en paralelo y
sin sobrecarga durante la ejecución de otros roles técnicos del proyecto.
2. Estructura del Método
El modelo de procesos esta organizado en dos grupos de procesos complementarios: los
procesos gerenciales que incluyen los procesos de soporte y los procesos de técnicos de
desarrollo propiamente dicho.
La estructura del método W_Watch inspirada en la metáfora del reloj de pulsera
(watch en Inglés), organiza los procesos técnicos, en forma circular, en las posiciones del
dial de un reloj y los procesos gerenciales en el centro, de manera que planifican y
controlan la ejecución de los procesos técnicos.
Esta manera de definir el marco metodológico permite que la ejecución de los
procesos de desarrollo sea cíclica, iterativa y controlada.
Cada ciclo de procesos técnicos produce una nueva versión del sistema (modo
progresivo o evolutivo) o un nuevo subsistema, del sistema en desarrollo, si se ha
definido un modo de desarrollo incremental.
En cada ciclo se puede iterar entre las fases a fin de corregir errores, introducir
nuevos requisitos o, simplemente, mejorar el producto en desarrollo.
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
analysis modelo de procesos w -w atch
Modelado del
Negocio
Entrega del
Sistema de (from Cadena de Valor)
Ingeniería de
Software
Requisitos
(from Cadena de Valor) fin
inicio
(from Cadena de Valor)
Procesos
Gerenciales
Pruebas del
Diseño del
Sistema de
(from Cadena de Valor) Sistema de
Software
Software
(from Cadena de Valor)
(from Cadena de Valor)
Implementación Aprovisionamiento
del Sistema de de componentes
Software
(from Cadena de Valor) (from Cadena de Valor)
Figura 1. Modelo de Procesos del Método W_Watch
Los procesos gerenciales describen las actividades que el líder del proyecto debe
realizar para:
Planificar, organizar y controlar el proceso de desarrollo del proyecto
Asegurar la calidad del sistema mediante validaciones y verificaciones
Gestionar los cambios en las especificaciones del producto
Se establecen un conjunto de supuestos que soportan la reducción de
responsabilidades gerenciales en el líder del proyecto. Estos son:
1) El personal de desarrollo en sus diferentes roles: analistas, diseñadores y
programadores) cuenta con las habilidades, experiencia y conocimientos
relacionados con el uso de lenguajes y herramientas de apoyo al desarrollo
que se van a utilizar.
2) El enfoque de desarrollo evolutivo es la base para la planificación del
número de iteraciones que se realizarán. Se parte del principio la primera
versión del producto es operativa y que cada nueva versión es el resultado
de un refinamiento de la versión previa.
3) Se espera que se empleen herramientas automatizadas para la elaboración de
la documentación del proyecto basadas en la notación UML. Estas
herramientas deberían facilitar las actividades de actualización,
mantenimiento, traza y seguimiento de los cambios y/o modificaciones en
especificaciones de producto para cada versión.
Los procesos técnicos son los procesos que prescriben lo que debe hacer el grupo de
desarrollo para elaborar un producto de software pequeño y poco complejo. Estos
procesos se organizan en una estructura formada por pasos y actividades. Cada proceso es
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
descrito mediante una tabla que le asocia los pasos y las actividades que indican de
manera detallada las acciones a ejecutar para llevar a cabo cada actividad prescrita y por
consiguiente cada paso del proceso.
Como toda guía metodológica el modelo de procesos del W_Watch debe ser
adaptado, por el líder del proyecto, según las particularidades de cada proyecto de
desarrollo. Entre los factores a considerar para la adaptación se tienen las características
propias de cada producto y de los ambientes de desarrollo y de operación; se consideran
además, los recursos utilizables tanto a nivel de personal como de HW y SW y las
habilidades y destrezas requeridas por los miembros que conformarán el equipo de
desarrollo.
analysis fluj o de trabaj o entre procesos
si Modelado del
Negocio
Diseño del Implementación del
Entrega del
Sistema de Sistema de Software
Software Sistema de
(from Cadena de Valor) Software
si MN
(from Cadena de Valor) (from Cadena de Valor)
(from Cadena de Valor)
Ingeniería de
No Requisitos
Aprovisionamiento Pruebas del Sistema
de componentes de Software
(from Cadena de Valor)
inicio (from Cadena de Valor) (from Cadena de Valor)
fin
Procesos Gerenciales
(from Cadena de Valor)
Figura 2. Flujo de trabajo del Modelo de Procesos del Método W_Watch
Por ejemplo, en el caso de proyectos asociados con desarrollo de productos de
software que no requieren el modelado del sistema de negocios donde operará el
software, el modelo de procesos de desarrollo se iniciaría directamente en la fase de
Ingeniería de Requisitos. La figura 2 muestra el diagrama de flujo de trabajo del Modelo
de Procesos del W_Watch.
3. Procesos Gerenciales
Procesos Actividades Técnicas y Notaciones Productos
Gestión del Planificación del Proyecto PERT/CPM Visión del
Proyecto Organización del grupo de Estructuras de grupos producto
desarrollo Estimación de costos Plan del Proyecto
Control del proyecto Técnicas de V & V Lista de chequeo
Verificación y Validación Técnicas de gestión de de riesgos
Revisión Técnica de riesgos Informe de V &
Productos Inspección de diseño y V
Resolución de Riesgos código Documentos del
Gestionar cambios en los Recorridos proyecto –
requisitos del SW estructurados informes
Control de Documentación Técnicas de Documentos de la
Control de la elaboración de aplicación
configuración del documentos técnicos Especificaciones
software Matrices y listas de actualizadas
rastreo de requisitos
Técnicas de SCM
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
4. Procesos de Desarrollo - Fase: Modelado de Negocios
Pasos Actividades Técnicas y Notaciones Productos
Definición del Establecer el alcance del Revisión de los manuales Definición del
Sistema de Negocios sistema de negocios de organización SN y su alcance
(SN) Identificar los Entrevistas con los
subsistemas del SN involucrados en el SN
Modelado de Definir objetivos de SN Revisión de los manuales Diagrama de
Objetivos del SN Elaborar la jerarquía de de organización Objetivos del SN
objetivos (si necesario) Entrevistas con los
involucrados en el SN
Modelado de objetivos
Modelado de los Modelar la cadena de Observación y Entrevista Cadena de Valor
Procesos de Negocio valor con los expertos del SN del SN
del SN Modelar los procesos Revisión de Diagramas de
vitales (fundamentales) documentación técnica Procesos del SN
Modelar los procesos de Modelado de Cadenas de (en UML
soporte (de apoyo) Valor Business)
Modelar las actividades Modelado de Procesos en Diagramas de
de cada proceso de la UML Business actividades en
cadena Modelado de Actividades UML
en UML
Modelado de Identificar Modelado de actividades Descripción de
actores/unidades actores/unidades (pueden con actores Actores y sus
organizacionales ser otros sistemas) Roles
Definir roles de los Matriz Actores-
actores en cada proceso Procesos
Elaborar la matriz
actores/procesos
Modelado de los Identificar los objetos de Modelado de Clases en Modelo de
Objetos de Negocio negocio y sus tipos x UML Conceptos del
del SN proceso SN (diagramas
Definir las relaciones de clases en
entre tipos de objetos UML)
Elaborar el modelo
preliminar de objetos
Identificación de las Identificar las reglas de Consultas a usuarios y Lista reglas de
Reglas de Negocio negocio expertos negocio del SN
Analizar y clasificar las Búsqueda de Descripción de
reglas de negocio documentación las reglas de bajo
Identificar las reglas de Modelado de reglas de nivel
negocios de bajo nivel negocio
Modelado de Identificar eventos Modelado de eventos en Diagrama de
Eventos Modelar el flujo de UML Business eventos en UML
trabajo asociado a cada Business
evento Matriz Eventos-
Elaborar la matriz de Procesos
eventos-procesos
Integrar los Verificar coherencia Matriz de relación objetos/ Modelo de
modelos entre modelos procesos Negocios del SN
Ensamblar el documento Técnicas de
de modelado documentación
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
5. Procesos de Desarrollo - Fase: Ingeniería de Requisitos
Pasos Actividades Técnicas y Notaciones Productos
Descubrimiento Identificación y análisis de los problemas de Entrevista Listado de
de Requisitos información que tiene el Sistema de Negocios (o el Documentación requisitos C
contexto) relacionada con el documentado
Determinación de los objetivos del producto de SW dominio s usando
Identificación y clasificación de los involucrados Observación de las planillas
(stakeholders) y usuarios (internos y externos) – si actividades que realizan Volere
MN a partir de modelo de actores los usuarios
Recolección de los requisitos que tienen los Plantilla de definición
involucrados y usuarios - si MN a partir de modelo de de requisitos Volere
actividades/actores [VOL04]
Identificación de requisitos de información a partir de Reuniones con usuarios
los diagramas de procesos y actividades (o del
contexto)
Análisis de Clasificación de los requisitos F y NF Matriz de interacción Documento
Requisitos Chequeo de requisitos entre requisitos de Definición
o Comprobar necesidad, prioridad, Técnicas de de Requisitos
consistencia, completitud y factibilidad negociación (DDR)
Negociación de requisitos validado
o Discutir, priorizar y acordar requisitos con
el cliente y los usuarios de la aplicación
Elaborar cuadro detallado de los requisitos
clasificados indicando sus prioridades y su fuente
Validación de requisitos con el cliente y usuarios
seleccionados
Especificación Elaboración de los diagramas de casos de uso Modelado de sistemas Documento de
de Requisitos Elaboración del diagrama preliminar de clases de en UML: Especificación de
objetos de negocio o Diagramas Requisitos (DER)
o Establecer las relaciones entre las clases de casos de validado
de negocios uso
Elaboración de diagramas de transición de estados o Diagramas
(si requerido) de clases
Integración de diagramas en documento de o Diagramas
Especificación de Requisitos (DER) de estado
Realizar la revisión técnica del DER con el cliente,
usuarios especializados y diseñadores
6. Procesos de Desarrollo - Fase: Diseño de software
Pasos Actividades Técnicas y Notaciones Productos
Determinación de requisitos a Modelos de calidad del Listado descriptivo de
Definición de la implementar a partir del DER y software [BCK98] las metas de diseño
estructura inicial
relacionarlos con la arquitectura del Estilos arquitectónicos Estructura de la
de la aplicación sistema de SW [BCK98] aplicación
Establecer las metas de calidad de la 3 CAPAS
arquitectura del sistema de SW Arquitectura 3 capas
Dividir el sistema en subsistemas (si Cliente/Servidor
necesario)
Refinar casos de uso
Refinar diagrama preliminar de
clases
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
Elaborar diagramas de secuencia
Agrupar funcionalidad según
criterios predefinidos - subsistemas
Representar subsistemas en arquitectura
3 capas
Definir en detalle el perfil de los usuarios
Diseño de la Técnicas de Utilidad Diseño de pantallas
Definir perfil de tareas a partir de los
Interfaz (usability)
Usuario/Sistema
casos de uso Diagrama jerárquico
Establecer las características estéticas que Técnicas y estrategias de de pantallas
deberá tener la interfaz gráfica de la diseño de interfaces GUI
aplicación
o Establecer los fondos, colores,
tipos de fuentes, etc.
Diseñar la estructura general de la
interfaz U/S:
o Elaborar el diagrama jerárquico
de pantallas del sistema
o Definir las características que
deben tener los ítems que
componen las pantallas de la
interfaz: menús, ventanas,
íconos, enlaces, cuadros, cajas,
etc.
Realizar las revisiones técnicas de la
interfaz U/S según lo expresado en
documentos DDR y DER
Diseño la BD Diseño Conceptual Diagramas de clase en Esquema conceptual
Refinar modelo de clases de objetos de UML integrado de la BD
negocio de cada proceso e integrarlos
Definir los atributos de cada clase de Modelado de Bases de Esquema conceptual de
objetos de negocio Datos OO la BD integrado y
Verificar el esquema con los requisitos Procedimiento de verificado
Validar con los usuarios respectivos el conversión de diagramas Esquema físico de la BD
esquema de clase a esquemas de
Diseño implementable relación
Convertir el esquema conceptual de la Modelado BD
BD en un esquema relacional equivalente Relacionales
Verificar el esquema implementable con
Revisión técnica
los requisitos relacionados
(Inspección de Diseño)
Diseño Fisico
Establecer los índices de las tablas del Procedimientos de diseño
diseño implementable físico de BD relacionales
Definir los derechos de acceso para cada
tipo de usuario (usuario final,
programador, ABD)
Definir las reglas de integridad de la BD
Diseño de Identificación de Componentes UML Components Definición de
componentes de Identificar componentes funcionales – [CHD01] componentes
SW propios de la aplicación – Arquitectura Inicial
implementación de casos de uso de Componentes
Identificar componentes de interfaz U/S Especificación de
Identificar componentes de acceso y Interfaces
manipulación de datos persistentes Arquitectura de
Ubicar componentes en arquitectura Componentes
inicial predefinida y describirla
Interacción de Componentes
Determinar las interfaces de cada
componente
Especificación Integrar diagramas de subsistemas, UML Components Documento de Diseño
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
del diseño interfaz, arquitectura y componentes y [CHD01] (DD) validado
BD en Documento de Diseño Procedimientos de
Definir los procedimientos de respaldo, administración de la
recuperación y seguridad de la BD BD
Realizar las revisiones técnicas de
validación del DD con el cliente y
usuarios seleccionados
7. Proceso de Desarrollo - Fase: Aprovisionamiento de componentes
Pasos Actividades Técnicas y Notaciones Productos
Instalar la Seleccionar, adquirir y/o preparar la Instalación de software Plataforma de
plataforma de plataforma o infraestructura de software distribuido (definido desarrollo
desarrollo requerida para desarrollar el sistema por el o los fabricantes) instalada
Instalar la plataforma de desarrollo:
o Instalar servidores web, de
aplicaciones, SMBD
Adquisición de Buscar componentes que puedan ser Búsqueda de Componentes
Componentes adquiridos de terceros (abiertos o componentes abiertos o adquiridos
propietarios) o en librerías propias de la comerciales (P. ej.,
organización COTS)
Adquirir componentes
Adaptación de Buscar componentes en repositorios locales Envoltorios (Wrapping) Componentes
Componentes (internos) o de terceros (externos) adaptados
Adaptar los componentes mediante su
modificación interna o el uso de envoltorios
(wrappers)
Desarrollo de Desarrollar aquellos componentes que no Diseño de algoritmos Componentes
Componentes pudieron ser localizados o adquiridos. Refinamiento paso-a- desarrollados
Partiendo de la especificación de cada paso
componente: Pseudo-código
o Elaborar el diseño detallado de Estándares de
cada operación de cada interfaz codificación
del componente Estrategias de pruebas
o Codificar las operaciones del de unidad
componente
o Elaborar la o las interfaces del
componente
o Desplegar el componente en la
plataforma seleccionada
o Diseñar y ejecutar las pruebas de
unidad del componente
Diseño y Realizar pruebas funcionales para cada Estrategias de pruebas Especificacion
ejecución de uno de los componentes adquiridos, caja negra: es de casos de
pruebas de suscritos, adaptados y desarrollados o Particiones prueba
componentes o Preparar los datos y equivalentes Componentes
mecanismos de prueba o Análisis de valores probados y
o Preparar el ambiente de límites depurados
pruebas Técnicas de pruebas
o Ejecutar las pruebas de hilos (thread
funcionales de cada componente testing)
Depurar los errores encontrados durante Depuración de errores
las pruebas funcionales de cada
componente
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
8. Procesos de Desarrollo - Fase: Ensamblaje del Sistema de software
Pasos Actividades Técnicas y Notaciones Productos
Construcción Ensamblar la capa de presentación con los Técnicas de construcción de Capa de
de la Interfaz componentes de la interfaz U/S software presentación de la
U/S o Codificar e integrar los componentes Técnicas y estrategias de aplicación
de interfaz del lado del cliente pruebas de interfaces gráficas Especificaciones de
Diseño y Ejecución de Pruebas de la Interfaz Depuración de errores casos de prueba
U/S
o Determinar los aspectos de la interfaz Interfaz U/S
U/S que deben probarse probada
o Realizar prueba de la interfaz U/S
Preparar los datos y
mecanismos de prueba
Preparar el ambiente de
pruebas
Ejecutar las pruebas de la
interfaz U/S
Depurar los errores encontrados
Ensamblaje Ensamblar la capa de lógica de negocios – Despliegue de componentes Capa de lógica de
de subsistemas - componentes de la aplicación que en servidores de aplicaciones negocios de la
Componentes la integran Técnicas y estrategias de aplicación
de la Ejecución de Pruebas de Integración pruebas de integración de Especificaciones de
aplicación – o Definir los criterios y técnicas de componentes OO casos de prueba
capa de pruebas de integración de o Casos de uso DER
negocios componentes o Diagramas de Lógica de negocios
o Realizar casos de prueba de Componentes del de la aplicación
integración de componentes diseño probada
Preparar los datos y Depuración de errores
mecanismos de prueba
Preparar el ambiente de
pruebas
Ejecutar las pruebas de
integración de componentes
Depurar los errores encontrados
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
Pasos Actividades Técnicas y Notaciones Productos
Construcción Crear la base de datos usando los esquemas Creación de BD relacional Capa de datos de la
de la BD implementables diseñados en la etapa anterior y Técnicas y estrategias de aplicación
el DBMS seleccionado pruebas de bases de datos Especificaciones de
Diseño y Ejecución de Pruebas de la BD Depuración de errores casos de prueba
o Realizar casos de prueba de la BD Base de datos
Definir los aspectos de la probada
BD que deben probarse
Preparar los datos y
mecanismos de prueba
Preparar el ambiente de
pruebas
Ejecutar las pruebas de la
BD
Depurar los errores encontrados
Pruebas de Realizar casos de prueba de integración de Técnicas y estrategias de Especificaciones de
la capas pruebas de aplicaciones casos de prueba
Integración o Definir los criterios y técnicas de distribuidas Aplicación integrada
de Capas pruebas de integración de las tres Depuración de errores y probada
capas de la aplicación (desplegada en la
o Preparar los datos y mecanismos de plataforma de
prueba desarrollo)
o Preparar el ambiente de pruebas
o Ejecutar las pruebas de integración
de capas
Depurar los errores encontrados
9. Procesos de Desarrollo - Fase: Pruebas del Sistema de Software
Pasos Actividades Técnicas y Notaciones Productos
Preparación de Preparar mecanismos de pruebas Seguimiento de los Mecanismos de
las Pruebas Preparar datos de prueba procedimientos de pruebas
Preparar ambiente de pruebas prueba Datos de pruebas
o Desarrollo
o Cliente
Realizar Realizar las pruebas funcionales del Estrategias de Especificaciones de
Pruebas del sistema (aplicación integrada) pruebas funcionales casos de prueba
Sistema o Ejecutar las pruebas y no funcionales Informe de
funcionales incidentes de prueba
Realizar las pruebas no funcionales del Aplicación validada
sistema por el usuario
o Ejecutar las pruebas no-
funcionales
Realizar las pruebas de aceptación
o Ejecutar las pruebas de
aceptación
Reportar los errores encontrados en las
pruebas
Corrección de Corregir los errores detectados en las Depuración Aplicación probada y
errores pruebas funcionales y no-funcionales (debbuging) depurada
Realizar pruebas de regresión para
asegurar que las correcciones no
introducen nuevos errores
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09
10. Procesos de Desarrollo - Fase: Entrega del Sistema de Software
Pasos Actividades Técnicas y Productos
Notaciones
Planificación de la Instalación Técnicas y Plan de Instalación
Instalación de
la Aplicación
Definir las estrategias de migración a la herramientas de Plataforma de
nueva aplicación planificación Operación (H/S)
Determinar actividades de la instalación de instalada
la aplicación Instructivos de
Estimar costos, tiempos y recursos despliegue de Aplicación instalada
requeridos aplicaciones
proporcionados BD actualizada
Instalar la plataforma de
Hardware/Software requerida para operar por el fabricante
el sistema (si no está instalada) Técnicas de
Desplegar la aplicación en los diferentes migración de
servidores de la plataforma de operación datos
Carga inicial de datos (si se requiere)
Preparar los datos de carga inicial de la
BD
Actualizar la BD
Diseño y Definir los aspectos de la instalación que Técnicas y Especificaciones de
Ejecución de deben probarse estrategias de casos de prueba
Pruebas de Diseñar los procedimientos y casos de pruebas de Informe de
Instalación prueba de instalación instalación incidentes de prueba
Preparar los datos y mecanismos de prueba Depuración de Aplicación instalada
Ejecutar las pruebas de instalación errores probada
Corregir los errores encontrados
Entregar el sistema al cliente
Realización de Identificar cambios y ajustes finales Control de Aplicación ajustada
ajustes finales Medir el impacto de los cambios y ajustes cambios en las
finales especificaciones
Tomar decisiones sobre la realización de del software
los cambios y ajustes
Elaboración de Elaborar los documentos o manuales del Técnicas de Documentos o
la producto de SW elaboración de manuales de la
Documentación documentos aplicación
técnicos
Entrenamiento Preparar ambiente y material de Técnicas de Material de
de Usuarios entrenamiento entrenamiento entrenamiento
Conducir entrenamiento de usuarios Usuarios entrenados
Methodius Informe técnico Versión 0.1 Elaborado por J. Barrios para revisión del Equipo 10
Febrero 09