2. Introducción
La siguiente presentación se enfoca a explorar vínculos
entre dos disciplinas de importancia técnica y práctica
relacionadas con las tecnologías de la información:
líneas de productos de software y el método watch.
3. Es un conjunto de sistemas intensivos en software que comparten
un conjunto común, administrado de prestaciones para
satisfacer las necesidades específicas de un segmento de
mercado o misión y que son desarrollados a partir de un
conjunto en común de activos centrales de un modo prescrito.
Estos activos centrales forman la base para la Línea de Productos
y en ellos se incluyen, entre otros, la arquitectura, las
especificaciones de requisitos, los planes y casos de prueba y
componentes de software reutilizables.
Líneas de Productos de Software (LPS)
4. Definición Clements (2001)
“se definen como un conjunto de sistemas software,
que comparten un conjunto común de características
(features), 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 (core assets) de una manera
preestablecida”.
Líneas de Productos de Software (LPS)
5. Las Líneas de Productos de Software pueden incrementar
significativamente la productividad de los ingenieros de
software, entendida como una reducción en el esfuerzo y el
coste necesario para desarrollar, poner en marcha y mantener
un conjunto de productos de software similares. En los casos de
estudio se han observado mejoras en la productividad que
duplican o triplican los enfoques tradicionales.
Beneficios Relativos A La Productividad Y Al Coste
6. Los beneficios que las líneas de productos de software 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 líneas de productos de software . 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 líneas de productos de software 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.
Beneficios Relativos A La Calidad
Otro segundo aspecto es la tasa de defectos en los productos de la líneas de
productos de software. Aquí los beneficios se derivan de la reutilización de los
elementos comunes (core assets). 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 core assets no
se limitan al producto donde se detecta el error, sino que se disemina entre
todos los productos de la líneas de productos de software.
7. Estrategias:
El proceso de desarrollo de las líneas de productos de software depende, entre otros
muchos factores, del ámbito de la líneas de productos de software. 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. Así cuatro features que soportaran cada una de ellas
tres casos posibles, todos ellos compatibles entre sí, daría lugar a 36 posibles diferentes
combinaciones. Esto favorece la variabilidad, pero incurre en costes de pruebas,
documentación y desarrollo adicionales, que pueden finalmente no rentabilizarse para
casos poco probables.
ASPECTOS METODOLÓGICOS
8. Procesos:
Un aspecto central compartido por las distintas metodologías de desarrollo de líneas de
productos de software es la división de los procesos de ingeniería en dos equipos de
trabajo. 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 líneas de productos de software, 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.
ASPECTOS METODOLÓGICOS
9. Cada sistema concreto de una línea de productos de software se deriva de la
arquitectura completa, tomando o no las partes opcionales adecuadas, según los
requisitos funcionales y no funcionales seleccionados por los usuarios. Esta actividad es
esencialmente un proceso de selección de características que genera un sub-
modelo, que a su vez (por las relaciones de trazabilidad) compone por derivación
toda o la mayor parte del código de la aplicación. La clave de este proceso reside en
la trazabilidad desde las características hasta el código pasando por los modelos de
diseño. Esta trazabilidad no es fácil de gestionar por varias razones. En primer lugar,
una característica opcional puede originar varios elementos en un modelo de diseño
(en general tenemos que asignar a la relación de trazabilidad entre elementos de
distintos niveles una multiplicidad varios a varios).
El segundo problema tiene que ver con el hecho de que los mecanismos básicos de
modelado de la variabilidad (la especialización en los diagramas de clases o la
relación <<extend>> de los casos de uso) se utilizan en muchas ocasiones para
expresar dos tipos de variabilidad distinta: la existente en la arquitectura de la línea de
productos de software (que se corresponde con requisitos opcionales) y la presente en
una aplicación concreta, que sigue teniendo variaciones en tiempo de ejecución (por
ejemplo, dos formas de pago alternativas).
Combinación De Paquetes Y Clases Parciales
10. Para extender la trazabilidad hasta el nivel de implementación se utiliza el
concepto de clase parcial. Aunque el nombre de las clases sea el mismo, su
pertenencia a distintos paquetes las hace entidades diferentes. Si los paquetes a
los que pertenecen son seleccionados, en el momento de compilación del
sistema se combinan en una única clase, haciendo que este modelo reproduzca
en la implementación de la línea de productos de software la misma estrategia
utilizada en requisitos y diseño. Por tanto, para derivar una aplicación concreta
basta con indicar al compilador los paquetes necesarios, que se corresponden
con la configuración elegida en el modelo de características. De esta manera se
cubre el objetivo de la trazabilidad uno-a-uno desde las características hasta el
código.
Implementación De La Línea De Productos De Software
11. Es un método de desarrollo de software elaborado para ser empleado durante el
desarrollo de sistemas de información empresarial (SIE).
Montilva (2008) define el método WATCH como: Un marco metodológico que
describe los procesos técnicos, gerenciales y de soporte que deben emplear los
equipos y grupos que tendrán a su cargo el desarrollo de las aplicaciones
informáticas de un SIE. Un marco metodológico es un patrón que debe ser
instanciado, es decir adaptado cada vez que se use. Cada equipo de desarrollo
de aplicaciones de un SIE deberá usar el método como un patrón o plantilla
metodológica, a partir de la cual ellos deben elaborar el proceso específico de
desarrollo de la aplicación que dicho equipo deba producir.
El Método Watch
12. • Sólida Fundamentación
• Posee una base conceptual y metodológica muy bien sustentada. El método
descansa en conceptos bien establecidos que se derivan de la Ingeniería de
Software, los Sistemas de Información Geográfica (SIG) y los Sistemas de
Información Empresarial (SIE).
• Es Estructurado y Modular
• Posee una clara estructura que facilita su comprensión y utilización. Esta
estructura separa los tres elementos primordiales de un método: el producto
que se quiere elaborar, los actores que lo elaboran y el proceso que siguen los
actores para elaborar el producto.
• Es de Propósito Específico
• El método está dirigido al desarrollo de aplicaciones geográficas en entornos
empresariales; es decir, al desarrollo de sistemas de información de carácter
corporativo que estén orientados.
• Es Flexible y Adaptable
• Si bien el método está dirigido al desarrollo de aplicaciones especializadas
(aplicaciones geográficas en entornos empresariales), sus tres componentes
pueden ser adaptados, con relativa facilidad, a otros tipos de productos de
software.
Características
13. • Orientar a los equipos de desarrollo acerca de qué deben hacer y cómo
deben desarrollar una aplicación informática de un SIE.
• Gestionar el desarrollo de las aplicaciones de un SIE como proyectos de
ingeniería, siguiendo los estándares de gestión de proyectos establecidos
en la empresa.
• Asegurar que en el desarrollo de cada aplicación de un SIE se empleen las
mejores prácticas, técnicas, herramientas, estándares y lenguajes
aceptados internacionalmente para desarrollar software de alta calidad.
El Método WATCH se utiliza para estructurar, planificar y controlar el proceso
de desarrollo de un sistema de información.
Objetivos
14. La metodología watch está comprendida por tres modelos, que la
componen estos son el modelo del producto, el modelo de proceso
y el de actores, cada uno de ellos aporta información en distintos
documentos que permiten el desarrollo de aplicaciones
empresariales para SIE.
• Modelado del Producto: Define el modelo de producto como “ el
primer componente del método Watch, este modelo describe las
características generales que tienen las aplicaciones de un SIE e
identifica los productos intermedios y finales que se deben
producir durante el desarrollo de una aplicación SIE.” .Para
desarrollar una aplicación empresarial es indispensable conocer
tanto los requisitos necesarios para llevar a cabo el proceso,
como los resultados que se obtendrán de dicho proceso, y por
este motivo es que el modelo de productos debe ser la primera
actividad de la metodología Watch.
Componentes
15. • Modelado de Actores
Montilva (2008) define el modelo de actores como “el segundo de
los tres componentes que integran el Método WATCH para el
desarrollo de una aplicación empresarial. Su función es discutir todos
aquellos aspectos organizativos relacionados con los actores,
equipos de trabajo y demás interesados vinculados al desarrollo de
las aplicaciones de una aplicación empresarial”.
• Modelado de Procesos
Es un conjunto de actividades que tienen un mismo fin, el modelo de
procesos es el último componente del método WATCH y
corresponde a los procesos que definen la trayectoria del proyecto y
como se admiran los recursos del equipo, sean estos materiales o
humanos.
Componentes
16. El método WATCH está orientado al desarrollo de un tipo particular de
software denominado aplicación empresarial. Una aplicación empresarial es
aplicación distribuida que apoya la ejecución de procesos de negocios en
una empresa. Las aplicaciones de comercio electrónico y los sistemas de
información web (SIW) son dos tipos particulares de aplicaciones
empresariales. Tanto las aplicaciones web como los SIW dan soporte a un
conjunto de uno o más procesos de negocios, mediante una interfaz web
que permite el intercambio de datos e información a través de una red
Intranet, Extranet o Internet.
Modelo Del Producto
17. El modelo de procesos del método WATCH es un marco
metodológico que describe, en términos generales, un conjunto
estructurado de actividades necesarias para producir una
aplicación empresarial. Este modelo organiza estas actividades
en dos tipos de procesos diferentes pero complementarios:
procesos gerenciales y procesos de desarrollo.
Modelo De Procesos Del Método Watch
18. Los Procesos Gerenciales
describen las actividades que la gerencia del proyecto (o, en su defecto, el líder del
proyecto) debe realizar para:
• Planificar, organizar, dirigir, manejar el grupo de desarrollo y controlar el proyecto
de desarrollo de un sistema o aplicación empresarial
• Asegurar la calidad del sistema.
• Gestionar la configuración del sistema
• Adiestrar el grupo de desarrollo durante el proceso de ejecución del proyecto.
Modelo De Procesos Del Método Watch
19. Los Procesos De Desarrollo
son los procesos técnicos que describen que debe hacer el
grupo de desarrollo para producir una aplicación empresarial.
Estos procesos se organizan en una estructura jerárquica
formada por fases, pasos y actividades.
Modelo De Procesos Del Método Watch
20. La aplicación de procesos, técnicas y prácticas gerenciales es un
factor crítico de éxito en el desarrollo de software. La calidad del
producto, la entrega a tiempo del producto, el cabal cumplimiento
de su presupuesto y el uso eficiente de los recursos humanos y
tecnológicos asignados a un proyecto de software son sólo posibles
mediante la aplicación de procesos gerenciales.
Procesos Gerenciales Del Método WATCH
22. Esta presentación introduce la noción de Línea de Producto de
Software como una etapa más en la búsqueda del equilibrio entre
coste y calidad del software. La estructura de la sección trata de
resaltar las tres bandas en las que tiene que jugar este enfoque: la
organizativa, la metodológica y la técnica. De un buen maridaje entre
ellas dependerá en gran medida el éxito final que obtenga nuestra
línea de producto.
El Método Watch es un método de desarrollo de software elaborado
para ser empleado durante el desarrollo de sistemas de información
empresarial es uno de los diferentes tipos de métodos para el desarrollo
de sistemas de información se utiliza para estructurar, planificar y
controlar el proceso de desarrollo de un sistema de información.
Conclusiones
