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

ESQUEMA

1. LINE DE PRODUCTO SOFTWARE

2. BENEFICIOS DE LINEAS DE PRODUCTO SOFTWARE

3. ESTRATEGIAS

4. PROCESOS

5. EL MÉTODO GRAY WATCH

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

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

(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ón hasta 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

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

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.