EL PROCESO DEL SOFTWARE

MGR. KARIN SUPO GAVANCHO

 Conceptos importantes

Personas: los que trabajan

Producto: lo que se obtiene
Proyecto: la pauta a seguir para desarrollar un
producto
 Proceso: la pauta a seguir para desarrollar un
proyecto
EJEMPLOS
 Capas de la IS

Capa de enfoque de calidad

Capa de proceso
Capa de métodos
Capa de herramientas
 Capas de la IS

Capa de calidad
Base de cualquier proceso de ingeniería
La IS se basa en calidad
 Mejores técnicas de construcción de software
Capa de proceso
Capa que une calidad y métodos
 Desarrollo racional de la IS
Conjunto de actividades y resultados asociados que
sirvenpara construir un producto software
 Capas de la IS

Capa de métodos
 Un método incluye:
 Análisis de requisitos
 Diseño
 Construcción de programas
 Prueba
 Mantenimiento
 Suelen estar bastante ligados al proceso
Capa de herramientas
 Soporte automático o semiautomático para el proceso y los
 Métodos
 Herramientas CASE: Computer Aided Software Engineering
 Visión general de la IS

Ingeniería: análisis, diseño, construcción y verificación

de entidades técnicas (o sociales)
La entidad caracteriza a la ingeniería:
Caminos, canales y puertos
Aeronaves
Buques
 Visión general de la IS

Con independencia de la entidad debemos identificar y

solucionar:
 Problema a resolver
 Características de la entidad
 Forma de construir la entidad
 Enfoque para resolver los errores cometidos durante el diseño
y construcción de la entidad
 Mantenimiento de la entidad frente a su evolución
 Visión general de la IS

En IS entidad = software.

Soporte para el desarrollo de la entidad/soporte para
la IS: modelo de proceso.
Con independencia del modelo de proceso hay tres
fases genéricas:
 Fase de definición
 Fase de desarrollo
 Fase de mantenimiento
Cada una de estas fases se descompone en un
conjunto de tareas
 Visión general de la IS

Fase de definición/especificación
 Centrada en el QUÉ
 Se identifican los requisitos del sistema y software:
 Información a procesar
 Función y rendimiento deseados
 Comportamiento del sistema
 Interfaces establecidas
 Restricciones de diseño
 Tareas principales:
 Planificación del proyecto software
 Ingeniería de sistemas o de información
 Análisis de requisitos
 Visión general de la IS

Fase de desarrollo
 Centrada en el CÓMO
 Se definen:
 Cómo han de diseñarse las estructuras de datos
 Cómo han de implementarse las funciones
 Cómo han de caracterizarse las interfaces
 Cómo debe traducirse el diseño a un lenguaje de
programación
 Cómo ha de validarse el producto (pruebas, verificación)
 Tareas principales:
 Diseño del software
 Generación del código
 Pruebas del software
 Visión general de la IS

Fase de mantenimiento
 Centrada en cambios que se pueda necesitar realizar sobre un
producto
 En esta fase se vuelven a aplicar las fases de definición y
desarrollo, pero sobre software ya existente
 Pueden producirse cuatro tipos de cambio:
 Corrección: Corregir los defectos
 Adaptación: Modificaciones por cambio en el entorno externo
(CPU, SO, etc.)
 Mejora: Ampliar los requisitos funcionales originales, a petición
del cliente
 Prevención: Cambio para facilitar el cambio
 Visión general de la IS

 Estas fases se complementan con las actividades de

soporte
 No crean software
 Mejoran su calidad
 Facilitan su desarrollo
 Se aplican a lo largo de todo el proceso del software
 Ejemplos de actividades de soporte
 Documentación
 Gestión de configuración
 Seguimiento y control del proyecto de software
 Revisiones técnicas formales
 Garantía de la calidad del software
 Gestión de reutilización
 Mediciones
 Gestión de riesgos
 Proceso del software

Conjunto estructurado de actividades y resultados

asociados requeridos para desarrollar un sistema de
software.
 Especificación: establecer los requisitos y restricciones del sistema
 Diseño: Producir un modelo en papel del sistema
 Implementación: construcción del sistema de software
 Validación: verificar (por ejemplo mediante pruebas) que el sistema
cumple con las especificaciones requeridas
 Instalación: entregar el sistema al usuario y asegurar su
operacionalidad
 Evolución y mantenimiento: cambiar/adaptar el software según las
demandas; reparar fallos en el sistema cuando sean descubiertose
Las actividades varían dependiendo de la organización y
del tipo de sistema a desarrollar
Debe estar explícitamente modelado si va a ser bien
administrado
 Modelos de proceso

Un modelo de proceso, o paradigma de IS, es una

plantilla, patrón o marco que define el proceso través
del cual se crea software
Dicho de otra forma, los procesos son instancias de
un modelo de proceso
En esta asignatura los términos proceso y modelo de
proceso se utilizan indistintamente
Una organización podría variar su modelo de
proceso para cada proyecto, según:
 La naturaleza del proyecto
 La naturaleza de la aplicación
 Los métodos y herramientas a utilizar
 Los controles y entregas requeridas
 Características del proceso

 Entendible
 Visibilidad
 Grado en que las actividades del proceso proporcionan resultados
 Soportable por herramientas CASE
 Aceptabilidad
 Grado en que los desarrolladores aceptan y usan el proceso
 Fiabilidad
 Capacidad de evitar o detectar errores antes de que sean defectos
 Robustez
 Continuidad del proceso a pesar de los problemas
 Mantenible
 Capacidad de evolución para adaptarse
 Rapidez
 Velocidad en que el proceso puede proporcionar un sistema a partirde una
especificación
 Modelos de proceso que no son...

Modelo de caja negra (code and fix)

 Codificar y corregir no es un modelo de proceso
 No se pierde el tiempo en la planificación, en la calidad, en los documentos
que hay que realizar cuando se terminan etapas o en cualquier otra actividad
que no sea la codificación. Por lo tanto este modelo no se necesita tener
experiencia y una gran cantidad de conocimientos.
 Al no seguir un modelo no tenemos ningún medio de
ver si se cumplen las expectativas creadas, lo cual es
un problema si encontramos un error casi al finalizar el
proyecto ya que hay que empezar de nuevo. Por
consiguiente tardamos más en ver los errores que en
otro modelo que sigue un mínimo de planificación
 No es lo mismo que Extreme Programming (XP)
 Modelos de proceso que no son...

El modelo del Caos

 El desarrollo de software se caracteriza como un
bucle de resolución de problemas con cuatro
etapas:
 Status Quo. Estado actual de procesos
 Definición de problemas. Identifica el problema
 Desarrollo técnico. Resuelve el problema
 Integración de soluciones. Ofrece los resultados
Bucle de resolución de problemas
 Bucle de resolución de problemas

Nótese que estas etapas son asimilables con

las fases de IS presentadas
Aplicación recursiva del bucle sobre sí mismo:
modelo del caos
El problema es que las fases de IS interactúan
más que lo mostrado por esta aproximación
Modelo del caos
 Modelos de Proceso del Software

Modelo de Cascada
 Separar en distintas fases de especificación y desarrollo que
se realizan en secuencia lineal.
Desarrollo Evolutivo
 La especificación y el desarrollo están intercalados
Prototipado
 Un modelo sirve de prototipo para la construcción del
sistemafinal
Transformación Formal
 Un modelo matemático del sistema se transforma
formalmente en la implementación
Desarrollo basado en Reutilización
 El sistema es ensamblado a partir de componentes
existentes
 Modelo en cascada (waterfall)

Es el modelo de proceso clásico (desde los ’70)

Basado en la mentalidad de línea de ensamblaje
Es sencillo y fácil de entender
El proyecto pasa a través de una serie de fases
 Al final de cada fase se revisan las tareas de trabajo y
productos
 Para poder pasar a la siguiente fase se tiene que haber
conseguido todos los objetivos de la fase anterior
 No hay apenas comunicación entre las fases
Modelo en cascada (waterfall)
 Modelo en cascada (waterfall)

 Fases:
 Conceptualización: Se determina la arquitectura de la
solución (i.e. división del sistema en subsistemas
+comunicación)
 Análisis de requisitos: Básicamente se definen los
requisitos funcionales y de rendimiento
 Diseño: Representación de la aplicación que sirve de guía a
 la implementación
 Implementación: Transforma el diseño en código
 Prueba: Validación e integración del software y de los
 sistemas
 Instalación y comprobación: Se instala al cliente, el cual
 comprueba la corrección de la aplicació
 Modelo en cascada (waterfall)

 Se tiene un seguimiento de todas las fases del proyecto y del

cumplimiento de todos los objetivos marcados en cada etapa
tanto de costes como fechas de entrega
 Al final de cada etapa se debe comprobar si el proyecto
cumple todas las necesidades del usuario
 Esto es un problema ya que si el cliente se da cuenta de que falta alguna
función una vez pasada esta etapa, el trabajo que hay que realizar se
retrasa en fechas de entrega y el coste es mayor
 Por este motivo se puede modificar el modelo en cascada pudiendo pasar
de una etapa a la anterior
 Difícil ya que hay que rehacer la etapa anterior (modelo de ciclo de vida del
salmón)
 El rendimiento puede mejorar notablemente variando el
modelo de la cascada pura (cuando no hay solapamientos
entre las fases):
 Solapamientos de fases (Modelo Sashimi)
 Modelo en cascada (Sommerville)

El sistema se pone en funcionamiento durante la fase

final del proyecto
 Entonces se descubren errores en diseño y programación, y
omisiones en los requisitos originales
 Para adaptar los cambios requeridos hay que repetir algunas o
todas las etapas del proceso
 Modelo lineal secuencial (Pressman)

Ingeniería de sistemas
 Al ser el software parte de un sistema más grande el trabajo
comienza estableciendo requisitos de todos los elementos del
sistema y asignando al software una parte de estos requisitos
 Modelo en cascada (waterfall)

Posibles ventajas:
 Sencillo
 Sirve cuando el personal está poco cualificado
 Aplicable cuando el problema es estable y cuando se trabaja con
técnicas conocidas
 Por ejemplo, será apropiado para la migración de una aplicación o
para generar una nueva versión de mantenimiento bien definida
Críticas:
 No se ve un producto hasta muy tarde en el proceso
 Un error grave en las últimas fases puede ser letal
 Especificación de requisitos estable
 Impone una estructura de gestión de proyectos
 Fases muy rígidas
 Las revisiones de proyectos de gran complejidad son muy difíciles
MODELO DE PROCESO INCREMENTAL
 Modelo Incremental
35

Combina lineal secuencial (aplicado

repetidamente) con filosofía interactiva de
construcción de prototipos.
Cada iteración devuelve un
“Incremento” o versión operativa.
Útil cuando no se está seguro de
cumplir con plazos de tiempo o se tiene
una fecha imposible de cambiar.
 Modelo Incremental
36

Entre
Inc Análisi Diseño Codif. Prueba
ga 1er
1 s Inc.

Entreg
Inc Análisi Diseño Codif. Prueba
a 2do
2 s Inc.

Entreg
Inc Análisi Diseño Codif. Prueba
a 3er
3 s Inc.
Tiempo
 MODELO INCREMENTAL

Cada secuencia lineal secuencial produce un

incremento del software
 Un incremento es un producto operacional de una parte del
sistema
El primer incremento suele ser un producto esencial
o núcleo
 Requisitos básicos
 Muchas funciones suplementarias se dejan para después
 Se evalúa (p.ej., por el cliente) el producto entregado n Como
resultado se desarrolla un plan para el incremento siguente
Se itera
 Hasta elaborar el producto completo
 Modelo de Desarrollo Rápido de
Aplicaciones (DRA)

 Basado en el Modelo Lineal Secuencial

 Modelo llevado a cabo por varias equipos de trabajo
que siguen las etapas del proceso de manera
simultanea.
 Modelo aplicable a la construcción de sistemas de
información fácilmente modularizables.
 El Modelo DRA necesita clientes y desarrolladores
comprometidos con el proceso.
 No es muy útil para aplicaciones que requieren
adopción de nuevas tecnologías porque la curva de
aprendizaje puede afectar el cronograma del proyecto.
Modelo de Desarrollo Rápido de
Aplicaciones (DRA)
 Modelo de Desarrollo Rápido de
Aplicaciones (DRA)

Ventajas
 Rapidez
 Válido para aplicaciones modularizables
Inconvenientes
 Exige conocer bien los requisitos y delimitar el ámbito del
proyecto
 Proyectos grandes => gran nro. de personas.
 Alto compromiso en tiempo
 Gestión riesgos técnicos altos
 Uso de nueva tecnología
 Alto grado de interoperabilidad con sistemas existentes
 Modelos de proceso Evolutivos
41

Se adaptan más fácilmente a los cambios

introducidos a lo largo del desarrollo.
Iterativos
En cada iteración se obtienen versiones más
completas del SW.
Modelos Evolutivos:
 Construcción de Prototipos
 Modelo en Espiral
 El modelo de desarrollo concurrente
Construcción de Prototipos
 Construcción de Prototipos

Comienza con una recolección inicial de requisitos para

pasar a un diseño rápido y finalmente a la construcción
de un prototipo de la solución.

43
 Construcción de Prototipos

El desarrollador y el cliente deben ser concientes de que el

prototipo se utiliza para precisar los requisitos del software y
así evitar inconvenientes como:

 El cliente cree que el prototipo es una primera versión

funcional del Sistema.
 El desarrollador construye el prototipo rápidamente y
en ocasiones sin hacer uso de la tecnología optima
disponible.

44
 Modelo Espiral

 Utilización de ciclos en lugar de sucesión de

actividades.
 Facilita el desarrollo rápido de versiones
incrementales de software.
EVOLUCION DEL MODELO ESPIRAL
“BOEHM 88”
 EVOLUCION DEL MODELO
ESPIRAL “PRESSMAN 98”

Modelo Espiral Típico

 EVOLUCION DEL MODELO
ESPIRAL “PRESSMAN 98”

Modelo Espiral Adaptado.

 EVOLUCION DEL MODELO
ESPIRAL “PRESSMAN 2002”

IWEB ( Ingeniería Web )

 Para aplicaciones basadas en Web
 Modelo en Espiral
50

Permite usar el prototipado en todas las etapas de

la evolución para reducir el riesgo.
Mantiene el enfoque sistemático de los pasos
sugeridos por el lineal secuencial, pero lo incorpora
dentro de un marco iterativo más real.
Críticas:
 Difícil de convencer a los clientes de que es controlable.
 Requiere mucha habilidad para el análisis de riesgos y de
esta habilidad depende su éxito.
 Modelo de desarrollo Concurrente

 El Modelo de Desarrollo Concurrente dado por Davis y

Sitaram, se puede representar en forma de esquema como
una serie de actividades técnicas importantes, tareas y
estados asociados a ellas.
 El modelo Concurrente define una serie de acontecimientos
que dispararán transiciones de estado a estado para cada
una de las actividades de la Ingeniería del software.
 Este modelo se utiliza a menudo como el paradigma de
desarrollo de aplicaciones cliente/servidor
Modelo Concurrente
Modelos especializados de procesos
 Desarrollo basado en componentes

Construir aplicaciones mediante ensamblado de

módulos software reutilizables, que han sido
diseñados previamente con independencia de las
aplicaciones en las que van a ser utilizados.
 Industrialización del campo del desarrollo software
 Cambio en el papel de los diseñadores de aplicaciones => De
programadores a ensambladores
 Mercado de componentes software reutilizables
 Desarrollo Basado en Componentes
55
Basado en modelo en Espiral (evolutivo e iterativo)
+ Tecnologías de Objetos.
Enfatiza la Reusabilidad.
Planificación Ident. Comps. candidatos
Análisis de
Riesgos
Comunicació Buscar Comps. en biblioteca
n con el
Cliente
F  V

Ingeniería,
Construcción Construir Extraer
y Entrega
Evaluació
Colocar en biblioteca
n del
Cliente

Construir iteración
 Modelo de Métodos Formales
56

Usan notación rigurosa.

Especificaciones sin ambigüedades.
Útiles para sistemas críticos.
Demostraciones formales de propiedades.
Dificulta validación con cliente => combinación con
otras técnicas semi-formales.
Buen nivel de manejo de Lógica y Algebra.
Dos modelos de proceso concretos
 Proceso Unificado (pesado)
 Extreme Programming (ágil)
 Proceso Unificado

Los autores de UML

 Booch: método Booch
 Rumbaugh: OMT
 Jacobson: proceso Objectory
También conocido como RUP: Rational Unified
Process
 Proceso unificado de desarrollo

Es un proceso de desarrollo de software

 Dirigido por casos de uso
 Centrado en la arquitectura
 Interativo e incremental
Utiliza UML para definir los modelos del sistema
software
El sistema software en construcción está formado
por
 componentes software
 interconectados a través de interfaces
Proceso unificado de desarrollo
Proceso unificado de desarrollo
 Tres frases clave

• dirigido por casos de uso

• centrado en la arquitectura
• iterativo e incremental
 Casos de uso

• Un caso de uso es un fragmento de funcionalidad del

sistema que proporciona al usuario un resultado
importante. (requisitos funcionales)
• Todos los casos de uso constituyen el modelo de
casos de uso.
 Arquitectura
• La arquitectura es una vista del diseño completo
con las características más importantes resaltadas,
dejando los detalles de lado.
1. crear esquema de la arquitectura
2. trabajar con un conjunto de casos de uso, se reparte en
subsistemas, clases, y componentes
3. al madurar los casos de uso se desarrolla más la arquitectura
4. esto lleva a madurar más casos de uso
5. se continua hasta que la arquitectura es estable
 Iterativo e incremental
• Se divide todo el trabajo en mini-proyectos.
• Cada mini-proyecto es una iteración (flujo de
trabajo) que resulta en un incremento (crece el
producto).
• Cada iteración tiene una serie de flujos de trabajo:
requisitos, análisis, diseño, implementación y prueba
 Iteración
Esfuerzo de trabajo en un proyecto que recorre
varias etapas de desarrollo (no necesariamente
todas), y al final del cual se ha incrementado el
material disponible sobre el sistema
 Incremento
Un avance significativo en el grado de
especificación, diseño, implementación, o
prueba del sistema que tenga lugar durante una
iteración
 Vida de un sistema
• La vida de un sistema es una serie de ciclos:
nacimiento + ciclos intermedios + muerte
• Cada ciclo tiene varias fases.
• Fase: intervalo de tiempo entre dos hitos importantes
del proceso, cuando se cumplen un conjunto de
objetivos bien definidos, se completan los artefactos
y se toman las decisiones sobre si pasar a la
siguiente fase
 Planificación

Fases de un ciclo
 inicio
 elaboración
 construcción
 transición
Ejemplos de iteraciones
 Fase de inicio

• se especifica la visión del proyecto

• la idea inicial para el desarrollo se lleva al punto de
estar (al menos internamente) suficientemente bien
fundamentada para garantizar la entrada en la fase de
elaboración .
• La oportunidad del negocio incluye:
– Criterios de éxito
– Identificación de riesgos
– Estimación de recursos necesarios
– Plan de las fases incluyendo hitos
Fase de inicio

Productos:

• Un documento de visión general: • Caso de negocio:

– Requerimientos generales del – Contexto
proyecto – Criterios de éxito
– Características principales – Pronóstico financiero
– Restricciones • Identificación inicial de riesgos.
• Modelo inicial de casos de uso • Plan de proyecto.
(10% a 20 % listos). • Uno o más prototipos.
• Glosario.
• Las partes interesadas deben acordar el alcance y la estimación de
tiempo y costo.

• Comprensión de los requerimientos plasmados en casos de uso.

 Fase de elaboración

• se definen la visión del producto y su arquitectura

• se expresan con claridad los requisitos del sistema,
se establecen las prioridades entre ellos, y son
utilizados para crear una sólida base arquitectónica
• se planifican las actividades y los recursos
necesarios
Fase de Elaboración
Productos:
• Es la parte más crítica del proceso:
– Al final toda la ingeniería
“dura” está hecha
– Se puede decidir si vale la
pena seguir adelante
• A partir de aquí la arquitectura, los
requerimientos y los planes de
desarrollo son estables.
• Ya hay menos riesgos y se puede
planificar el resto del proyecto con
menor incertidumbre.
• Se construye una arquitectura
ejecutable que contemple:
– Los casos de uso críticos
– Los riesgos identificados
 Fase de Elaboración
Productos:
• Modelo de casos de uso (80%
completo) con descripciones detalladas.
• Otros requerimientos no funcio-nales o
no asociados a casos de uso.
• Descripción de la Arquitectura del
Software.
• Un prototipo ejecutable de la
arquitectura.
• Lista revisada de riesgos y del caso
de negocio.
• Plan de desarrollo para el resto del
proyecto.
• Un manual de usuario preliminar.

• Condiciones de éxito de la elaboración:

– ¿Es estable la visión del producto?
– ¿Es estable la arquitectura?
– ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y
resueltos?
– ¿Es el plan del proyecto algo realista?
– ¿Están de acuerdo con el plan todas las personas involucradas?
 Fase de construcción

• se construye el producto mediante una serie de

iteraciones incrementales
• se lleva el software desde una base arquitectónica
ejecutable hasta su disponibilidad para la comunidad
de usuarios
 Fase de construcción

• El producto de software integrado y corriendo en la

plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.
• Al final:
• Se obtiene un producto Beta que debe decidirse si
puede ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:
– ¿El producto está maduro y estable para instalarlo en el ambiente
del cliente?
– ¿Están los interesados listos para recibirlo?
 Fase de transición

• el software es puesto en manos de la comunidad de

usuarios
• manufactura
• entrega
• formación...
Fases de un ciclo
 Ciclo de un sistema

• Cuando se han recorrido las cuatro fases, se dice que

el sistema ha sufrido un ciclo.
• Cada ciclo produce una versión del sistema.
• Cada versión es un producto preparado para su
entrega.
 Contenido de una entrega
– código fuente
– manuales
– otros productos asociados
– requisitos
– casos de uso
– especificaciones no funcionales
– casos de prueba
– modelo de la arquitectura
– modelo visual (UML)
Definiciones

Trabajador
• Un trabajador define el comportamiento y las
responsabilidades de un individuo.
• Es como un “sombrero” que la persona usa durante el
proyecto:
– Una persona puede tener varios sombreros
– Es el rol que desempeña en un momento dado
• Responsabilidades:
– Hacer una serie de actividades
– Ser el responsable de una serie de artefactos
 Definiciones
Actividades
• Una actividad es una unidad de
trabajo que se asigna a un
trabajador. Ej.:
– Crear o modificar un artefacto
• Una actividad lleva entre un par de
horas y un par de días, involucra un
solo trabajador y un número
pequeño de artefactos.
• Las actividades se consideran en la
planificación y evaluación del progreso del
proyecto.
• Ejemplos:
– Planificar una iteración - Administrador
de proyecto
– Encontrar actores y casos de uso -
Analista
– Revisar el diseño - Revisor de diseño
– Ejecutar pruebas de performance - Ing.
de pruebas de performance
Asignación de actividades

Recurso Trabajador Actividad

Pablo Diseñador Diseño de Objetos

María Autor de Casos de Uso Detallar un Caso de Uso

José Diseñador de Casos de Uso Diseñar un Caso de Uso

Silvia Revisor de Diseño Revisar el Diseño

Eduardo Arquitecto Análisis de Arquitectura

Diseño de Arquitectura
 Artefactos
• Elementos de información
producidos, modificados o usados
por el proceso.
• Son los productos tangibles del
proyecto.
• Son usados por los trabajadores para
realizar nuevas actividades y son el
resultado de esas actividades.
• Ejemplos:
– Un modelo, como el modelo de
casos de uso o el modelo de
diseño.
– Un elemento del modelo, como
una clase o un caso de uso.
– Un documento tal como el Caso
del Negocio o la Arquitectura
del Software.
– Código fuente.
– Código ejecutable.
 Flujos de trabajo

Análisis de Diseño de Describir Describir

Arquitectura Arquitectura Concurrencia Distribución
• Una lista de actividades,
trabajadores y artefactos Arquitecto
constituye un proceso.
Análisis de Diseño de
Casos de Uso Casos de Uso
• Un flujo de trabajo es una
Diseñador de
secuencia de actividades que Casos de Uso
produce un resultado valioso.
Análisis de Diseño de
Objetos Objetos
• No siempre es posible representar Diseñador
flujos de trabajo.

Revisor de Revisar el Revisar el Revisar la

Diseño Análisis Diseño Arquitectura
 Flujos de trabajo esenciales
Flujos de Trabajo
de Ingeniería

Flujos de Trabajo
de Apoyo
Flujos de trabajo

• Existen habitualmente problemas de comunicación entre

ingenieros de software e ingenieros de negocios.

• RUP proporciona un lenguaje y proceso común para estos

dos ámbitos.

• Para el modelamiento del negocio se usan “business use

cases” (casos de uso del negocio):
– La forma en que el software dará apoyo al negocio.
 Requerimientos
• Los desarrolladores y
clientes deben acordar qué
es lo que el sistema debe
hacer:
– Relevar requerimientos
– Documentar funcionalidad y
restricciones
– Documentar decisiones
– Identificar actores
– Identificar casos de uso
Imprimir Informe
Reciclar Operador
Cliente
Administrar Depósito
• Los casos de uso describen
la funcionalidad.
• Los requerimientos no
funcionales se incluyen en
una especificación
complementaria.
Análisis y diseño
• Descripción de cómo se implementará
el sistema: un plano
• Debe:
– Ejecutar las tareas y funciones
descritas en los casos de uso
– Satisfacer todos los requerimientos
– Flexible a cambios
• El diseño se centra en la noción de
arquitectura.
• Diseñar y validar la arquitectura es
una tarea esencial.
• El modelo de diseño consta de
– Clases estructuradas en paquetes
– Diseños de subsistemas con
interfaces definidas
(componentes)
– Forma de colaboración entre las
clases.
Implementación

• Propósito:

– Definir la organización del código

– Implementar clases y objetos en forma de componentes
(fuente, ejecutables, etc.)
– Probar las componentes desarrolladas
– Integrar las componentes en un sistema ejecutable
 Pruebas

• Propósito:
• RUP propone probar las componentes
– Verificar la interacción entre los desde el principio:
objetos
– Confiabilidad, funcionalidad y
– Verificar la integración apropiada performance
de componentes
– Verificar que se satisfacen los • Las pruebas de regresión son importantes
requerimientos en desarrollos iterativos.
– Identificar los defectos y
corregirlos antes de la instalación • Rational tiene herramientas para
automatizar algunas pruebas.
• RUP describe como planear y ejecutar
estas pruebas.
Distribución
• Producir un producto y hacerlo
llegar a sus usuarios finales.
• Incluye varias actividades:
– Producir un “release”
– Empaquetar el software
– Distribuir el software
– Instalar el software
– Apoyar a los usuarios
• A veces también incluye:
– Realizar pruebas beta
– Migración de datos
– Aceptación formal
• La mayor parte de la distribución
ocurre durante la transición.
• Este es uno de los flujos de trabajo
menos documentados en RUP.
Administración de proyectos

• Es el arte de balancear objetivos contrarios, manejar

riesgos y producir software que satisface a clientes y
usuarios.

• Existen pocos proyectos realmente exitosos.

• RUP incluye:
– Un framework para manejo de proyectos de software
– Guías para planificación, provisión de personal, ejecución y monitoreo de
planes
– Un framework para manejar riesgos
Administración de configuración y cambios

• Forma de controlar los artefactos producidos por las

personas que trabajan en el proyecto.

• Algunos problemas habituales:

– Actualizaciones simultáneas
– Múltiples versiones

• RUP da guías para:

– Desarrollos en paralelo
– Automatizar la construcción
– Administrar defectos
Ambiente

• Ambiente y herramientas de desarrollo que harán

posible llevar a cabo el proyecto.

• RUP guía en la configuración de un ambiente de

proceso apropiado a cada proyecto.
 UML

 Diagrama de casos de uso que muestra a los actores (otros usuarios del
sistema), los casos de uso (las situaciones que se producen cuando utilizan
el sistema) y sus relaciones.
 Diagrama de clases que muestra las clases y la relaciones entre ellas.
 Diagrama de secuencia muestra los objetos y sus múltiples relaciones entre
ellos.
 Diagrama de colaboración que muestra objetos y sus relaciones,
destacando los objetos que participan en el intercambio de mensajes.
 Diagrama de estado muestra estados, cambios de estado y eventos en un
objeto o en parte del sistema.
 Diagrama de actividad que muestra actividades, así como los cambios de
una a otra actividad junto con los eventos que ocurren en ciertas partes del
sistema.
 Diagrama de componentes que muestra los componentes de mayor nivel
de la programación (cosas como Kparts o Java Beans).
 Diagrama de implementación que muestra las instancias de los
componentes y sus relaciones.
 Diagrama de relaciones de entidad que muestra los datos y las relaciones y
restricciones entre ellos.