1

Elementos de la Ingeniería de Software

Estrategia de desarrollo de software

2

Ingeniería de Software: un enfoque multicapa (Pressman)

Procesos

Métodos & técnicas

Herramientas

Calidad

AproximaciónMetodológica

Notación

Modelo de desarrollo

3

Elementos del proceso de desarrollo

• Modelo de desarrollo : Estrategia gerencial que orienta el desarrollo del proyecto

• Aproximación metodológica : Según el enfoque de modelamiento utilizado para describir la realidad

• Notación / técnica : Conjunto de diagramas utilizados para describir el sistema

• Metodo : Proceso disciplinado para generar un modelo, utilizando una notación bien definida

4

El modelo de desarrollo (Pressman)

Cascada / Lineal Prototipado DRA (Rapide Application Development) Incremental Espiral Modelo orientado a componentes Modelo con énfasis en reutilización Rational Unify Process - RUP (Rational)

5

El modelo lineal secuencial

Análisis Diseño Código Prueba

Ingeniería de Sistemas/Información

6

E Modelo de Prototipado

Escuchar alCliente

Construír yRevisar Maqueta

El cliente prueba la maqueta

7

El modelo DRA

Modelado degestión

Modelado dedatos

Modelado deprocesos

Generación de aplicaciones

Pruebas yvolumen

Modelado degestión

Modelado dedatos

Modelado deprocesos

Generación deaplicaciones

Pruebas y volumen

Modelado degestión

Modelado dedatos

Generación deaplicaciones

Modelado deprocesos

Modelado degestión

Equipo # 1 Equipo # 2 Equipo # 3

De 60 a 90 días

8

El modelo incremental

Análisis Diseño Código Pruebas

Análisis

Análisis

Diseño Código Pruebas

Diseño Código Pruebas

Ingeniería de Sistemas/Información

Tiempo de calendario

Incremento 1

Incremento 2

Incremento 3

9

Modelo espiral (Boehm)Planificación

Análisis deriesgos

Ingeniería

Construcción yadaptación

Evaluación del cliente

Punto deentrada al Proyecto

Comunicación con el cliente

A B CD

A: Desarrollo de Conceptos B: Desarrollo de ProductosC: Mejora de Productos D: Mantenimiento de Productos

10

El modelo de ensamblaje de componentes

Planificación Análisis de riesgos

Construcción y adaptación(ingeniería)

Evaluación del cliente

Comunicación con el cliente

Identificar componentescandidatos

Construir ninteracciones

del sistema

Buscar componentesen Biblioteca

Poner componentesnuevos en la

biblioteca

Extraer componentes

si están disponibles

construircomponentessi no están disponibles

11

Modelo orientado a la reutilización

Ingeniería de Dominios

Ingeniería de Software

Análisis delDominio

Definición dela Arquitectura

Construcción /Generalización

Modelo deldominio

Modelo Estructural

Bibliotecade

Componentes

Análisis delSistema

Especificacióny diseño

ConstrucciónRequisitos del usuario

12

Aproximación metodológica En el enfoque estructurado

• Orientadas a datos

• Orientadas a procesos

• Híbrida

En el enfoque objetual• Behavior-Driven

• Data-Driven

13

Aproximación Orientada a Procesos

datos 1

datos 3 datos 4

datos 2

proceso 1 proceso 2

proceso n

14

Aproximación Orientada a Datos

datos 3

datos 4

datos 1

datos 2

proceso 1 proceso 2

proceso n

“A menudo encontramos que construir primeramente el modelo de datos, hace más fácil descubrir

cuáles son las funciones requeridas” (Yourdon)

15

Aproximación Híbrida

Recopilación

Análisis de datos

especificación de datos

modelo de datos

diseño lógicode la BD.

Diseño Físico de la BD.

Análisis de procesos

modelo de procesos

especificaciónde procesos

Diseñode transacciones

Diseñode Programas

16

Perspectivas de modelamiento desde el punto de vista objetual

Estructural - propiedades (anatómico)

Funcional - estado(fisiológico)

Dinámico - colaboraciones(social)

Deóntico - reglas(moral)

17

Notación o Técnica En el enfoque estructurado

• Diferentes notaciones para diferentes etapas del ciclo de vida

• Diferentes propuesta notacionales

En el enfoque objetual• La misma notación para todas las etapas del ciclo de

vida

• Antes de UML: diferentes propuestas notacionales (Booch, Rumbaugh, Jacobson, etc.)

• Después de UML: Lenguaje unificado

18

Introducción al Proceso Unificado Orígenes

• Modelo original Objectory definido por Ivan Jacobson (1987)

• Rational Software compra la empresa de Objectory (1995)

• Surge la primera versión de UML (1997)

• Se publica la primera versión del Proceso Unificado de Rational - RUP (junio 1998)

19

Características del proceso unificado

Dirigido por casos de uso

• Se centra en la funcionalidad que el sistema debe poseer para satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interactua con él

• Casos de uso como el hilo conductor que orienta las actividades de desarrollo

Casos de Uso

AnálisisRecopilar,

Clarificar y Validar los

requerimientos

Diseño

Realizar loscasos de uso

Pruebas

Verificar que sesatisfacen los casos de uso

<<realiza>> <<verifica>><<defineNecesidades>>

20

Características del proceso unificado Centrado en la arquitectura

• Concepto similar a la arquitectura de un edificio

• Varios planos con diferentes aspectos del edificio

• Tener una imagen completa del edificio antes que comience la construcción

• Arquitectura en sofware

• Diferentes vistas del sistema: estructural, funcional, dinámico, etc.

• Plataforma en la que va a operar

• Determina la forma del sistema

• Arquitectura: determina la forma del sistema

• Casos de uso: determinan la función del sistema

21

Características del proceso unificado Iterativo e incremental

• Descomposición de un proyecto grande en mini-proyectos

• Cada mini-proyecto es una iteración

• Las iteraciones deben estar controladas

• Cada iteración trata un conjunto de casos de uso Ventajas del enfoque iterativo

• Detección temprana de riesgos

• Administración adecuada del cambio

• Mayor grado de reutilización

• Mayor experiencia para el grupo de desarrollo

22

Rational Unify Process (RUP) -Dimensiones

Dinámica• Ciclo: cada ciclo una nueva versión del producto

• Fase: Etapas de un ciclo que finalizan en un HITO

• Iteración: Proceso de ingeniería sobre una funcionalidad limitada del sistema

Estática - Flujos de trabajo • Artefactos

• Actividades

• Roles

23

Dimensión estática del proceso Roles QUIÉN? Actividades CÓMO? Artefactos QUÈ? Flujo de Trabajo CUÁNDO?

realiza

responsable dediseñador

diseño de casode uso

diagrama de secuencia

24

Rol Definición del comportamiento y

responsabilidades de los participantes Propietario de una serie de artefactos

Recurso Rol Actividad Artefacto

Diseñador Diseño de Objetos DCAnalista Definición de CU DCUDominioDiseñador Diseño de CU DSFuncional

PatriciaJuanMónicaPedro

25

Actividad Unidad de trabajo que puede ejecutar un individuo en un

rol específico Tiene un propósito claro y se expresa en términos de

actualizar artefactos La granularidad de la actividad es generalmente de horas

o pocos días Ejemplos de actividades

• Planear una iteración (administrador del proyecto)

• Encontrar caso de uso y actores (analista del dominio)

• Revisión del diseño (probador)

26

Artefacto Pieza de información producida, modificada y

utilizada en un proceso Productos tangibles del proyecto Utilizados por los roles como entrada para la

realización de sus actividades Resultado de las actividades realizadas por los

roles Metamodelo: Clase rol tiene como métodos las

actividades y como parámetros los artefactos

27

Flujo de trabajo Forma de describir significativamente la secuencias de

actividades que producen resultados y las interacciones entre cargos

En términos de UML se puede utilizar: diagrama de actividades, de secuencia, de colaboración

En RUP hay nueve tipos de flujos de trabajo• De ingeniería

• Negocio, Requerimiento, Análisis, Diseño, Pruebas, Liberación

• De soporte• Administración del proyecto, Administración del cambio,

Ambiente

28

Dimensión dinámica del proceso

Concepción Elaboración Construcción Transición

ciclofase

Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6

hito 1 hito 2 hito 3 hito 4

Hito: punto en el tiempo en donde se evaluan objetivoslogrados y se pueden tomar decisiones críticas

29

Desarrollo iterativo

Ciclo dedesarrollo 1

Ciclo dedesarrollo 2

Ciclo dedesarrollo n

Perfeccionarel plan

SincronizarArtefactos

Análisis Diseño Construcción Pruebas

Construcción

30

Fase Concepción Objetivo: definir la razón de ser y el alcance

del proyecto. Estudio de oportunidad.• Visión = QUÉ + PARA QUÉ + CUÁNTO

Actividades• Especificación de los criterios de éxito del proyecto

• Definición de los requerimientos

• Estimación de los recursos necesarios

• Cronograma inicial de fases Artefactos

• Documento de definición del proyecto

31

Fase Elaboración Objetivo: establecer un plan de proyecto y una

arquitectura correcta del sistema Actividades

• Análisis del dominio del problema• Definición de la arquitectura básica • Análisis de riesgos• Planificación del proyecto

Artefactos• Modelo del dominio• Modelo de procesos• Modelo funcional de alto nivel• Arquitectura básica

32

Fase Construcción Objetivo: desarrollar el sistema a lo largo

de una serie de iteraciones Actividades

• Análisis

• Diseño

• Codificación

• Pruebas (individuales, de integración)