Ingeniería de software II - Parte 2

PARTE 1.1
Metodologías de Desarrollo
Proceso de Desarrollo
Unificado (UP)
Material Académico preparado por:
Ph.D, Marta Silvia Tabares B.
Fecha última actualización: 4-Sep-2011

Ingeniería de Software II
(mapa conceptual de tópicos de conocimiento)

Material Preparado por MARTA SILVIA TABARES B. UdeM

Bibliografía
• Roger Pressman. Ingeniería del Software (6ª ED.). Mcgraw-hill / Interamericana.

• Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and
Design with UML Version 2.0 - An Object Oriented Approach, Second Edition. John
Wiley & Sons © 2005.

• Ivar Jacobson, Grady Booch, James Rumbaugh. El Proceso Unificado de Desarrollo
de Software. Adisson Wesley. 2001.

• Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented
Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.
• OMG-UML. Unified Modeling Language: Superstructure. version 2.0, formal/05-07-
04. 2005.
• Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos
del Sistema, Usando UML. McGraw-Hill, 2006.
• Atención: algunas fuentes de imágenes y otros es colocada anexo a la imagen.


Proceso de Desarrollo
Unificado

Marco de trabajo (framework) genérico
cuyo proceso de desarrollo puede
especializarse para una gran variedad de
sistemas de software, diferentes áreas de
aplicación, diferentes tipos de
organizaciones, diferentes niveles de
aptitud y diferentes tamaños de proyectos

Fuente: Jacobson, I.; Booch, G.; Rumbaugh, J.; (2001).“El
Proceso de Desarrollo Unificado de Desarrollo de Software.
Adisson Wesley.

Proceso Unificado + OpenUP

Material Preparado por MARTA SILVIA
TABARES B. UdeM

Modelo base del Proceso Unificado
MODELO ESPIRAL [Boehm, 1988]

Costo
Acumulado

1. Determinar Objetivos, Progreso
restricciones y a través de pasos 2. Análisis y prevención
alternativas R del riesgo

Evaluación de
Riesgo
Definición Costo
Acumulado
Prototipos
Compromiso,
R R
partición Simulación, modelos,
benchmarks
Planeación Desarrollo,
próxima verificación
fase producto
4. Planificación siguiente nivel 3. Desarrollo del
y dirección R producto

R = Revisión

TABARES B. UdeM

Modelo Espiral Win-Win
del proceso de desarrollo de software [Boehm, 1989]

2. Identifique
Las condiciones de triunfo de
los grupos de participantes

3. Reconcilie
1. Identifique condiciones de triunfo.
los grupos de participantes Establezca objetivos, restricciones
del siguiente nivel y alternativas del siguiente nivel

7. Revisión y Compromiso
4. Evalúe alternativas
de producto y proceso.
6. Valide definiciones Resuelva riesgos.
de producto
y proceso 5. Defina siguiente nivel
de producto y proceso – incluyendo particiones

TABARES B. UdeM

Los 4 ejes del desarrollo de Software
• Los principales autores de un proyecto de software son ingenieros de requisitos, los arquitectos, desarrolladores,
ingenieros de prueba, además de otros stakeholders tales como clientes, usuarios, proveedores, entre otros.
Personas

• Es el elemento que permite organizar y gestionar la ejecución del desarrollo del software. Se organiza a partir de
un EDT como la Estructura de Desglose del plan de Trabajo. EDT un agrupamiento de los elementos de un
Proyecto proyecto orientado hacia los entregables, cuyo objetivo es organizar y definir el alcance total del proyecto.

• Los productos son artefactos que se crean durante la vida del proyecto. Son entregables tales como modelos,
código fuente, ejecutables, y documentación.
• El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida e un sistema. Cada ciclo
Producto consta de sus cuatro fases : inicio, elaboración, construcción y transición.
• Cada ciclo concluye con una VERSIÓN del producto para los clientes. Cada fase se subdivide a su vez en
iteraciones.

• El proceso de ingeniería de software es un conjunto completo de actividades necesarias para transformar los
requisitos de usuario en un producto software. Un proceso es una plantilla para crear proyectos.
Proceso

Estos 4 ejes del desarrollo del software están soportados por Herramientas de Software tales como CASE, IDE,
Frameworks para automatizar las actividades definidas en el proceso.


El Proceso de Desarrollo Unificado* (1)
• Es un Proceso de Desarrollo, es decir es un conjunto de
actividades necesarias para transformar los requisitos de un usuario en
un sistema software.

• Es un Marco de Trabajo genérico que puede especializarse para una
gran variedad de sistemas de software.

• Está basado en Componentes, es decir que el sistema software en
construcción está formado por componentes de software
interconectados a través de interfaces bien definidas.

• Utiliza el Lenguaje Unificado de Modelado (UML) para preparar
todos los esquemas de un sistema de software.

• Dirigido por Casos de Uso, Centrado en la Arquitectura, Iterativo e
Incremental.
* Unified Process – en inglés.
* Rational Unified Process (RUP)– Producto Comercial de la IBM.


El Proceso de Desarrollo Unificado (2)

1. Dirigido por REQUISITOS y RIESGOS

– Significa que los Casos de Uso son la herramienta de
modelado primaria para definir el comportamiento del
sistema. Ellos son una forma de capturar los requisitos.

• Los casos de uso son usados para identificar y comunicar los
requisitos del sistema a los desarrolladores y cómo se debe
escribir el sistema.



2. Centrado en la ARQUITECTURA

• Significa que la arquitectura de software subyacente a la
especificación del sistema de desarrollo conduce la
especificación, la construcción, y la documentación del
sistema.

• La arquitectura surge de las necesidades de la empresa, como las
perciben los usuarios y los patrocinadores del proyecto. Además, se
ve influenciada por factores tales como la plataforma en la que tiene
que funcionar el software (arquitectura hardware, sistema operativo,
sistema de gestión de base de datos, protocolos para las
comunicaciones en red, etc.).

TABARES B. UdeM

Centrado en la Arquitectura
• El análisis de sistemas orientado por objeto moderno y los acercamientos de
diseño deben apoyarse al menos en tres vistas arquitectónicas (separadas
pero interrelacionadas) de un sistema: funcional, estática, y dinámica.

• Vista Funcional: describe el comportamiento externo de el sistema desde
la perspectiva del usuario.
• Los casos de uso y sus diagramas son la primera aproximación usada
para representar la vista funcional. En algunos casos también son
usados como complemento a los casos de uso.

• Vista Estática: describe la estructura del sistema en términos de
atributos, métodos, clases, y relaciones.
• Los diagramas estructurales retratan la vista estática de un sistema
de información orientado por objeto que evoluciona.

• Vista Dinámica: describe el comportamiento interno del sistema en
términos de mensajes pasados entre los objetos, y cambios de estado
dentro de un objeto.
• Los diagramas de comportamiento representan la vista dinámica.

Centrado en la Arquitectura
• Las arquitecturas del sistema son usadas por diversos conjuntos de
personas en tiempos diferentes en el ciclo de desarrollo, por esta razón
es frecuente ver que estas arquitecturas son separadas en vistas
diferentes.

• El Proceso Unificado Racional (RUP) identifica un conjunto
de vistas estándar llamado 4+1 Vistas de Arquitectura.

• Este enfoque permite que todos los grupos de participantes
comuniquen las necesidades (es decir, requisitos), resuelvan los
conflictos, y realicen los documentos de decisiones.


Centrado en la Arquitectura: 4+1 Views (Philippe Kruchten)

Logical View Implementation View

End-users/Analysts/Designers Programmers
Functionality Configuration management
Use Case View

Process View Deployment View
System integrators System engineering
Performance System topology
Scalability Delivery, Installation,
Throughput Communication

Conceptual Physical
Figura tomada de: Clements, et al, Documenting Software Architectures


Centrado en la Arquitectura: 4+1 Views
• El +1 se refiere a la Vista de Casos de Uso, la cual contiene los casos de uso clave
(base) que dirigen la arquitectura. Las otras cuatro vistas son:

• Vista Lógica: describe la estructura del software y es usada para identificar los paquetes más
importantes del diseño, clases, y otros elementos.

• Vista de Procesos: orienta los aspectos actuales del sistema en tiempo de ejecución: tareas,
hilos, procesos y sus interacciones.
•
• Vista de Desarrollo: muestra cómo los diferentes ejecutables y otros componentes en
tiempo de ejecución son mapeados en plataformas subyacentes o nodos de cómputo.
•
• Vista de Implementación: proporciona la organización estática del software en términos de
empaquetamiento, capas (layering), y dirección de configuración.

Atención:
Profundizar en este tema en presentación: Arquitectura 4 mas una vista



3. ITERATIVO E INCREMENTAL
– El desarrollo iterativo e incremental que se somete a pruebas continuas
y refinamiento en todas partes de la vida del proyecto. Cada iteración
del sistema lo trae más cerca y más cerca a verdaderas necesidades de
usuario.

– Cuando se desarrolla un producto de software es práctico dividir el
trabajo en partes más pequeñas o mini-proyectos.

– Cada mini-proyecto es una ITERACIÓN que resulta en un incremento.

– Cada Iteración genera una línea base que compromete una versión
parcial completa del sistema final incluyendo cualquier documentación
asociada al proyecto.

– La diferencia entre dos líneas base consecutivas se conoce como un
incremento.

Iterativo e Incremental
• Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al
crecimiento del producto.

• Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y
ejecutarse de una forma planificada, por esto se consideran mini-proyectos.

• La iteración trata un grupo de casos de uso que juntos amplían la utilidad del
producto desarrollado hasta un momento determinado del ciclo de vida.

• Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal y
como quedaron al final de la última iteración.

• Una iteración comienza con los casos de uso y continúan a través del trabajo de
desarrollo subsiguiente: análisis, diseño, implementación, pruebas e
implementación (de los casos de uso de dicha iteración).

• Un INCREMENTO es la diferencia entre la versión interna de una iteración y la
versión interna de la siguiente.


Iterativo e Incremental

Implemen
Requisitos Análisis Diseño Pruebas
tación

Una
ITERACIÓN

CADA ITERACIÓN CONSTITUYE UNA PASADA A TRAVÉS DE LOS CINCO FLUJOS DE
TRABAJO (DISCIPLINAS) FUNDAMENTALES


Interacción y Flujos de trabajo (workflows)

• Cinco (5) flujos de trabajo especifican qué necesita ser hecho y qué habilidades
son necesarias en cada iteración.

• Flujos de Trabajo:

– Requisitos: se captura lo que el sistema debe hacer.

– Análisis: se refinan y estructuran los requisitos.

– Diseño: se realizan los requisitos en la arquitectura del sistema.

– Implementación: se construye el software.

– Prueba: se verifica que los trabajos de implementación estén acorde a los
requisitos.


Detalle del Proceso Iterativo e Incremental

Figura tomada de: Building J2EE Applications with the Rational Unified Process. Addison-Wesley. 2003


Roles

Usuarios

Arquitecto
Ingenieros
de Pruebas
SISTEMA

Jefe de Proyecto
Diseñadores

Analistas


Fases del Proceso Unificado
INICIO

• Inicio (Inception): objetivos del ciclo de vida
– Descripción del producto final y se presenta el análisis de negocio para el producto.
• Objetivos:
– Establecer la factibilidad del proyecto.
– Crear un caso de negocio para demostrar que el proyecto traerá beneficios
económicos.
– Capturar los requisitos esenciales para ayudar a alcanzar el sistema.
– Identificar riesgos críticos.
• Roles:
– Jefe del Proyecto
– Arquitecto del Sistema
– Requisitos
– Análisis
– Diseño e Implementación son actividades soportadas por los prototipos.


ELABORACIÓN
• Elaboración (Elaboration): arquitectura del ciclo de vida.

• Se especifican la mayoría de los casos de uso del producto y se diseña la
arquitectura del sistema.
• Objetivos:
• Crear una línea base arquitectónica ejecutable.
• Refinar la evaluación del riesgo
• Definir los atributos de calidad
• Especificar los casos de uso para el 80% de los requisitos funcionales.
• Crear un plan detallado para la fase de construcción.
• Roles:
• Analista
• Diseñador
• Arquitecto
• Requisitos: refina el alcance del sistema y los requisitos.
• Análisis: establecer qué se va a construir
• Diseño: crear una arquitectura estable.
• Implementación: construir la arquitectura base.
• Prueba: Probar la línea base arquitectónica.


CONSTRUCCIÓN

• Construcción (Construction): Capacidad Operativa Inicial.
• Se completan todos los requisitos, análisis, y diseño; además evoluciona la línea base
arquitectónica generada en la Elaboración del sistema final.
• Objetivos:
Mantener la integridad de la arquitectura del sistema.
Refinar la evaluación del riesgo
Desarrollar los productos a ser liberados
Hacer la integración de subsistemas
Realizar pruebas de unidad
Realizar pruebas de integración.
• Roles:
• Diseñador
• Ingenieros de Prueba
• Arquitecto
• Requisitos: descubre requisitos perdidos.
• Análisis: termina el modelo de análisis.
• Diseño: termina el modelo de diseño.
• Implementación: construye la capacidad operativa inicial.
• Prueba: pruebas la capacidad operativa inicial.


TRANSICIÓN
• Transition (Transición): Liberación del Producto.
• Inicia cuando la prueba Beta se completa y el sistema finalmente se desarrolla. Corrige errores encontrados
en las pruebas Beta y prepara la versión de producto de salida en el lugar de los usuarios.
• Objetivos:
Corregir errores.
Preparar los equipos y lugares de usuarios donde operará el nuevo sistema.
Modificar el software si aparecen problemas inesperados.
Crear manuales de usuarios y documentación necesaria para entregar el producto.
Proporcionar consultoría a los usuarios
Orientar una revisión de puesta en marcha del proyecto.
• Roles:
• Ingenieros de Prueba
• Arquitecto
• Requisitos: no aplica.
• Análisis: no aplica.
• Diseño: modificación del diseño si los problemas emergentes en la prueba Beta lo ameritan.
• Implementación: adaptar el software para el lugar de los usuarios y corregir problemas no
descubiertos en las pruebas Beta.
• Prueba: pruebas Beta y aceptación de las pruebas en el lugar del usuario.


Proceso Unificado: Objetivos, Documentos,
Entregables

Fuente:
IIE Instituto de Ingeniería Eléctrica.DesaSoft
Desarrollo de Software para Ingeniería
Eléctrica.Guías de clase. Parte II: Ingeniería de
Software.

TABARES B. UdeM

Fase de INICIO UP: Objetivos, Documentos,
Entregables

Fase Objetivos Generales Documento/Modelo Documento/Modelo
de la Fase Fuente Producto de Trabajo
Inicio - Tomar decisiones - Modelo del negocio - Documento de visión
tecnológicas - Documento
- Modelar el negocio descriptivo del negocio
- Capturar requisitos - Documento de
- Identifica el riesgo crítico evaluación del riesgo
- Modelo de requisitos
funcionales
- Modelo de casos de
uso
- Modelo del dominio
- Prototipos desechables
- Arquitectura candidata


Fase de INICIO UP: Objetivos, Documentos,
Entregables

Fuente:
IIE Instituto de Ingeniería Eléctrica.DesaSoft Desarrollo de Software para Ingeniería Eléctrica.Guías de clase. Parte II: Ingeniería de Software.


Fase de ELABORACIÓN UP: Objetivos,
Documentos, Entregables
Fase Objetivos Generales Documento/Modelo ARTEFACTO
Elaboración - Crear arquitectura - Documento de visión - Documento de visión
ejecutable - Documento de refinado
- Evaluar el riesgo evaluación del riesgo - Documento de
- Especificar los atributos de - Modelo de Requisitos evaluación del riesgo
calidad - Modelo de casos de uso refinado
- Especificar - refinar casos - Arquitectura candidata - Modelo de requisitos
de uso No-funcionales
- Crear del plan detallado de - Modelo de casos de
la fase de construcción uso
- Analizar el costo-beneficio arquitectónicamente
del sistema solución significativos
- Modelo de Clases
- Modelo de
componentes
- Esquema de la base de
datos
- Prototipos definitivos
- Arquitectura
ejecutable
- Modelo de Pruebas

Fase de ELABORACIÓN UP: Objetivos,

Fuente:
IIE Instituto de Ingeniería Eléctrica.DesaSoft Desarrollo de Software para Ingeniería Eléctrica.Guías de clase. Parte II: Ingeniería de Software.


Fase de CONTRUCCIÓN UP: Objetivos,

Construcción - Desarrollar los productos - Arquitectura ejecutable - Modelo de Despliegue
a ser liberados refinada - Programas de Software
- Hacer la integración de - Modelo de componentes de la solución
subsistemas - Esquema de la base de - Resultados de pruebas
- Realizar pruebas de datos de unidad
unidad
- Realizar pruebas de
integración


Fase de TRANSICIÓN UP: Objetivos,
Transición - Ejecutar pruebas - Modelo de Despliegue - Resultado de pruebas
operativas del sistema - Modelo de Componentes funcionales y de la
- Corregir errores de refinado capacidad operativa del
construcción - Esquema de la base de sistema
- Hacer pruebas para datos refinado - Manuales de usuario
liberación de productos de - Programas de software a - Manuales de operación
trabajo ser liberados del sistema
- Documento con plan
de implantación


Ingeniería de software II - Parte 2

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Ingeniería de software II - Parte 2

Similaire à Ingeniería de software II - Parte 2 (20)

Plus de Marta Silvia Tabares

Plus de Marta Silvia Tabares (20)

Dernier

Dernier (10)

Ingeniería de software II - Parte 2