Metodo

1. REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA
LA EDUCACIÓN UNIVERSITARIA
INSTITUTO UNIVERSITARIO POLITÉCNICO
“SANTIAGO MARIÑO”
EXTENSIÓN COL - SEDE CIUDAD OJEDA
METODO WATCH Y LINEA DE PRODUCTOS DE SOFTWARE
Realizado por:
José, Jerez
C.I. 17.827.697
Ciudad Ojeda, Agosto 2016

2. Es un marco metodológico que describe los procesos técnicos, gerenciales y de
soporte que deben emplear los grupos de desarrollo de aplicaciones
empresariales. Un marco metodológico es un patrón que debe ser adaptado, al
proyecto y al grupo cada vez que se use.
Características
 Sólidamente fundamentado
 Incremental e iterativo
 De propósito específico
 Flexible y adaptable
 Usa mejores prácticas de:
 Ingeniería de Software y
 Gestión de Proyectos
 Integra los procesos de gestión con los procesos técnicos y de soporte
EL METODO WATCH

3. Análisis
Soporte
Gestión
Diseño
Construcción
Pruebas
Instalación
PROCESO DEL DESARROLLO DEL
METODO WATCH

4. Análisis
Soporte
Gestión Diseño
ConstrucciónPruebas
Instalación
ESTRUCTURA DEL METODO WATCH

5. Método WATCH
Modelo de procesosModelo de ActoresModelo de Productos
COMPONENTES DEL METODO
WATCH

6. Tipo de productos
Productos de Trabajo
(Productos Intermedios)
Productos Finales
(Productos entregables)
Modelo del
Dominio de Aplicación
Documento de
Requisitos
Documento de
Diseño
Documento de
Implementación
Documento de
Pruebas
Caso de Negocio
Plan del Proyecto
Informes de Gestión
Productos de
Gestión del Proyecto
Productos
Técnicos
Aplicación
Empresarial
Programas
Base(s) de Datos
Manuales
MODELO DE PRODUCTO

7. Líder del
Proyecto
Grupo de Diseño
Grupo de
Implementación
Grupo de Análisis
Cliente
Grupo de Pruebas
e Instalación
Equipo de Desarrollo de Aplicaciones Empresariales
Describe las modalidades de organización de los grupos de trabajo que
desarrollan las aplicaciones; así como, los roles y responsabilidades de los
actores que integran estos equipos .
MODELO DE ACTORES

8. Interesado
(Stakeholder)
Personal
Ejecutivo
Usuario Externo Desarrollador Personal de apoyoUsuario Interno
Personal
Administrativo
Personal
Técnico
Presidente
Junta
Directiva
Gerente
Jefe de
Departamento
Jefe de
Sección
Presidente
Director
Lider de
Proyecto
Analista de
Negocios
Ingeniero de
Requisitos
Arquitecto de
Software
Diseñador de
Software
Ingeniero de
Componentes
Programador
Especialista
en Pruebas
Administrador
de Bases
de Datos (ABD)
Especialista
en Calidad
(SQA)
Especialista en
Configuración
(SCM)
Facilitador
Consultor
Administrador
de Sistemas
ActoresRoles
MODELO DE ACTORES
Un actor es un individuo o una unidad organizacional que está
involucrada en el proyecto.

9. Describe los procesos técnicos, gerenciales y de soporte que los grupos de
trabajo deben emplear para desarrollar las aplicaciones empresariales
Modelo de Procesos
Procesos
de Soporte
Procesos
de Gestión
Procesos
Técnicos
MODELO DE PROCESOS

10. Modelado del
Dominio
de la Aplicación
(MDA)
Ingeniería de
Requisitos
(IR)
Diseño
Arquitectónico
(DA)
Diseño
Detallado
(DD)
Construcción
&
Integración (C&I)
Pruebas
de la
Aplicación (PA)
Entrega
de la
Aplicación (EA)
Gestión del Proyecto (GP)
Capacitación (CAP)
Verficación y Validación (V&V)
Gestión de Riesgos (GR)
Aseguramiento de la Calidad del Software (SQA)
Gestión de la Configuración del Software (SCM)
Procesos
fundamentales
Procesos
de apoyo
CADENA DE VALOR

11. Línea de Productos de Software
1. Es un conjunto de sistemas de software que comparten un conjunto
común y gestionado de aspectos que satisfacen las necesidades
específicas de un segmento de mercado o misión y que son desarrollados
a partir de un conjunto común de activos fundamentales [de software]
de una manera prescrita.(Clements and Northrop, 2002)
2. Consiste de una familia de sistemas de software que tienen una
funcionalidad común y alguna funcionalidad variable" (Gomma, 2004)
3. La funcionalidad común descansa en el uso recurrente de un conjunto
común de activos reutilizables (requisitos, diseños, componentes,
servicios web, entre otros.

12. Modelo Básico de una Línea de
Productos de Software
La entrada: Una colección de partes de software (requisitos, diseños,
componentes, casos de prueba, etc.) que se configuran y componen de
una manera prescrita para producir los productos de la línea
El control: Modelos de Decisión y Decisiones de Productos. Los Modelos
de Decisiones describen los aspectos variables y opcionales de los
productos de la línea. Cada producto de la línea es definido por un
conjunto de decisiones (decisiones del producto)

13. Modelo Básico de una Línea de
Productos de Software
El proceso de producción: Establece los mecanismos o pasos para componer
y configurar productos a partir de los activos de entrada. Las decisiones del
producto se usan para determinar que activos de entrada utilizar y como
configurar los puntos de variación de esos activos.
La salida: Productos de software: Conjunto de todos los productos que
pueden o son producidos por la línea de productos.
Beneficios
•La entrega de productos de software de una manera z más rápida,
económica y con una mejor calidad.
•Las LPS producen mejoras en: Tiempo de entrega del producto (time to
market ), Costos de ingeniería, Tamaño del portafolio de productos,
Reducción de las tasas de defectos, Calidad de los productos.
Beneficios tácticos de ingeniería:
•Reducción en el tiempo promedio de creación y entrega de nuevos
productos
•Reducción en el número promedio de defectos por producto Reducción en
el esfuerzo promedio requerido para desarrollar y mantener los productos

14. Son todos los artefactos producidos durante el desarrollo del
software y que son potencialmente reutilizables
Ejemplos
Arquitectura base
Patrones de diseño
Componentes de software
Manuales de usuario
Especificación de requisitos
‹Planes de producción
‹Planes de pruebas
ACTIVOS DE SOFTWARE

15. „Arquitectura de Software es la definición de las componentes que
forman el sistema, las propiedades externamente visibles de esas
componentes y las relaciones entre las mismas
Arquitectura Base de una LPS corresponde a la definición de la
arquitectura general que describe todos los componentes que podrían
potencialmente formar parte de la línea de productos de software y su
interrelación. La arquitectura base define y limita el alcance de la LPS
ARQUITECTURA DE
SOFTWARE

16. Desarrollo de Componentes
„Las componentes de software son uno de los activos
más claramente reutilizable
Existe una fuerte tendencia a desarrollar software
basado en componentes
Las LPS dan un marco para el desarrollo y uso planificado
de las componentes de software
„Tecnologías de definición de componentes: ‹ActiveX,
JavaBeans, CCM, entre otros

17. Formas de Reutilización de
Componentes „
Reuso de componentes a lo largo de las distintas versiones de una
aplicación
Esto sabemos hacerlo
Reuso de componentes en varias versiones de un software y en distintos
productos
Reuso de componentes en varias versiones, diversos productos de software
y en distintas organizaciones

18. Productividad ‹
Sistemas grandes y complejos pueden desarrollarse con menor
tiempo y esfuerzo
Menor tiempo para tener un producto en el mercado „
Costos
‹Cada nuevo producto sólo requiere desarrollar unas pocas partes
nuevas
Personal calificado y caro es pagado una única vez y su trabajo se
reutiliza
Desarrollo de Líneas de Productos de Software
Facilidad de Administración
Reducción del riesgo
Menor trabajo a ser planificado y controlado
Calidad
‹Activos probados dan garantías de calidad y buen funcionamiento ‹
BENEFICIOS DE UN LPS

19. Desarrollar activos genéricos, configurables, robustos,
documentados, portables y probados es más caro que hacer un
desarrollo ad hoc
Antes de obtener los beneficios de la LPS uno debe tener una
base de activos con estas características
Lograr el cambio de paradigma en las prácticas profesionales es
un gran reto: ‹mejores activos no aseguran un mejor producto
(hoy), ‹mejores activos posibilitan la reutilización (mañana)
COSTOS DE UN LPS

20. Desafíos de la Ingeniería del Producto
„
Adaptar las necesidades de los clientes a las posibilidades de la LPS. „
Ser capaz de integrar productos útiles (casi) exclusivamente con las
componentes disponibles
Ceñirse a la estructura de la arquitectura base para todos los productos. „
Realizar pruebas de integración y del sistema, suponiendo que cada
componente satisface su especificación

21. Algunos Productos Potenciales
Desde el punto de vista de la funcionalidad: ‹
Módulo para que un producto CAD genere buenas mallas de volumen
Módulo para que un software FEM pueda refinar/des refinar una malla de
volumen en forma adaptiva o interactiva
‹Software independiente para generar y mejorar mallas de superficie
‹Software independiente para refinar/des refinar mallas de volumen
„Desde el punto de vista de la implementación
Manejar los datos en estructuras de memoria o bien manejarlos en una base de
datos
‹Implementar algoritmos secuenciales o paralelos de generación o refinamiento
de las mallas de volumen
‹Generar mallas de volumen a partir de mallas de superficie generadas por
diferentes productos CAD

22. Módulo para mejorar mallas de superficie
generadas por un CAD particular. „
Se manejan los datos en estructuras de memoria. „
Solamente la componente de cargar estructuras de datos es
dependiente del CAD
Las estructuras de datos tienen una interfaz conocida para las otras
componentes, pero es indiferente su implementación interna

23. Módulo para generar mallas de volumen a
partir de una gran malla de superficie. „
Se usa una base de datos con idéntica interfaz que las estructuras de
memoria
Se usan algoritmos paralelos para corregir la malla de superficie y para
generar la malla de volumen
Las otras componentes son idénticas a las anteriores