S03-2020I

Vista previa del material en texto

INGENIERÍA DE SOFTWARE
RAFAEL VILCA BARBARAN
UNIVERSIDAD NACIONAL DE LA 
AMAZONÍA PERUANA
mailto:Rafael.vilca@unapiquitos.edu.pe
mailto:rafaelvilcab@Gmail.com
Un lenguaje de modelado, no 
es suficiente
Desarrollo Basado
En Equipos
Lenguaje de 
Modelado
Unified 
Process
2
Rational Unified Process
◼ Es un proceso de desarrollo de software y junto con el 
Lenguaje Unificado de Modelado UML, constituye la
metodología estándar más utilizada para el análisis, 
implementación y documentación de sistemas OO.
 Forma disciplinada de asignar tareas y responsabilidades 
(quién hace qué, cuándo y cómo) . 
 Pretende implementar las mejores practicas en ingenieria 
de Software: 
 Desarrollo iterativo 
 Administración de requisitos 
 Uso de arquitectura basada en componentes 
 Control de cambios 
 Modelado visual del software 
 Verificación de la calidad del software 
Rational Unified Process
◼ El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e 
incremental, estar centrado en la arquitectura y guiado por los casos de uso. 
◼ El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al 
final de cada ciclo, cada ciclo se divide en fases que finalizan con un hito donde 
se debe tomar una decisión importante:
 Inicio: se hace un plan de fases, se identifican los principales casos de uso 
y se identifican los riesgos 
 Elaboración: se hace un plan de proyecto, se completan los casos de uso 
y se eliminan los riesgos 
 Construcción: se concentra en la elaboración de un producto totalmente 
operativo y eficiente y el manual de usuario 
 Transición: se implementa el producto en el cliente y se entrena a los 
usuarios. Como consecuencia de esto suelen surgir nuevos requerimientos 
a ser analizados. 
Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
Arquitecturas
Basadas en
Componentes
Desarrollar
Iterativamente
Verificar 
Calidad
Modelizar
Visualmente
5
Planeamiento
Inicial
Planeamiento
Requerimientos
Análisis y Diseño
Implementación
Prueba
Distribución
Evaluación
Ambiente de
Administración
1. Desarrollar Software 
Iterativamente
◼ Cada iteración resulta en un release ejecutable
6
1. Desarrollar Software 
Iterativamente
◼ Los desentendimientos importantes se evidencian 
tempranamente
◼ Se alienta el feedback del usuario
◼ Focalización en los temas más críticos, sin 
distracciones
◼ Testing continuo e iterativo: evaluación objetiva
◼ Inconsistencias entre requerimientos, diseños e 
implementaciones se detectan tempranamente
7
1. Desarrollar Software 
Iterativamente
◼ Carga de trabajo mejor repartida en el tiempo
◼ El equipo puede analizar las lecciones aprendidas en 
las primeras iteraciones
◼ Integración progresiva en lugar de Big Bang
◼ Evidencias concretas a los sponsors
◼ Se facilita la reutilización
◼ Arquitectura más robusta
8
2. Administrar los requerimientos
◼ Requirements Management, enfoque 
sistemático que involucra:
◼ Obtener, organizar y documentar la 
funcionalidad y restricciones requeridas a 
un sistema
◼ Analizar los cambios solicitados y evaluar 
impactos 
◼ Registrar y documentar las alternativas y 
decisiones tomadas 9
2. Administrar los requerimientos
◼ Los requerimientos pueden ser adecuadamente 
capturados y comunicados a través de Casos de 
Uso 
◼ Los Casos de Uso son importantes instrumentos de 
planificación
Modelo de Diseño
Modelo de Implementación Modelo de Test
verificaRealización influenciados por
Los Casos de Uso 
direccionan el 
trabajo desde el 
análisis hasta el 
test
Modelo de Casos de Uso
10
2. Administrar los requerimientos: 
Beneficios
◼ Las comunicaciones están basadas en 
requerimientos bien definidos
◼ Los requerimientos pueden ser priorizados, 
filtrados y monitoreados
◼ Es posible realizar evaluaciones objetivas 
acerca del éxito de un proyecto
◼ Las inconsistencias se detectan fácilmente
◼ Con herramientas adecuadas: repositorio de 
requerimientos, con atributos y relaciones
11
3. Utilizar Arquitecturas Basadas en 
Componentes
◼ La Arquitectura de Software representa el 
conjunto de decisiones significativas sobre la 
organización de un sistema de software
◼ selección de los elementos estructurales, y sus 
interfaces, por los cuales el sistema está 
compuesto
◼ comportamiento, especificado como 
colaboraciones entre los elementos
◼ composición en subsistemas de los elementos 
estructurales y de comportamiento
◼ estilo de arquitectura que guía a la organización
12
3. Utilizar Arquitecturas Basadas en 
Componentes
◼ La Arquitectura de Software representa el 
conjunto de decisiones significativas sobre 
la organización de un sistema de software
◼ selección de los elementos estructurales, y sus 
interfaces, por los cuales el sistema está 
compuesto
◼ comportamiento, especificado como 
colaboraciones entre los elementos
◼ composición en subsistemas de los elementos 
estructurales y de comportamiento
◼ estilo de arquitectura que guía a la organización
13
3. Utilizar Arquitecturas Basadas en Componentes
Vista 
Lógica
Usuario
Funcionalidad
Vista de 
Implementación 
Programadores
Administración del Software
Vista del 
Proceso
Performance
Escalabilidad
Rendimiento
Integradores
Vista de 
Desarrollo Topología
Distribución, 
Instalación
Comunicación 
Ingeniería 
Conceptual
Física
Vista de Caso de 
Uso
Vistas
14
3. Utilizar Arquitecturas Basadas en 
Componentes
◼ Un componente de software puede definirse como una 
pieza no trivial de software, un módulo o un 
subsistema que completa una función clara, tiene 
límites claros y puede ser integrado en una 
arquitectura bien definida
◼ Realización física de una abstracción en el diseño
System-
software
Middleware
Negocio
Aplicación
Arquitectura basada 
en componentes
15
3. Utilizar Arquitecturas 
Basadas en Componentes
◼ Definir arquitecturas muy modulares e identificar, 
aislar, diseñar, desarrollar y probar componentes bien 
formados
◼ Desarrollar componentes para ser reutilizados. Formar 
la base de reuso de la organización
◼ Industria de infraestructura de componentes
◼ COM+ - Microsoft Component Object Model
◼ CORBA - Common Object Request Broker 
Architecture - OMG
◼ JavaBeans - SUN
16
4. Modelar Software 
Visualmente
◼ Diagramas de Casos de Uso
◼ Diagramas de Clases
◼ Diagramas de Estados
◼ Diagramas de Componentes
◼ Diagramas de Implementación
Código
Clases
Subsistemas
Modelización Visual
eleva el nivel de 
abstracción
17
4. Modelar Software 
Visualmente: Beneficios
◼ Los casos de uso permiten especificar 
comportamiento sin ambigüedades
◼ Quedan expuestas las arquitecturas 
inflexibles o no modulares
◼ El diseño refleja sus inconsistencias 
más rápidamente
◼ Existen herramientas que proveen 
soporte para la modelización visual
18
5. Verificar la Calidad del 
Software
◼ La actividad fundamental de esta práctica es el 
testing
◼ Evaluar continuamente la calidad de un sistema con 
respecto a funcionalidad, confiabilidad, performance
Desarrollo Implementación
Costo
Encontrar y reparar un 
problema de software 
después de la 
implementación 
puede resultar de 100 
a 1000 veces más 
costoso
19
5. Verificar la Calidad del Software: 
Beneficios
◼ La evaluación del estado del proyecto es 
objetiva, se evalúan resultados de test.
◼ Se exponen inconsistencias en 
requerimientos, diseños e implementaciones
◼ Se focaliza en las áreas de riesgo más alto
◼ Los defectos se identifican en forma 
temprana
◼ Existen herramientas automatizadas para el 
testing de funcionalidad, confiabilidad y 
performance 20
6. Controlar los Cambios al Software
◼ Controlar, registrar y monitorear los cambios para posibilitar el 
desarrollo iterativo
◼ Establecer “workspaces” seguros para cada desarrollador 
◼ Automatizar la integración y la administración de “builds”
ALERTREPORT
Workspace
de Administración
Integración
Desarrollo en 
paralelo
Administracióndel Build 
21
6. Controlar los Cambios al Software: Beneficios
◼ Las solicitudes de cambios formales facilitan 
la claridad de comunicación
◼ Los espacios de trabajo aislados reducen la 
interferencia entre los miembros del equipo 
que trabajan en paralelo
◼ Las estadísticas de cantidad de cambios 
proveen buenas métricas para evaluar 
objetivamente el estado del proyecto
◼ La propagación del cambio es evaluable y 
controlable
◼ Los cambios pueden ser mantenidos en 
sistemas automáticos 22
Rational Unified Process (RUP)
Provee: Lineamientos, 
templates para herramientas, 
que guían una implementación 
efectiva de las
6 Mejores Practicas
Controlar 
Cambios
Administrar Requerimientos
Arquitecturas
Basadas en
Componentes
Desarrollar
Iterativamente
Verificar 
Calidad
Modelar
Visualmente
23
El Ciclo de Vida del Software -
Etapas
◼ Concepción
◼ La idea. La visión del producto y su objeto de negocio
◼ Elaboración
◼ Planeamiento de actividades. Recursos. Cualidades. 
Arquitectura
◼ Construcción
◼ Construcción del producto. Evolución de la visión, 
Arquitectura, Planes
◼ Transición
◼ Liberación del producto a la comunidad de usuarios
◼ Evolución
◼ Siguientes versiones
Tiempo
Concepción Elaboración Construcción Transición Evolución
24
El Ciclo de Vida del Software -
Etapas
La “Evolución”
25
El Ciclo de Vida del Software -
Perspectivas
Dos Perspectivas
26
Estructura Estática de RUP
Entorno
Modelado del negocio
Implementación
Pruebas
Análisis & Diseño
Preliminary 
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#
n
Iter.
#
n
Iter.
#
n
Iter.
#
m
Iter.
#
m
Implantación
Gestión de configuraciones
Requerimientos
Elaboration TransitionInception Construction
Administración del proyecto
Flujo de trabajo de Soporte
Flujo de trabajo de Proceso
Fases
27
Rational Unified Process (RUP) y 
UML 
Desarrollados en armonía por 
Rational
RUP y Unified Modeling 
Language (UML)
28