14 DE MAYO DE 2018

MODELOS DE LA INGENIERÍA DE
SOFTWARE
UNIDAD 2

JORGE MÉNDEZ DELGADO

INGENIERÍA DE SOFTWARE
MC Francisco Javier Ruiz Ortega
Modelos de la Ingeniería de Software

Modelo de Cascada
En Ingeniería de software el desarrollo en cascada, también llamado modelo en
cascada, es el enfoque metodológico que ordena rigurosamente las etapas del
proceso para el desarrollo de software, de tal forma que el inicio de cada etapa
debe esperar a la finalización de la etapa anterior.
Fases de la metodología de desarrollo en cascada es:

 Análisis de requisitos.
 Diseño del Sistema.
 Diseño del Programa.
 Codificación.
 Pruebas.
 Implantación.
 Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba

conduce necesariamente al rediseño y nueva programación del código afectado,
aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la
metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un
cambio en las fases más avanzadas de un proyecto.
En la práctica, este modelo no es lineal, e involucra varias iteraciones e
interacción entre las distintas fases de desarrollo. Algunos problemas que se
observan en el modelo de cascada son:
 Las iteraciones son costosas e implican rehacer trabajo debido a la
producción y aprobación de documentos.
 Aunque son pocas iteraciones, es normal congelar parte del desarrollo y
continuar con las siguientes fases.
 Los problemas se dejan para su posterior resolución, lo que lleva a que estos
sean ignorados o corregidos de una forma poco elegante.
 Existe una alta probabilidad de que el software no cumpla con los requisitos
del usuario por el largo tiempo de entrega del producto.
 Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es
difícil responder a cambios en los requisitos.
Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se
utiliza como parte de proyectos grandes.

Características:
 Es el más utilizado.
 Es una visión del proceso de desarrollo de software como una sucesión
de etapas que producen productos intermedios.
 Para que el proyecto tenga éxito deben desarrollarse todas las fases.
 Las fases continúan hasta que los objetivos se han cumplido.
 Si se cambia el orden de las fases, el producto final será de inferior
calidad.
Ventajas:
 La planificación es sencilla.
 La calidad del producto resultante es alta.
 Permite trabajar con personal poco calificado.

Desventajas:
 No refleja realmente el proceso de desarrollo del software.
 Se tarda mucho tiempo en pasar por todo el ciclo.
 El mantenimiento se realiza en el código fuente.
 Las revisiones de proyectos de gran complejidad son muy difíciles.

Modelo en Espiral
El modelo de desarrollo en espiral es actualmente uno de los más conocidos y
fue propuesto por Boehm. El ciclo de desarrollo se representa como una espiral,
en lugar de una serie de actividades sucesivas con retrospectiva de una actividad
a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definición de objetivos: Se definen los objetivos. Se definen las
restricciones del proceso y del producto. Se realiza un diseño detallado
del plan administrativo. Se identifican los riesgos y se elaboran estrategias
alternativas dependiendo de estos.
2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de
cada riesgo identificado. Pueden desarrollarse prototipos para disminuir
el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir
los riesgos.
3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la
evaluación del riesgo. El modelo que se utilizará (cascada, sistemas
formales, evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificación: Se determina si continuar con otro ciclo. Se planea la
siguiente fase del proyecto.

Este modelo a diferencia de los otros, toma en consideración explícitamente el

riesgo, esta es una actividad importante en la administración del proyecto.
Características:
 Encada giro se construye un nuevo modelo del sistema completo.
 Este modelo puede combinarse con otros modelos de proceso de
desarrollo.
 Mejor modelo para desarrollo de grandes sistemas.
 El análisis de riesgo requiere la participación del personal con alta
calificación.
 No hay numero definido de interacciones, deben de decidirlas el equipo
de gestión de proyecto.

Ventajas:
 El análisis del riesgo se hace de forma explícita y clara. Une los mejores
elementos de los restantes modelos.
 Reduce riesgos del proyecto
 Incorpora objetivos de calidad
 Integra el desarrollo con el mantenimiento, etc.
 Además, es posible tener en cuenta mejoras y nuevos requerimientos sin
romper con la metodología, ya que este ciclo de vida no es rígido ni
estático.

Desventajas
 Genera mucho tiempo en el desarrollo del sistema
 Modelo costoso
 Requiere experiencia en la identificación de riesgos

Inconvenientes
Planificar un proyecto con esta metodología es a menudo imposible, debido a la
incertidumbre en el número de iteraciones que serán necesarias. En este
contexto la evaluación de riesgos es de la mayor importancia y, para grandes
proyectos, dicha evaluación requiere la intervención de profesionales de gran
experiencia.
Modelo Incremental
El modelo incremental combina elementos del modelo lineal secuencial
(aplicados repetidamente) con la filosofía interactiva de construcción de
prototipos. El modelo incremental aplica secuencias lineales de forma
escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal
produce un incremento del software. Por ejemplo, el software de tratamiento de
textos desarrollado con el paradigma incremental podría extraer funciones de
gestión de archivos básicos y de producción de documentos en el primer
incremento; funciones de edición más sofisticadas y de producción de
documentos en el segundo incremento; corrección ortográfica y gramatical en el
tercero; y una función avanzada de esquema de página en el cuarto.

Etapas del modelo incremental:

1. Análisis: Construye un modelo de los requisitos
2. Diseño: A partir del modelo de análisis se deducen las estructuras de
datos, la estructura en la que descompone el sistema y la interfaz de
usuario.
3. Código: Construye el sistema. La salida de esta fase es código
ejecutable.
4. Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un

producto esencial, sólo con los requisitos básicos. Este modelo se centra en la
entrega de un producto operativo con cada incremento. Los primeros
incrementos son versiones incompletas del producto final, pero proporcionan al
usuario la funcionalidad que precisa y también una plataforma para la evaluación.

Ventajas
 Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema.
Pueden empezar a usarlo desde el primer incremento.
  Los clientes pueden aclarar los requisitos que no tengan claros conforme
ven las entregas del sistema.
 Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede
distribuir en cada incremento.
 Las partes más importantes del sistema son entregadas primero, por lo
cual se realizan más pruebas en estos módulos y se disminuye el riesgo
de fallos.

Desventajas
 Cada incremento debe ser pequeño para limitar el riesgo (menos de
20.000 líneas).
 Cada incremento debe aumentar la funcionalidad.
 Es difícil establecer las correspondencias de los requisitos contra los
incrementos.
 Es difícil detectar las unidades o servicios genéricos para todo el sistema.
Inconvenientes

Para el uso de este modelo se requiere una experiencia importante para definir
los incrementos y distribuir en ellos las tareas de forma proporcionada. Entre los
inconvenientes que aparecen en el uso de este modelo podemos destacar los
siguientes:
 Cada fase de una iteración es rígida y no se superponen con otras.
 Pueden surgir problemas referidos a la arquitectura del sistema porque no
todos los requisitos se han reunido, ya que se supone que todos ellos se
han definido al inicio.

Proceso Unificado Racional

Es un proceso de Ingeniería de Software. Proporciona un enfoque disciplinado

para la asignación de tareas y responsabilidades dentro de una organización de
desarrollo. Su objetivo es garantizar la producción de alta calidad software que
satisfaga las necesidades de sus usuarios finales, dentro de un horario
predecible y presupuesto.
El RUP de desarrollo de software fue desarrollado por la IBM Corporation, de
propiedad de Rational Software en 2003. El antecedente más importante se
ubica en 1967 con la Metodología Ericsson (Ericsson Approach) elaborada por
Ivar Jacobson, una aproximación de desarrollo basada en componentes, que
introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson
fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory
(abreviación de Object Factory).
Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB
y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir
de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML
como lenguaje de modelado. Desde ese entonces y a la cabeza de Grady
Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarrolló e
incorporó diversos elementos para expandir ROP, destacándose especialmente
el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se
lanza Rational Unified Process.
Características Esenciales
Los autores de RUP destacan que el proceso de software propuesto
por RUP tiene tres características esenciales: está dirigido por los Casos de
Uso, está centrado en la arquitectura, y es iterativo e incremental.
Sus características es que es iterativo e incremental y está basada mucho en los
casos de uso, también sus características es que verifica de manera seguida la
calidad del software y administrar los requisitos. Este proceso de desarrollo tiene
tanto artefactos como roles (que son las personas que están encargadas dentro
del desarrollo o proceso).

1. Proceso dirigido por Casos de Uso: Los Casos de Uso son una técnica
de captura de requisitos que fuerza a pensar en términos de importancia
para el usuario y no sólo en términos de funciones que sería bueno
contemplar. Se define un Caso de Uso como un fragmento de
funcionalidad del sistema que proporciona al usuario un valor añadido.
Los Casos de Uso representan los requisitos funcionales del sistema. En
RUP los Casos de Uso no son sólo una herramienta para especificar los
requisitos del sistema. También guían su diseño, implementación y
prueba. Los Casos de Uso constituyen un elemento integrador y una
guía del trabajo. Los Casos de Uso no sólo inician el proceso de
desarrollo, sino que proporcionan un hilo conductor, permitiendo
establecer trazabilidad entre los artefactos que son generados en las
diferentes actividades del proceso de desarrollo.
2. Proceso centrado en la arquitectura: La arquitectura de un sistema es
la organización o estructura de sus partes más relevantes, lo que permite
tener una visión común entre todos los involucrados (desarrolladores y
usuarios) y una perspectiva clara del sistema completo, necesaria para
controlar el desarrollo. La arquitectura involucra los aspectos estáticos y
dinámicos más significativos del sistema, está relacionada con la toma de
decisiones que indican cómo tiene que ser construido el sistema y
ayuda a determinar en qué orden. La arquitectura se ve influenciada por
la plataforma software, sistema operativo, gestor de bases de datos,
protocolos, consideraciones de desarrollo como sistemas heredados.
Muchas de estas restricciones constituyen requisitos no funcionales del
sistema. En el caso de RUP además de utilizar los Casos de Uso para
guiar el proceso se presta especial atención al establecimiento temprano
de una buena arquitectura que no se vea fuertemente impactada ante
cambios posteriores durante la construcción y el mantenimiento.
3. Proceso iterativo e incremental: La estrategia que se propone en RUP
es tener un proceso iterativo e incremental en donde el trabajo se divide
en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio
entre Casos de Uso y arquitectura se vaya logrando durante cada mini
proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto
se puede ver como una iteración (un recorrido más o menos completo a
lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene
un incremento que produce un crecimiento en el producto. Una iteración
pu ede realizarse por medio de una cascada de etapas. Se pasa por los
flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y
Pruebas), también existe una planificación de la iteración, un análisis de
 la iteración y algunas actividades específicas de la iteración. Al finalizar
se realiza una integración de los resultados con lo obtenido de las
iteraciones anteriores.
4. Estructura Dinámica del proceso. Fases e iteraciones: RUP se repite
a lo largo de una serie de ciclos que constituyen la vida de un producto.
Cada ciclo concluye con una generación del producto para los clientes.
Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y
Transición. Cada fase se subdivide a la vez en iteraciones, el número de
iteraciones en cada fase es variable. Cada fase se concluye con un hito
(entregable) bien definido, un punto en el tiempo en el cual se deben
tomar ciertas decisiones críticas y alcanzar las metas clave antes de
pasar a la siguiente fase, ese hito principal de cada fase se compone de
hitos menores que podrían ser los criterios aplicables a cada iteración.
Los hitos para cada una de las fases son: Inicio - Lifecycle Objectives,
Elaboración - Lifecycle Architecture, Construcción - Initial Operational
Capability, Transición - Product Release. La duración y esfuerzo
dedicado en cada fase es variable dependiendo de las características del
proyecto.

Ciclo de Desarrollo
El RUP divide un ciclo de desarrollo en cuatro fases consecutivas:
1. Fase Inicial: Durante la fase inicial, se establece el modelo de negocio
para el sistema y delimitar el alcance del proyecto. Para ello se debe
identificar todas las entidades externas con las que el sistema va a
interactuar (actores) y definir la naturaleza de esta interacción en un alto
nivel. Esto implica identificar todos los casos de uso y que describe una
los pocos significativos. El caso de negocio incluye criterios de éxito,
evaluación de riesgos y estimación de los recursos necesarios y un plan
de eliminación con las fechas de los hitos más importantes.
2. Elaboración de Fase: El propósito de la fase de elaboración es analizar
el dominio del problema, establecer una base arquitectónica de sonido,
desarrollar el plan del proyecto, y eliminar los elementos de mayor riesgo
del proyecto. Para lograr estos objetivos, que debe tener la "milla de
ancho y una pulgada de profundidad" vista del sistema. Las decisiones de
arquitectura que se hace con una la comprensión de todo el sistema: su
alcance, la funcionalidad y los principales requisitos no funcionales, tales
como requisitos de desempeño.
3. Fase de Construcción: Durante la fase de construcción, todos los demás
componentes y características de las aplicaciones se desarrollan y se
integran en el producto, y todas las características están ampliamente
probadas. La fase de construcción es, en cierto sentido, un proceso de
fabricación donde se hace hincapié en la gestión de recursos y control de
las operaciones para optimizar costos, horarios y de calidad. En este
sentido, la mentalidad de gestión experimenta una transición desde el
desarrollo de la propiedad intelectual durante el inicio y elaboración, para
el desarrollo de productos de despliegue durante la construcción y en
transición.
4. La Transición de Fase: El propósito de la fase de transición es la
transición del producto de software para la comunidad de usuarios. Una
 vez que el producto ha dado al usuario final, suelen surgir problemas que
requieren para desarrollar las nuevas versiones, corregir algunos
problemas, o acabado de las características que fueron aplazadas.

Lenguaje de Programación
El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified
Modeling Language) es el lenguaje de modelado de sistemas de software para
especificar o para describir métodos o procesos. Se utiliza para definir un
sistema, para detallar los artefactos en el sistema y para documentar y construir.
Se puede aplicar en el desarrollo de software para dar soporte a una metodología
de desarrollo de software como el modelo RUP.
Ventajas:
 Requiere de conocimientos del proceso y de UML
 Progreso visible en las etapas tempranas
 El uso de iteraciones
 Evaluación de riesgos en lugar de descubrir en la integración final del
sistema
 Facilita la reutilización del código

Desventajas:
 Por el grado de complejidad puede no resultar no muy adecuado
 Mal aplicado en el estilo cascada

Determinar el modelo más adecuado para un tipo de sistema

Cada proyecto de software requiere de una forma de particular de abordar el
problema. Las propuestas comerciales y académicas actuales promueven
procesos iterativos, donde en cada iteración puede utilizarse uno u otro modelo
de proceso, considerando un conjunto de criterios (Por ejemplo: grado de
definición de requisitos, tamaño del proyecto, riesgos identificados, entre otros).
De acuerdo a un cuadro comparativo de acuerdo con algunos criterios básicos
para la selección de un modelo de proceso, la medida utilizada indica el nivel de
efectividad del modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo
Cascada responde con un nivel de efectividad Bajo cuando los Requisitos y
arquitectura no están predefinidos)

En si podemos deducir que no hay metodologías mejores o peores, sino que

cada una se adapta a un proyecto por sus propias características. También hay
que tener en cuenta que, en todo el proceso, es muy importante el cliente, que
participa de distinta forma según la metodología, por lo que trabajar con un
profesional o empresa, sabiendo qué proceso de desarrollo utiliza es beneficioso
para obtener un buen resultado. En esto también incluye a quién se contrate,
pues las dos partes deben tener en cuenta que se trabaja con personas, y su
gestión dentro de las metodologías es muy importante, porque son ellas las que
pueden tener errores y las capacitadas para corregirlos que, como acabamos de
ver, es algo que los ciclos de vida tienen muy en cuenta