Sistema II

1. REPUBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACION
I.U “POLITECNICO SANTIAGO MARIÑO”
EXTENSION MARACAIBO
LÍNEA DE PRODUCTO DE SOFTWARE Y MÉTODO WATCH
Realizado por:
Michelle León C.I 21228184
Cátedra
Sistemas II
Maracaibo, Julio 2015

2. ESQUEMA
1. LINE DE PRODUCTO SOFTWARE
2. BENEFICIOS DE LINEAS DE PRODUCTO SOFTWARE
3. ESTRATEGIAS
4. PROCESOS
5. EL MÉTODO GRAY WATCH

3. DESARROLLO
1. LINE DE PRODUCTO SOFTWARE
Se definen las líneas del producto de software como un conjunto de
sistemas software, que comparten un conjunto común de características,
las cuales satisfacen las necesidades específicas de un dominio o
segmento particular de mercado, y que se desarrollan a partir de un sistema
común de activos base de una manera preestablecida”.
La línea de producto de software es un conjunto de aplicaciones de
aplicaciones con una arquitectura común específica de dichas aplicaciones,
cada aplicación específica se especializa de alguna manera. El nuevo
desarrollo puede implicar una configuración específica de componentes,
implementación de componentes adicionales y adaptación de algunos
componentes para satisfacer las nuevas demandas.
Entre los precursores de este enfoque en el mundo del software se
encuentran McIllory (1968), Parnas (1976) y Neighbors (1989) que en sus
trabajos ya intuían el potencial de estas ideas.
Las Líneas de Producto Software (LPS) se engloban dentro de ese
anhelo recurrente dentro de la Ingeniería del Software que es la
reutilización.
La Línea de Producto Software es una etapa más en la búsqueda
del equilibrio entre coste y calidad del software.
2. BENEFICIOS DE LINEAS DE PRODUCTO SOFTWARE
Los beneficios que las LPS aportan a la calidad se pueden medir de
dos formas. La primera mediante el grado de precisión con que cada
producto se ajusta a las necesidades de cada cliente. Esta medida depende
del grado de “variabilidad” de la LPS. A mayor variabilidad, más
probabilidades de adaptar el producto a los gustos del cliente. Pero,
normalmente, esta variabilidad tiene un coste, y el reto es encontrar el

4. equilibrio entre coste y variabilidad. A diferencia de los enfoques
tradicionales, en las LPS la variabilidad es un concepto nuclear. Todo el
proceso de desarrollo está guiado por esta noción con el objetivo de
abaratar los costes de la variabilidad, y así poder conseguir mayores cotas
de variabilidad y, por tanto, de satisfacción de las peculiaridades del cliente.
Otro aspecto es la tasa de defectos en los productos de la LPS. Aquí
los beneficios se derivan de la reutilización de los elementos comunes
(coreassets). La continuada utilización de estos elementos a lo largo del
tiempo hace que finalmente estén muy depurados/probados. Además, los
beneficios de encontrar y eliminar un defecto en un coreasset no se limitan
al producto donde se detecta el error, sino que se disemina entre todos los
productos de la LPS.
3. ESTRATEGIAS
El proceso de desarrollo de la LPS depende, entre otros muchos
factores, del ámbito de la LPS. Es fundamental saber acotar la familia de
productos que serán objeto de la línea. En general, existe una tendencia a
generalizar en exceso cuando se está desarrollando software re-usable,
considerando casos poco probables. Es la filosofía del “por si acaso”. Sin
embargo, esta excesiva generalización, si se repite con distintas “features”
compatibles entre sí, puede dar lugar a una explosión combinatoria.
4. PROCESOS
Un aspecto central compartido por las distintas metodologías de
desarrollo de LPS Es la división de los procesos de ingeniería en dos
equipos de trabajo (ver figura 3.4). El primer equipo se encarga de la
Ingeniería de Dominio, el cual es definido por Clements (2001) como core
asset Development. Este equipo es responsable de desarrollar los
elementos comunes al dominio: estudiar el dominio, definir su alcance

5. (requisitos) dentro del mercado objetivo de la LPS, definir las features,
implementar los core assets reutilizables y su mecanismo de variabilidad, y
establecer cómo es el plan de producción.
El segundo equipo se encarga de la Ingeniería de Producto definido por
Clements (2001) como product Development. Sus cometidos incluyen
desarrollar los productos para clientes concretos, a partir de los recursos
basados no en los requisitos del dominio, sino en requisitos concretos de
clientes. Para ello, este segundo equipo utiliza los recursos creados por el
equipo anterior.
5. EL MÉTODO GRAY WATCH
WATCH es un método enfocado al desarrollo de software empresarial.
A lo largo de los anos el método WATCH ha sido refinado por varios
autores. Su primera extensión fue realizada por Hamar en el año 2003 para
desarrollar el ciclo de vida de un componente reutilizable, desde su
especificaciónhasta su liberación. Esta sección presenta una visión general
de la versión denominada GRAY WATCH, en particular, nos
concentraremos en su proceso de Análisis donde se definen y especifican
el conjunto de requisitos funcionales y no funcionales que la aplicación
empresarial debe satisfacer.
GRAY WATCH es un marco metodológico que describe los aspectos
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. Un marco metodológico es un patrón que debe ser
instanciado, es decir adaptado cada vez que se use. Cada equipo de
trabajo deberá usar el método como un patrón o plantilla metodológica, a
partir de la cual dicho equipo debe elaborar el proceso especıfico de
desarrollo de la aplicación que se desea producir. GRAY WATCH cubre
todo el ciclo de vida de las aplicaciones; desde el modelado del dominio de

6. la aplicación, pasando por la definición de los requisitos de los usuarios,
hasta la puesta en operación de la aplicación.
GRAY WATCH está compuesto por tres (3) modelos fundamentales: el
modelo de productos, el modelo de actores y el modelo de procesos. Este
´ultimo establece los procesos necesarios para gestionar proyectos de
desarrollo de aplicaciones empresariales y llevar a cabo las actividades
técnicas y de soporte que requieren estos proyectos. Los procesos técnicos
del método se dividen en tres grupos: Procesos de Análisis, Diseño e
Implementación. La figura 1 ilustra esta clasificación.
La figura anterior resalta tres (3) grandes grupos de procesos. Los
procesos de análisis de la Aplicación cubren los procesos de Modelado de
Negocios y la Ingeniería de Requisitos. La fase de diseño consiste de los
procesos de Diseño Arquitectónico y Diseño de Componentes, mientras
que los procesos de Implementación agrupan los procesos de
Programación e Integración, Pruebas y Entregas de la Aplicación.
Procesos de análisis
Estos procesos tienen como objetivos (1) entender y modelar el Sistema
de Negocios que constituye el dominio de la aplicación empresarial; y (2)
definir y especificar el conjunto de requisitos que la aplicación empresarial
debe satisfacer.
En la figura 2 se aprecia que el proceso de Ingeniería de Requisitos
requiere de la ejecución de cinco subprocesos complementarios: el

7. Descubrimiento de Requisitos, Análisis de Requisitos, Especificación de
Requisitos Validación de Requisitos y Gestión de Requisitos.
El subproceso de Análisis de Requisitos consiste en determinar y
resolver posibles conflictos entre los requisitos y establecer la interacción
de la aplicación empresarial con su dominio o ambiente. La figura 3 muestra
el diagrama de actividades de este subproceso.