Este documento describe los conceptos y procesos asociados con las líneas de productos de software y el método WATCH. Explica que una línea de productos de software es una familia de productos de software que comparten características comunes. El método WATCH describe el ciclo de vida de un componente de software reutilizable, enfocándose en la reutilización del componente. El documento también presenta modelos para las diferentes etapas del ciclo de vida de un componente, incluyendo la especificación, implementación e instalación.
1. LPS y METODO
WATCH
Componente
David Vásquez
CI: 17.458.807
Profesora: María Sara Yepez
INSTITUTO UNIVERSITARIO POLITECNICO
“SANTIAGO MARIÑO”
EXTENSION VALENCIA
2. Líneas de productos de software
• Es una familia de productos de software que
tiene un conjunto de aspectos gestionados
que son comunes a todos los miembros de la
familia.
Objetivo su principal:
Reducir el tiempo, esfuerzo, costo y complejidad
de crear y mantener los productos de la línea.
3. Aspectos tecnológicos
ARQUITECTURA DE LPS:
ES instanciada a través de mecanismos de
Variabilidad:
Herencia
Puntos de extensión
Parametrización
configuración
4. • Repositorios LPS: es una base de datos
especializada que almacena activos de
software y facilita la recuperación y el
mantenimiento de los activos de software.
OBJETIVO:
Es asegurar la disponibilidad de activos para
apoyar el desarrollo de productos de la LPS.
Repositorios LPS
5. Tipos de repositorios
• Según su alcance: Locales.
• Según su propósito: De Reuso.
• Según su aplicabilidad: de dominio específico.
6. Áreas de practica de la ingeniería de
software
Los aspectos metodológicos de las LPS involucran la
aplicación de un conjunto de prácticas de ingeniería:
- Definición de la arquitectura LPS.
- Evaluación de la arquitectura LPS.
- Desarrollo de componentes
- Utilización de COTS
- Minería de activos
existentes.
- Ingeniería de Requisitos.
- Integración de sistemas de
software.
- Pruebas.
- Entendimiento de dominios
relevantes.
8. METODO WATCH
Concepto
• Es un método en que se describe el ciclo de
vida de un componente de software
reutilizable.
• Estos métodos se centran en la reutilización
del componente y no en su desarrollo
individual.
9. ¿Cómo se realizo o hizo este método?
• Este método se hizo siguiendo los conceptos de la
ingeniería de métodos.
• Estos conceptos incluyen:
El modelado del producto.
El modelado de los procesos.
También se incluye la propuesta por (Montilva &
Barrios, 2002), el cual adiciona el “Modelo del
grupo”
10. Principios del método Watch
• Utiliza la metáfora del reloj.
• Los procesos son divididos en procesos
gerenciales y procesos de desarrollo.
• El líder del proyecto es el que decidirá según
los resultados obtenidos si continua la
próxima fase.
11. Este método incluye dos nuevos
Aspectos
• La toma de decisiones acerca de las
posibilidades de aprovisionamiento, establece
los pasos a seguir en cada una de las etapas.
• Esta diseñado modelando el ciclo de vida de
un solo componente reutilizable y no una
aplicación integrada por componentes
12. Modelado del producto de un
componente
• Especificación del componente: Establece las características
del componente y las funciones.
• Interfaz del componente: Corresponde a la parte de
especificación de las operaciones y la definición de su
comportamiento.
• Implementación del componente: Comprende la realización
del componente.
• Componente instalado: La instalación (despliegue) de la
implementación del componente en una plataforma de
ejecución determinada.
• Componente Objeto: Es una instancia de un componente
instalado.
13. Etapas en el ciclo de vida de un
componente de software reutilizable
14. Modelado del componente
especificado
• Se realiza tomando en cuenta tanto la
especificación del componente, como también
la especificación de cada una de sus
interfaces.
Especificación de la interfaz de un componente
15. Aspectos de el modelado de un
componente especificado
• La especificación de un componente se realiza
mediante contratos.
• Un componente es especificado mediante dos
tipos de especificaciones: de componente y de
las interfaces.
• El contrato de uso se hace según lo
especificado en el documento.
• El contrato de uso se realiza según las
interfaces necesarias en el componente.
17. Modelado del Componente
implementado
• Es el resultado de reutilizar, diseñar, codificar y
probar el componente especificado.
• En este se logra implementar un componente
que podrá ser sustituido por otro que cumpla
con las especificaciones, siendo una ventaja
importante la sustitución de componentes.
18. Aspectos del modelado del
componente implementado
• Es el resultado de diseñar, codificar y probar, en
una plataforma de desarrollo, un componente
especificado.
• Un componente implementado sigue las
especificaciones de un contrato.
• Esta formado por la implementación de las
interfaces y la implementación interna del
componente.
• La interfaz permite el enlace de la aplicación con
la implementación interna
• Las interfaces proveen servicios.
20. Componente instalado
• Este modelo se encarga de definir los
conceptos y los aspectos relacionados con la
instalación de un componente dentro de una
plataforma de ejecución.
• Corresponde al despliegue dentro de la
infraestructura o plataforma de ejecución de
los componentes implementados.
21. Aspectos importantes del modelado de
componente instalado
• Un componente instalado se despliega en una
plataforma de ejecución o infraestructura.
• Un componente instalado posee dos tipos de
instancias: de interfaz y de componentes.
• Las instancias del componente pueden ser un
objeto o un ejecutable.
• Las instancias de las interfaces dependerán del
tipo.
23. Modelado de un contexto de un
componente
• El objetivo es determinar que conceptos están asociados a
un componente de software en todas sus etapas.
• Un componente de software reutilizable , además de estar
en una de las tres formas descritas anteriormente, se
encuentra enmarcado dentro de un contexto.
24. Aspectos importantes del modelado del
contexto de un componente
• Un componente se encuentra almacenado en un
repositorio, este repositorio puede ser interno,
externo o estar disponible libremente en la
internet.
• El componente es especificado mediante
contratos.
• Los componentes están enmarcados dentro de un
dominio.
• Los componente proveen servicios.
• Un componente se relaciona con otros
componentes.
28. Modelo del grupo de desarrollo
• La distinción entre los roles de los
desarrolladores de componentes es un
aspecto clave en el proceso de desarrollo
orientado a componentes.
• Para formar grupos de desarrolladores es
necesario contar con personas cuyas
habilidades cubran un amplio rango de
tecnologías de información
29. Atributos en los grupos de desarrollo
• El tamaño correcto: los grupos deben ser de un
tamaño razonable.
• El ambiente correcto: El habiente influye
bastante en el desarrollo de aplicaciones.
• Los mecanismos correctos de comunicación:
Para esto se deben tomar en cuenta los
mecanismos de comunicación asíncrona como el
correo electrónico, transferencia de archivos,
paginas web etc..
30. Roles del equipo de desarrolladores
Líder del proyecto.
Arquitecto de componentes.
Asesor de componentes.
Gerente de reutilización.
Gerente de aprovisionamiento.
Diseñador de componentes.
Experto en sistemas legados.
Desarrollador de componentes.
Certificador de componentes.
Realizador de pruebas de componentes.
Administrador del repositorio de componentes.
32. Actores
• El actor de los procesos gerenciales es el líder del
proyecto, su rol es el de gerenciar todas las
decisiones de acuerdo a los resultados que les
provean los procesos de verificación y validación
en cada etapa.
Procesos de desarrollo: Su objetivo principal es
de generar un modelo compuesto por etapas que
permita representar el ciclo de vida del desarrollo
de un componente de software en sus diferentes
etapas(especificación, implementación e
instalación)
33. Pruebas del componente
• El proceso de pruebas corresponde al proceso de
encontrar las diferencias en el comportamiento
de los componentes de software con respecto a
la manera que se espera que estos se comporten.
• Si se encontraran errores en la implementación,
estos deberán ser corregidos, antes de que el
componente sea certificado.
34. Tipos de pruebas
Pruebas Funcionales
Pruebas de comportamiento.
Pruebas de aceptación.
• Anidadas a estas también se encuentran las
técnicas con las cuales se pueden realizar , ya
sean manuales o automáticas.
35. Producto
• Las pruebas que se hacen para los
componentes incluyen pruebas de
funcionalidad , de comportamiento y de
aceptación : Documento de pruebas a realizar
(DPR), Documento de las pruebas funcionales
(DPF), Documentos de pruebas de
comportamiento (DPC), Documento de
pruebas de aceptación (DPA), Documentos de
análisis de resultados (DAR), Componente
probado
36. FIN DE LA PRESENTACION
GRACIAS POR SU ATENCION