Universidad Nacional De La Amazonia Peruana

Modelos de Desarrollo
Para el desarrollo de cualquier producto de software se realizan una serie de
tareas entre la idea inicial y el producto final.

Un modelo de desarrollo establece el orden en el que se harán las cosas en

el proyecto, nos provee de requisitos de entrada y salida para cada una de
las actividades.

Es necesario destacar el ciclo de vida del proyecto y el modelo de

desarrollo.

El ciclo de vida del proyecto ayuda a controlar las actividades del proyecto
desde el inicio al fin del mismo.

El modelo de desarrollo nos ayuda a la forma en la que vamos a construir el

producto.

Ambos se complementan para generar el producto desde el punto de vista

técnico y administrativo.

La ingeniería de software tiene varios modelos, paradigmas o filosofías de

desarrollo en los cuales se puede apoyar para la realización de software, de
los cuales podemos destacar a éstos por ser los más utilizados y los más
completos:
I. Modelo en cascada o Clásico (modelo tradicional)
II. Modelo en espiral (modelo evolutivo)
III. Modelo de prototipos
IV. Desarrollo por etapas
V. Desarrollo iterativo y creciente o Iterativo e Incremental
VI. RAD (Rapid Application Development)
I. EL MODELO DE CASCADA
El modelo de cascada es también conocido como Modelo en cascada o
Modelo lineal secuencial o Ciclo de vida básico o Ciclo de vida clásico.
Es un refinamiento altamente influenciado para 1970 del modelo de etapas.
Existe, para este modelo, un reconocimiento de los ciclos de
retroalimentación entre etapas, y una guía para confinar las
retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el
costo del retrabajo involucrado en retroalimentaciones a través de muchas
etapas.
Es uno de los método más usados en desarrollo de software y que ha sido
exitoso durante décadas tanto en el desarrollo de grandes sistemas como
en el de pequeños. Existen ocasiones en que los requisitos de un problema
se entienden de una manera razonable: cuando el trabajo fluye desde la
comunicación a través del despliegue de una manera casi lineal. Esta
situación se encuentra a veces cuando es necesario hacer adaptaciones o
mejorías bien definidas a un sistema existente (por ejemplo, una adaptación
a un software contable debido a los cambios en las regulaciones del
gobierno). Esto puede ocurrir también en un número limitado de proyectos
de nuevos desarrollos, pero sólo cuando los requerimientos están bien
definidos y son estables en forma razonable,

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

El modelo en cascada, algunas veces llamado el ciclo de vida clásico,

sugiere un enfoque sistemático, secuencial hacia el desarrollo del software,
que se inicia con la especificación de requerimientos del cliente y que
continúa con la planeación, el modelado, la construcción y el despliegue
para culminar en el soporte del software terminado. El modelo en cascada
es el paradigma más antiguo para la ingeniería del software. Sin embargo,
en las décadas pasadas, las criticas a este modelo de proceso han
ocasionado que aun sus más fervientes practicantes hayan cuestionado su
eficacia. Entre los problemas que algunas veces se encuentran al aplicar el
modelo en cascada están:

1. Es muy raro que los proyectos reales sigan el flujo secuencial que
propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo
hace de manera indirecta. Como resultado, los cambios confunden mientras
el equipo de proyecto actúa.

2. Con frecuencia es difícil para el cliente establecer todos los requisitos de

manera explícita. El modelo en cascada lo requiere y se enfrentan
dificultades al incorporar la incertidumbre natural presente en el inicio de
muchos proyectos.

3. El cliente debe tener paciencia. Una versión que funcione de los

programas estará disponible cuando el proyecto esté muy avanzado. Un
error grave será desastroso si no se detecta antes de la revisión del
programa.

En un análisis interesante de proyectos reales, Bradac concluyó que la

naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en
los cuales algunos miembros del equipo del proyecto deben esperar a otros
para terminar tareas dependientes. De hecho, el tiempo de espera puede
superar el que se aplica en el trabajo productivo. El estado de bloqueo
tiende a ser más común al principio y al final del proceso secuencial.

En la actualidad, el trabajo del software está acelerado y sujeto a una

cadena infinita de cambios (de características, funciones y contenido de la
información). Con frecuencia, el modelo en cascada no es apropiado para
dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en
situaciones donde los requerimientos están fijos y donde el trabajo se
realiza, hasta su conclusión, de una manera lineal.

VENTAJAS...

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

✔ Excelente cuando se tiene un producto estable y se conoce la

tecnología.
✔ Es un método muy estructurado que funciona bien con gente de poca
experiencia.
✔ Provee estabilidad en los requerimientos.
✔ La planeación se puede hacer anticipadamente.
✔ Para proyectos grandes.

DESVENTAJAS...

✔ Tiene poca flexibilidad.

✔ Los proyectos en la práctica raramente siguen un flujo secuencial.
✔ Siempre es difícil para el cliente mostrar todos los requerimientos
explícitamente y con mucha anticipación.
✔ El cliente debe tener paciencia.
✔ Es inflexible y no motiva al cambio.
✔ Poco apropiado para aplicaciones para la toma de decisiones.
✔ Los usuarios tienen una participación limitada.

I. EL MODELO DE ESPIRAL

El modelo Espiral de Boehm para Ingeniería de Software agrupa las mejores

características del modelo del ciclo de vida clásico y de prototipos. Pero
también agrega nuevas funciones que no están incluidas en los otros
modelos, como el análisis de riesgo. El modelo espiral define cuatro
actividades principales para el ciclo de vida:

· Planificación
La determinación de los objetivos del proyecto, alternativas y restricciones.
· Análisis de Riesgo
El análisis de alternativas y la identificación y solución de riesgos.
· Ingeniería
Desarrollo del producto.
· Evaluación del cliente
El asentimiento de los resultados de la ingeniería.

El modelo es representado por una espiral dividida en cuatro cuadrantes, en

que cada uno describe las actividades mencionadas anteriormente. El
modelo espiral utiliza un esquema de desarrollo iterativo donde la primera
iteración comienza en el centro del círculo e, incrementalmente, se va
desplazando hacia afuera. Las siguientes iteraciones sucesivas son
versiones más completas del software que está siendo construido. Al
principio de cada iteración del ciclo de vida se hace un análisis de riesgo,
mientras, por el otro extremo, la revisión del proyecto se realiza al final de
la iteración. Así, se puede contrarrestar cualquier riesgo observado
mediante las acciones adecuadas en el tiempo preciso.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

El modelo espiral es visto como un enfoque más realista para el desarrollo

de grandes sistemas de software.
Usa un método evolucionario para desarrollo y prototipos como una técnica
de reducción de riesgo (pese a que los prototipos pueden ser usados en
cualquier etapa dentro del ciclo de vida). También utiliza el enfoque de
sistematización y el 'desarrollo en etapas' del ciclo de vida clásico, pero, con
la diferencia que todos están incorporados dentro del esquema iterativo
planteado por el modelo espiral.

VENTAJAS...

✔ El producto avanza a pasos firmes solucionado riesgos en cada

iteración.
✔ El producto termina con todos los riesgos resueltos.
✔ Se pueden incluir otros métodos de desarrollo en las iteraciones.
✔ A medida que el costo aumenta, los riesgos se reducen.
✔ Se tienen puntos de control en cada interacción.

DESVENTAJAS...

✔ Es complicado.
✔ Requiere de mucha administración.
✔ Difícil de definir los objetivos, metas que indiquen que podemos
avanzar al siguiente ciclo.
✔ Se puede caer en un desarrollo de nunca acabar.

I. MODELO DE PROTOTIPOS
Es un método menos formal de desarrollo.
El prototipeo es una técnica para comprender las especificaciones.
Un prototipo puede ser eliminado.
Un prototipo puede llegar a ser parte del producto final.

Una definición de un prototipo en software podría ser:

Las fases que comprende el método de desarrollo orientado a prototipos
serían:

· Investigación preliminar

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

Las metas principales de esta fase son: determinar el problema y su ámbito,

la importancia y sus efectos potenciales sobre la organización por una parte
y, por otro lado, identificar una idea general de la solución para realizar un
estudio de factibilidad que determine la factibilidad de una solución
software.

· Definición de los requerimientos del sistema

El objetivo de esta etapa es registrar todos los requerimientos y deseos que
los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa es la
más importante de todo el ciclo de vida, es aquí donde el desarrollador
determina los requisitos mediante la construcción, demostración y
retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada
con más detalle luego de esta descripción.

· Diseño técnico
Durante la construcción del prototipo, el desarrollador ha obviado el diseño
detallado. El sistema debe ser entonces rediseñado y documentado según
los estándares de la organización y para ayudar a las mantenciones futuras.
Esta fase de diseño técnico tiene dos etapas: por un lado, la producción de
una documentación de diseño que especifica y describe la estructura del
software, el control de flujo, las interfaces de usuario y las funciones y,
como segunda etapa, la producción de todo lo requerido para promover
cualquier mantención futura del software.

· Programación y prueba
Es donde los cambios identificados en el diseño técnico son implementados
y probados para asegurar la corrección y completitud de los mismos con
respecto a los requerimientos.

· Operación y mantención
La instalación del sistema en ambiente de explotación, en este caso, resulta
de menor complejidad, ya que se supone que los usuarios han trabajado con
el sistema al hacer las pruebas de prototipos. Además, la mantención
también debería ser una fase menos importante, ya que se supone que el
refinamiento del prototipo permitiría una mejor claridad en los
requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si
eventualmente se requiriese una mantención entonces el proceso de
prototipado es repetido y se definirá un nuevo conjunto de requerimientos.
La fase más importante corresponde a la definición de requerimientos, la
cual correspondería a un proceso que busca aproximar las visiones del
usuario y del desarrollador mediante sucesivas iteraciones. La definición de
requerimientos consiste de cinco etapas entre dos de las cuales se
establece un ciclo iterativo:

· Análisis grueso y especificación

El propósito de esta subfase es desarrollar un diseño básico para el
prototipo inicial.

· Diseño y construcción
El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador
debe concentrarse en construir un sistema con la máxima funcionalidad,
poniendo énfasis en la interface del usuario.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

· Evaluación
Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de
los requerimientos adicionales del sistema y verificar que el prototipo
desarrollado lo haya sido en concordancia con la definición de
requerimientos del sistema. Si los usuarios identifican fallas en el prototipo,
entonces el desarrollador simplemente corrige el prototipo antes de la
siguiente evaluación. El prototipo es repetidamente modificado y evaluado
hasta que todos los requerimientos del sistema han sido satisfechos. El
proceso de evaluación puede ser dividido en cuatro pasos separados:
preparación, demostración, uso del prototipo y discusión de comentarios. En
esta fase se decide si el prototipo es aceptado o modificado.

· Modificación
Esto ocurre cuando la definición de requerimientos del sistema es alterada
en la subfase de evaluación. El desarrollador entonces debe modificar el
prototipo de acuerdo a los comentarios hechos por los usuarios.

· Término
Una vez que se ha desarrollado un prototipo estable y completo, es
necesario ponerse de acuerdo en relación a aspectos de calidad y de
representación del sistema.
En la siguiente figura se puede ver un esquema en que estas etapas se
realizan, note que la especificación de requerimientos está claramente
diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que
permite entregar al usuario lo que sería una visión la solución final en
etapas tempranas del desarrollo, reduciendo tempranamente los costos de
especificaciones erróneas.

VENTAJAS...

✔ Útiles cuando los requerimientos son cambiantes.

✔ Cuando no se conoce bien la aplicación.
✔ Cuando el usuario no se quiere comprometer con los requerimientos.
✔ Cuando se quiere probar una arquitectura o tecnología.
✔ Cuando se requiere rapidez en el desarrollo.

DESVENTAJAS...

✔ No se conoce cuando se tendrá un producto aceptable.

✔ No se sabe cuantas iteraciones serán necesarias.
✔ Da una falsa ilusión al usuario sobre la velocidad del desarrollo.
✔ Se puede volver el producto aún y cuando no este con los estándares.

I. EL MODELO DE ETAPAS

Gustavo Donoso:
En 1956, el enfrentarse a un gran sistema de software como el
Semi−Automated Ground Environment (SAGE) hizo que se reconocieran los

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

problemas inherentes a la codificación y esto llevó al desarrollo del modelo

de etapas, con el objetivo de poder mejorar estos nuevos problemas. Este
modelo estipula que el software será desarrollado en sucesivas etapas:

· Plan operativo
Etapa donde se define el problema a resolver, las metas del proyecto, las
metas de calidad y se identifica cualquier restricción aplicable al proyecto.

· Especificación de requerimientos
Permite entregar una visión de alto nivel sobre el proyecto, poniendo
énfasis en la descripción del problema desde el punto de vista de los
clientes y desarrolladores. También se considera la posibilidad de una
planificación de los recursos sobre una escala de tiempos.

· Especificación funcional
Especifica la información sobre la cual el software a desarrollar trabajará.

· Diseño
Permite describir como el sistema va a satisfacer los requerimientos. Esta
etapa a menudo tiene diferentes niveles de detalle. Los niveles más altos de
detalle generalmente describen los componentes o módulos que formarán
el software a ser producido. Los niveles más bajos, describen, con mucho
detalle, cada módulo que contendrá el sistema.

· Implementación
Aquí es donde el software a ser desarrollado se codifica. Dependiendo del
tamaño del proyecto, la programación puede ser distribuida entre distintos
programadores o grupos de programadores. Cada uno se concentrará en la
construcción y prueba de una parte del software, a menudo un subsistema.
Las pruebas, en general, tiene por objetivo asegurar que todas las funciones
están correctamente implementadas dentro del sistema.

· Integración
Es la fase donde todos los subsistemas codificados independientemente se
juntan. Cada sección es enlazada con otra y, entonces, probada. Este
proceso se repite hasta que se han agregado todos los módulos y el sistema
se prueba como un todo.

· Validación y verificación
Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es
probado para verificar que el sistema es consistente con la definición de
requerimientos y la especificación funcional. Por otro lado, la verificación
consiste en una serie de actividades que aseguran que el software
implementa correctamente una función específica. Al finalizar esta etapa, el
sistema ya puede ser instalado en ambiente de explotación.

· Mantención
La mantención ocurre cuando existe algún problema dentro de un sistema
existente, e involucraría la corrección de errores que no fueron descubiertos
en las fases de prueba, mejoras en la implementación de las unidades del
sistema y cambios para que responda a los nuevos requerimientos. Las
mantenciones se puede clasificar en: correctiva, adaptativa, perfectiva y
preventiva.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

El modelo de etapas consideraba que cada una de ellas debería ir a

continuación de la anterior, poniendo énfasis en la documentación que
resulta de cada una y que es la entrada de la siguiente, formalizando los
procedimientos de planificación y de control. Todo tendiente a conformar
una cadena de producción de software, de manera similar a una cadena de
montaje de automóviles.
Pero ello no logra que las causas de fondo que hicieron que se replantease
el modelo de codificar y fijar desapareciesen. Todavía existe la distancia
entre el programador (ahora desarrollador) y el usuario, esta distancia está
dada por dominios de acción distintos. La iteración de aproximación es
ahora más factible, pero también resulta onerosa, es necesario instalar todo
el software nuevamente en la cadena de montaje para su revisión y
reconstrucción.

II. EL MODELO DESARROLLO ITERATIVO Y CRECIENTE O

ITERATIVO E INCREMENTAL

Combina elementos del modelo en cascada aplicado en forma iterativa.

Como se muestra en la figura, el modelo incremental aplica secuencias
lineales de manera escalonada conforme avanza el tiempo en el calendario.
Cada secuencia lineal produce "incrementos" del software. Por ejemplo, el
software procesador de texto, desarrollado con el paradigma incremental en
su primer incremento, podría realizar funciones básicas de administración
de archivos, edición y producción de documentos; en el segundo
incremento, ediciones más sofisticadas, y tendría funciones más complejas
de producción de documentos; en el tercer incremento, funciones de
corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas
de configuración de página. Se debe tener en cuenta que el flujo del
proceso de cualquier Modelos de desarrollo de software incremento puede
incorporar el paradigma de construcción de prototipos que se expone más
adelante. A menudo, al utilizar un modelo incremental el primer incremento
es un producto esencial. Es decir, se incorporan los requisitos básicos, pero
muchas características suplementarias (algunas conocidas, otras no) no se
incorporan. El producto esencial queda en manos del cliente (o se somete a
una evaluación detallada). Como resultado de la evaluación se desarrolla un
plan para el incremento siguiente. El plan afronta la modificación del
producto esencial con el fin de satisfacer de mejor manera las necesidades
del cliente y la entrega de características y funcionalidades adicionales. Este
proceso se repite después de la entrega de cada incremento mientras no se
haya elaborado el producto completo. El modelo de proceso incremental, al
igual que la construcción de prototipos y otros enfoques evolutivos, es
iterativo por naturaleza. Pero a diferencia de la construcción de prototipos,
el modelo incremental se enfoca en la entrega de un producto operacional
con cada incremento. Los primeros incrementos son versiones “incompletas
del producto final, pero proporcionan al usuario la funcionalidad que
necesita y una plataforma para evaluarlo.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

El desarrollo incremental es útil sobre todo cuando el personal necesario

para una implementación completa no está disponible. Los primeros
incrementos se pueden implementar con menos gente. Si el producto
esencial es bien recibido se agrega (si se requiere) más personal para
implementar el incremento siguiente. Además, los incrementos se pueden
planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande
podría requerir la disponibilidad de un hardware nuevo que está en
desarrollo y cuya fecha de entrega es incierta. Sería posible planear los
primeros incrementos de forma que se evite el uso de este hardware, lo que
permitiría la entrega de funcionalidad parcial a los usuarios finales sin
retrasos desordenados.

VENTAJAS...

✔ La solución se va mejorando en forma progresiva a través de las

múltiples iteraciones.

✔ Incrementa el entendimiento del problema y de la solución por medio

de los refinamientos sucesivos.

DESVENTAJAS...

✔ Requiere de mucha planeación, tanto administrativa como técnica.

✔ Requiere de metas claras para conocer el estado del proyecto.

I. EL MODELO RAD (RAPID APPLICATION DEVELOPMENT).

El desarrollo rápido de aplicaciones (RAD) es un modelo de proceso de

software incremental que resalta un ciclo de desarrollo corto. El modelo
DRA es una adaptación a "alta velocidad" del modelo en cascada en el
que se logra el desarrollo rápido mediante un enfoque de construcción
basado en componentes. Si se entienden bien los requisitos y se limita el
ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo
cree un "sistema completamente funcional" dentro de un periodo muy corto
(por ejemplo, de 60 a 90 días). Como otros modelos de proceso, el enfoque
DRA cumple con las actividades genéricas del marco de trabajo que ya se

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

han presentado. La comunicación trabaja para entender el problema de

negocios y las características de información que debe incluir el software. La
planeación es esencial porque varios equipos de software trabajan en
paralelo sobre diferentes funciones del sistema. El modelado incluye tres
grandes fases: modelado de negocios, modelado de datos y modelado del
proceso y establece representaciones del diseño que sirven como base para
la actividad de construcción del modelo DRA. La construcción resalta el
empleo de componentes de software existente y la aplicación de la
generación automática de código. Por último, el despliegue establece una
base para las iteraciones subsecuentes, si éstas son necesarias.
El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las
restricciones de tiempo impuestas sobre un proyecto DRA exigen un
"ámbito de escalas". Si una aplicación de negocios se puede modular de
forma que cada gran función pueda completarse en menos de tres meses
(mediante la aplicación del enfoque ya descrito), ésta es una candidata para
el DRA. Cada gran función se puede abordar mediante un equipo de DRA
por separado, para después integrarlas y formar un todo.

Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes:

1) Para proyectos grandes, pero escalables, el DRA necesita suficientes
recursos humanos para crear en número correcto de equipos DRA.
2) Si los desarrolladores y clientes no se comprometen con las actividades
rápidas necesarias para completar el sistema en un marco de tiempo muy
breve, los proyectos DRA fallarán.
3) Si un sistema no se puede modular en forma apropiada, la construcción
de los componentes necesarios para el DRA será problemática.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

4) Si el alto rendimiento es un aspecto importante, y se alcanzará al

convertir interfaces en componentes del sistema, el enfoque DRA podría no
funcionar.
5) El DRA sería inapropiado cuando los riesgos técnicos son altos (por
ejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías).

METODOLOGÍA DE DESARROLLO DE SOFTWARE

Las metodologías de desarrollo de software son un conjunto de
procedimientos, técnicas y ayudas a la documentación para el desarrollo de
productos software.

DEFINICIONES:

1. son un conjunto de procedimientos, técnicas y ayudas para el desarrollo

de productos software. En si pasos naturales o lógicos para la construcción
de software.
2. se definen como un con junto de pasos como análisis diseño desarrollo
implementación pruebas y implantación llamados ciclo de vida como una
definición general.
3. Es conjunto ordenado de pasos a seguir para llegar a la solución de un
problema u obtención de un producto osea el software, son también los
pasos generales que sigue el proceso de desarrollo de un producto software.

Las metodologías de desarrollo de software son un conjunto de

procedimientos, técnicas y ayudas a la documentación para el desarrollo de
productos software.

CARACTERISTICAS DESEABLES
DE UNA METODOLOGIA
• Existencia de reglas predefinidas
• Cobertura total del ciclo de desarrollo
• Verificaciones intermedias
• Planificación y control
• Comunicación efectiva
• Utilización sobre un abanico amplio de proyectos
• Fácil formación
• Herramientas CASE
• Actividades que mejoren el proceso de desarrollo
• Soporte al mantenimiento
• Soporte de la reutilización de software
Una metodología de desarrollo de software es un conjunto de pasos y
procedimientos que deben seguirse para desarrollar software. Una
metodología está compuesta por:
✔ Cómo dividir un proyecto en etapas.
✔ Qué tareas se llevan a cabo en cada etapa.
✔ Qué restricciones deben aplicarse.
✔ Qué técnicas y herramientas se emplean.
✔ Cómo se controla y gestiona un proyecto.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

Clasificación de las metodologías

Las metodologías se clasifican de la siguiente forma:

a. Estructuradas.
○ Orientadas a procesos
○ Orientadas a datos
○ Mixta
b. No estructuradas.
○ Orientadas a objetos
○ Sistemas de tiempo real
a. Metodologías estructuradas
Se basan en la forma top-down

Metodologías orientadas a procesos

La ingeniería del software se basa en el modelo básico de
entrada/proceso/salida de un sistema.
Está compuesta por:
• Diagrama de flujo de datos (DFD).
• Diccionario de datos.
• Especificaciones de proceso.
Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon.

Metodologías orientadas a datos

Son metodologías basadas en la información. Primero se definen las
estructuras de datos y, a partir de éstos, se derivan los componentes
procedimentales.

Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr.

a. Metodologías no estructuradas

Metodologías orientadas a objeto

La orientación a objetos unifica procesos y datos encapsulándolos en el
concepto de objetos.

Tiene dos enfoques distintos:

• Revolucionario, puro u ortodoxo. Rompen con las metodologías
tradicionales.
Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock.
• Sintetista o evolutivo. Toman como base los sistemas estructurados y
conforman elementos de uno y otro tipo.
Ejemplos: metodología OMT de Rumbourgh.

Sistemas de tiempo real

Procesan información orientada al control más que a los datos.

Se caracterizan por concurrencia, priorización de procesos, comunicación

entre tareas y acceso simultáneo a datos comunes.

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

En general las metodologías llevan a cabo una serie de procesos comunes

que son buenas prácticas para lograr los objetivos antes mencionados
independientemente de cómo hayan sido diseñadas. Las fases que agrupan
estos procesos son las siguientes:
• Análisis
• Especificación
• Diseño
• Programación
• Prueba
• Documentación
• Mantenimiento
• Reingeniería
Las metodologías desde el punto de vista de la arquitectura de software y la
administración de proyectos son las siguientes:

Metodologías tradicionales
• Capability Maturity Model (SW-CMM)
• Capability Maturity Model Integration for Development (CMMI-DEV)
• Big Design Up Front (BDUF)
• Cleanroom Software Engineering
• Rational Unified Process (RUP)
El Proceso Unificado Racional (Rational Unified Process en inglés,
habitualmente resumido como RUP) 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 orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un
conjunto de metodologías adaptables al contexto y necesidades de cada
organización.
También se conoce por este nombre al software desarrollado por Rational,
hoy propiedad de IBM, el cual incluye información entrelazada de diversos
artefactos y descripciones de las diversas actividades. Está incluido en el
Rational Method Composer (RMC), que permite la personalización de
acuerdo a necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el
Proceso Unificado, y una especificación más detallada, el Rational Unified
Process, que se vendiera como producto independiente.

El RUP está basado en 6 principios clave que son:

El proceso deberá adaptarse a las características propias del proyecto u
organización. El tamaño del mismo, así como su tipo o las regulaciones que

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

lo condicionen, influirán en su diseño específico. También se deberá tener

en cuenta el alcance del proyecto en un area subformal.

Equilibrar prioridades
Los requerimientos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe encontrarse un
equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se
podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas
iteradas. En cada iteración se analiza la opinión de los inversores, la
estabilidad y calidad del producto, y se refina la dirección del proyecto así
como también los riesgos involucrados

Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples
equipos. Debe haber una comunicación fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes, resultados, etc.

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales
como patrón del software, lenguajes 4GL o marcos de referencia
(frameworks) por nombrar algunos. Esto evita que los ingenieros de
software vayan directamente de los requisitos a la codificación de software
a la medida del cliente, sin saber con certeza qué codificar para satisfacer
de la mejor manera los requerimientos y sin comenzar desde un principio
pensando en la reutilización del código. Un alto nivel de abstracción
también permite discusiones sobre diversos niveles y soluciones
arquitectónicas. Éstas se pueden acompañar por las representaciones
visuales de la arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en
todos los aspectos de la producción. El aseguramiento de la calidad forma
parte del proceso de desarrollo y no de un grupo independiente.

Ciclo de vida

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan

varias iteraciones en número variable según el proyecto y en las que se
hace un mayor o menor hincapié en las distintas actividades. En la Figura
muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la
que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan
hacia la comprensión del problema y la tecnología, la delimitación del
ámbito del proyecto, la eliminación de los riesgos críticos, y al
establecimiento de una baseline (Linea Base) de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades
de modelado del negocio y de requerimientos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la
baseline de la arquitectura, abarcan más los flujos de trabajo de
requerimientos, modelo de negocios (refinamiento), análisis, diseño y una
parte de implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por
medio de una serie de iteraciones.
Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis
y diseño y se procede a su implementación y pruebas. Se realiza una
pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que
se termine la implementación de la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto
preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero
que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
Principales características
• Forma disciplinada de asignar tareas y responsabilidades (quién hace
qué, cuándo y cómo)
• Pretende implementar las mejores prácticas en Ingeniería de
Software
• Desarrollo iterativo
• Administración de requisitos
• Uso de arquitectura basada en componentes

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

• Control de cambios
• Modelado visual del software
• Verificación de la calidad del software
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. Incluye artefactos (que son los productos tangibles del proceso como
por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles
(papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso)....
Fases
• Establece oportunidad y alcance
• Identifica las entidades externas o actores con las que se trata
• Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las
disciplinas:
Proceso: Las etapas de esta sección son:
• Modelado de negocio
• Requisitos
• Análisis y Diseño
• Implementación
• Pruebas
• Despliegue
Soporte: En esta parte nos encontramos con las siguientes etapas:
• Gestión del cambio y configuraciones
• Gestión del proyecto
• Entorno
La estructura dinámica de RUP es la que permite que éste sea un proceso
de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas
las 4 fases descritas anteriormente:
• Inicio(También llamado Incepción)
• Elaboración
• Desarrollo(También llamado Implementación,Construcción)
• Cierre (También llamado Transición)
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura estática)
realiza una serie de artefactos que sirven para comprender mejor tanto el
análisis como el diseño del sistema (entre otros). Estos artefactos (entre
otros) son los siguientes:
Inicio:
• Documento Visión
• Especificación de Requerimientos
Elaboración:

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

• Diagramas de caso de uso

Construcción:
• Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lógica:
• Diagrama de clases
• Modelo E-R (Si el sistema así lo requiere)
Vista de Implementación:
• Diagrama de Secuencia
• Diagrama de estados
• Diagrama de Colaboración
Vista Conceptual:
Modelo de dominio
Vista física:
Mapa de comportamiento a nivel de hardware.
• Essential Unified Process for Software Development (EssUP)
• Fusebox Lifecycle Process (FLiP)
• Software Process Improvement and Capability dEtermination (SPICE)
• Métrica
• Jackson System Development (JSD)
• Joint Application Development (JAD)
• Open Unified Process (OpenUP)

Metodologías ágiles
• Extreme Programming (XP)
PROGRAMACIÓN EXTREMA XP
Metodología ágil basada en cuatro principios: simplicidad, comunicación,
retroalimentación y valor. Además, orientada por pruebas y refactorización,
se diseña e implementan las pruebas antes de programar la funcionalidad,
el programador crea sus propios tests de unidad.
Este método es típicamente atribuido a Kent Beck, Ron Jeffries y Ward
Cinningham. El objetivo de Xp son grupos pequeños y medianos de
construcción de software en donde los requisitos aún son muy ambiguos,
cambian rápidamente o son de alto riesgo. Xp busca la satisfacción del
cliente tratando de mantener durante todo el tiempo su confianza en el
producto. Además, sugiere que el lugar de trabajo sea una sala amplia, si es
posible sin divisiones (en el centro los programadores, en la periferia los
equipos individuales). Una ventaja del espacio abierto es el incremento en la
comunicación y el proporcionar una agenda dinámica en el entorno de cada
proyecto.
• Scrum
• Agile Modeling Adaptive Software Development (ASD)
• Crystal Clear
• Dynamic Systems Development Method (DSDM)

ALUMNO: JACK JAREK SILVANO TAMANI

Universidad Nacional De La Amazonia Peruana

• Feature Driven Development (FDD)

• Lean Software Development (LSD)
• Agile Unified Process (AUP)
• Software Development Rhythms
• Agile Documentation
• ICONIX Process
• Microsoft Solutions Framework (MSF)
• Agile Data Method
• Database Refactoring
• LeanCMMI

ALUMNO: JACK JAREK SILVANO TAMANI