MODELOS DE PROCESO DE

SOFTWARE
Integrantes: Miguel A. Pacosillo Limachi
Gabriela Quispe Apaza
Marco A. Sanchez Acarapi
Materia: Ingeniería de Software
EXTREME PROGRAMMING (XP)
Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el
éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos
los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los
cambios.

CARACTERISTICAS:
 Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
 Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión Se aconseja escribir el código de la prueba
antes de la codificación.
 Programación por parejas: se recomienda que las tareas de desarrollo se lleven
a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad
del código escrito de esta manera: el código es revisado y discutido mientras se
escribe, es más importante que la posible pérdida de productividad inmediata.
 Frecuente interacción del equipo de programación con el cliente o usuario. Se
recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
 Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer
entregas frecuentes.
FASES DE XP
1ª Fase: Planificación del proyecto. 3ª Fase: Codificación.
 Historias de usuario. 4ª Fase: Pruebas.
 Release planning.  El uso de los test en X.P es el siguiente.
Test de aceptación.
 Iteraciones:
Velocidad del proyecto.
Programación en pareja.
Reuniones diarias. Ventajas:
 Programación organizada.
2ª Fase: Diseño.
 Menor taza de errores.
 Diseños simples.
 Satisfacción del programador.
 Glosarios de términos.
Desventajas:
 Riesgos.  Es recomendable emplearlo solo en proyectos a
corto plazo.
 Funcionalidad extra.
 Altas comisiones en caso de fallar.
 Tarjetas C.R.C. (Class,
Responsabilities and Collaboration)
METODOLOGIA RUP
Rational Unified Process El Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y otros de
la Rational como el proceso complementario al UML. El RUP es un armazón de proceso y como tal puede
acomodar una gran variedad de procesos.
El RUP puede usarse en un estilo muy tradicional de cascada o de una manera ágil. Como resultado se puede
usar el RUP como un proceso ágil o como un proceso pesado - todo depende de cómo lo adapte a su ambiente.
CARACTERISTICAS:
 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
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software
FASES DE RUP
1ª Fase: Incepción.
 Significa “comienzo”, Se especifican
los objetivos del ciclo de vida del
proyecto y las necesidades de cada
participante, Establecer el alcance y
las condiciones de límite y los
criterios de aceptabilidad. Se
identifican los casos de uso que
orientarán la funcionalidad.
2ª Fase: Elaboración.
 Se analiza el dominio del problema y
se define el plan del proyecto. RUP
presupone que la fase de elaboración
brinda una arquitectura
suficientemente sólida junto con
requerimientos y planes bastante
estables. Se describen en detalle la
infraestructura y el ambiente de
desarrollo, así como el soporte de
herramientas de automatización.
3ª Fase: Construcción.
 Se desarrollan, integran y verifican todos los
componentes y rasgos de la aplicación. RUP
considera que esta fase es un proceso de
manufactura, en el que se debe poner énfasis en la
administración de los recursos y el control de
costos, agenda y calidad.
4ª Fase: Transición.
 Comienza cuando el producto está suficientemente
maduro para ser entregado. Se corrigen los últimos
errores y se agregan los rasgos pospuestos. La fase
consiste en prueba beta, piloto, entrenamiento a
usuarios y despacho del producto a mercadeo,
distribución y ventas. Se produce también la
documentación.
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
METODOLOGÍA SCRUM
Scrum es una metodología ágil de desarrollo, aunque surgió como modelo para el desarrollo de
productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que
requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de
software.
Es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en el
seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del
proyecto.

CARACTERISTICAS:
 Equipos autodirigidos
 Utiliza reglas para crear un entorno ágil de administración de proyectos
 No prescribe prácticas específicas de ingeniería
 Los requerimientos se capturan como ítems de la lista Product Backlog.
 El producto se construye en una serie de Sprints de un mes de duración.
FASES DE SCRUM
1.- Pre-juego
 Planificación: Definición de una nueva versión basada en la pila actual, junto
con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta
fase abarca tanto la visión como el análisis. Si se trata de la mejora de un
sistema existente comprende un análisis de alcance más limitado.
 Arquitectura: Diseño de la implementación de las funcionalidades de la pila.
Esta fase incluye la modificación de la arquitectura y diseño generales.
2.- Juego
 Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con
respeto continuo a las variables de tiempo, requisitos, costo y competencia.
La interacción con estas variables define el final de esta fase. El sistema va
evolucionando a través de múltiples iteraciones de desarrollo o sprints.
3.- Post-juego
 Preparación para el lanzamiento de la versión, incluyendo la documentación
final y pruebas antes del lanzamiento de la versión.
VENTAJAS
 Evaluación en cada fase que permite cambios de objetivos.
 Funciona bien en proyectos de innovación.
 Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de
desarrollar el software.
 Seguimiento detallado en cada una de las fases.
DESVENTAJAS
 La evaluación de riesgos es compleja
 Excesiva flexibilidad para algunos proyectos
 Se pone al cliente en una situación que puede ser muy incómoda .
 El cliente deberá ser capaz de describir y entender a un gran nivel de detalle
para poder acordar un alcance del proyecto con él.
METODOLOGIA AUP (AGIL UNIFIED PROCESS)
El AUP es un acercamiento aerodinámico a desarrollo del software basado en el
Proceso Unificado Rational de IBM (RUP), basado en disciplinas y entregables
incrementales con el tiempo. El ciclo de vida en proyectos grandes es serial
mientras que en los pequeños es iterativo. Las disciplinas de Aup son:
Modelado, Implementación, Prueba, Despliegue, Administración de la
configuración, Administración o gerencia del Proyecto, Entorno .

Características:
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
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 interactúa con él

Casos de uso como el hilo conductor que orienta las actividades de

Desarrollo
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 software
• 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

1ra fase Iniciación.
 El objetivo de esta fase es identificar el alcance inicial del proyecto, una
arquitectura potencial para el sistema y obtener, si procede, financiación
para el proyecto y la aceptación por parte de los promotores del sistema.
2da fase Elaboración.
 Mediante esta fase se pretende identificar y validar la arquitectura del
sistema.
3ra fase Construcción.
 El objetivo de esta fase consiste en construir software desde un punto de
vista incremental basado en las prioridades de los participantes.
4ta fase Transición.
 En esta fase se valida y despliega el sistema en el entorno de producción.
VENTAJAS:
El personal sabe lo que esta haciendo: no obliga a conocer detalles.

Simplicidad: apuntes concisos.

Agilidad: procesos simplificados del RUP

Centrarse en actividades de alto valor: esenciales para el desarrollo.

Herramientas independientes: a disposición del usuario.

Fácil adaptación de este producto: de fácil acomodo (HTML)

DESVENTAJAS:
El AUP es un producto muy pesado en relación al RUP.

Como es un proceso simplificado, muchos desarrolladores eligen trabajar con el RUP,

por tener a disposición mas detalles en el proceso.
METODOLOGIA RAD
El desarrollo rápido de aplicaciones o RAD ( rapid application development) es un
proceso de desarrollo de software, desarrollado inicialmente por James Martin
en1980. El método comprende el desarrollo interactivo, la construcción de prototipos
y el uso de utilidades CASE (Computer Aided Software Engineering).
Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la
usabilidad, utilidad y la rapidez de ejecución.

CARACTERISTICAS:
Equipos Híbridos
 Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y
usuarios de tiempo completo del sistema así como aquellas personas
involucradas con los requisitos.
 Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y
programadores en uno.
Herramientas Especializadas
 Desarrollo "visual"
 Creación de prototipos falsos (simulación pura)
 Creación de prototipos funcionales
 Múltiples lenguajes
 Calendario grupal
 Herramientas colaborativas y de trabajo en equipo
 Componentes reusables
 Interfaces estándares (API)
"Timeboxing“

Las funciones secundarias son eliminadas como sea necesario para cumplir con el
calendario.

Prototipos Iterativos y Evolucionarios.

Reunión JAD (Joint Application Development):

 Se reunen los usuarios finales y los desarrolladores.
 Lluvia de ideas para obtener un borrador inicial de los requisitos.
Iterar hasta acabar:
 Los desarrolladores construyen y depuran el prototipo basado en los requisitos
actuales.
 Los diseñadores revisan el prototipo.
 Los clientes prueban el prototipo, depuran los requisitos.
 Los clientes y desarrolladores se reúnen para revisar juntos el producto,
refinar los requisitos y generar solicitudes de cambios.
 Los cambios para los que no hay tiempo no se realizan. Los requisitos
secundarios se eliminan si es necesario para cumplir el calendario.

FASES DE RAD
1ra fase Modelado de gestión: el flujo de información entre las funciones
de gestión se modela de forma que responda a las siguientes preguntas:
¿Qué información conduce el proceso de gestión? ¿Qué información se
genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la
proceso?
2da fase Modelado de datos: el flujo de información definido como parte de la fase de
modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar
la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las
relaciones entre estos objetos.

3ra fase Modelado de proceso: los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de información necesario para implementar
una función de gestión. Las descripciones del proceso se crean para añadir, modificar,
suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

4ta fase Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta

generación. En lugar de crear software con lenguajes de programación de tercera generación,
el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando
es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se
utilizan herramientas automáticas para facilitar la construcción del software.

5ta fase Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas.
Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las
interfaces a fondo.
VENTAJAS:
 Comprar puede ahorrar dinero en comparación con construir.
 Los entregables pueden ser fácilmente trasladados a otra plataforma.
 El desarrollo se realiza a un nivel de abstracción mayor.
 Visibilidad temprana.
 Mayor flexibilidad.
 Menor codificación manual.
 Mayor involucramiento de los usuarios.
 Posiblemente menos fallas.
 Posiblemente menor costo.
 Ciclos de desarrollo más pequeños.
 Interfaz gráfica estándar.
DESVENTAJAS:
 Comprar puede ser más caro que construir.
 Costo de herramientas integradas y equipo necesario.
 Progreso más difícil de medir.
 Menos eficiente.
 Menor precisión científica.
 Riesgo de revertirse a las prácticas sin control de antaño.
 Más fallas (por síndrome de “codificar a lo bestia”).
 Prototipos pueden no escalar, un problema mayúsculo.
 Funciones reducidas (por “timeboxing”).
 Dependencia en componentes de terceros: funcionalidad de más o
de menos, problemas legales.
MODELO LINEAL SECUENCIAL

También llamado "Ciclo de vida básico " tiene su origen en el "Modelo de cascada
“ basado en el modelo en cascada de Winston Royce, sugiere un enfoque
sistemático o más bien secuencial del desarrollo de software que comienza en un
nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento.
CARACTERISTICAS:
 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
FASES DEL MODELO LINEAL SECUENCIAL
1. Ingeniería y Análisis del Sistema:
 Debido a que el software es siempre parte de un sistema mayor el trabajo comienza
estableciendo los requisitos de todos los elementos del sistema y luego asignando
algún subconjunto de estos requisitos al software.
2. Análisis de los requisitos del software:
 El proceso de recopilación de los requisitos se centra e intensifica especialmente en
el software. El ingeniero de software (Analistas) debe comprender el ámbito de
la información del software, así como la función, el rendimiento y las interfaces
requeridas.
3. Diseño:
 El diseño del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz. El proceso de diseño tradúcelos requisitos en una
representación del software con la calidad requerida antes de que comience la
codificación. Se dividen en:
 Diseño de Alto Nivel o Arquitectónico
 Diseño Detallado
4. Codificación:
 El diseño debe traducirse en una forma legible para la maquina.El paso de codificación
realiza esta tarea. Si el diseño se realiza de unamanera detallada la codificación puede
realizarse mecánicamente.
5. Prueba:
 Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra
en la lógica interna del software, y en las funciones externas, realizando pruebas que
aseguren que la entrada definida produce los resultados que realmente se requieren. Existen
varios tipos de pruebas:
 Pruebas de unidad
 Pruebas de integración
 Prueba de sistema
 Prueba de aceptación
6. Mantenimiento:
 El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán
debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del
entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente
requiera ampliaciones funcionales o del rendimiento. Los tipos de mantenimiento son:
 Mantenimiento Preventivo o Perfectivo
 Mantenimiento Correctivo
 Mantenimiento Evolutivo
VENTAJAS:
 Se tiene todo bien organizado y no se mezclan las fases.
 Modelo y planificación fácil y sencillos.
 Este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el
software.
 Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los
requerimientos y se conozca muy bien la herramienta a utilizar.
 Los usuarios lo pueden comprender fácilmente.
DESVENTAJAS:
 Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay
iteraciones y se crean problemas en la aplicación del paradigma.
 Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El
ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden
existir al comienzo de muchos productos.
 El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una
versión operativa del programa. Un error importante no detectado hasta que el programa este
funcionando puede ser desastroso. Alto riesgo en sistemas nuevos debido a problemas en las
especificaciones y en el diseño.
 Los responsables del desarrollo de software siempre se retrasan innecesariamente.
MODELO DE PROPOTIPOS
También conocido como Desarrollo con Prototipación, se inicia con la
definición de los objetivos globales para el software, luego se identifican
los requisitos conocidos y las áreas del esquema en donde es necesaria
más definición. Entonces se plantea con rapidez una iteración de
construcción de prototipos y se presenta el modelado (en forma de un
diseño rápido).

Características
 El prototipo es una aplicación que funciona2.
 Los prototipos se crean con rapidez3.
 Los prototipos evolucionan a través de un proceso iterativo4.
 Los prototipos tienen un costo bajo de desarrollo
Tipos De Prototipos.
1. El prototipo evolutivo: entrega a los usuarios finales un sistema funcionando. Se usa
con los requerimientos que mejor se comprenden. Desarrollado a base de incrementos de
acuerdo a la realimentación y los requerimientos detectados en sus versiones.
2. El prototipo desechable: valida o deriva los requerimientos del sistema. Se usa con los
requerimientos que no se conocen bien. Período de vida corto.
3. El prototipado rápido: Comienza en las áreas de mayor riesgo. Si supera obstáculos, se
puede desarrollar el resto del sistema a partir del prototipo, sino se puede descartar sin
tener que gastar más dinero.
FASES DEL MODELO DE PROTOTIPOS:
Identificar los requerimientos conocidos.
 Los analistas y los usuarios trabajan juntos para identificar los requerimientos conocidos
que tienen que satisfacerse. Se debe: determinar los fines del sistema y el alcance de su
capacidad.
Desarrollar modelo que funcione.
Los desarrolladores explican a los usuarios:
 El método
 Las actividades a realizar
En el desarrollo del prototipo se preparan los siguientes componentes:
 Pantallas y formatos para la entrada de datos
 Módulos esenciales de procesamiento
 Salida del sistema
En esta fase no se prepara la documentación ni las especificaciones de salida o de diseño del software.
Utilizar el prototipo.
 La responsabilidad de trabajar con el prototipo y evaluar sus características y operación es del usuario. La
experiencia con el sistema bajo condiciones reales permite determinar los cambios o mejoras o eliminar
características innecesarias.
Revisar el prototipo.
 Se realiza la evaluación y con la información obtenida se levantan las características que debe llevar la siguiente
versión del prototipo.
¿Prototipo terminado?
Los pasos anteriores se repiten varias veces, hasta que los usuarios y desarrolladores están de acuerdo en que el
sistema ha evolucionado lo suficiente e incluye todas las características necesarias.
Cuando el prototipo está terminado, el paso que sigue a continuación es tomar la decisión sobre cómo proceder, para
lo cual existen cuatro opciones:
 Abandonar la aplicación: Se descartan el prototipo y la aplicación
 Implantar el prototipo
 Volver a desarrollar la aplicación: El desarrollo del prototipo proporcionó suficiente información para determinar las
características necesarias de toda la aplicación.
Ventajas
 Este modelo es útil cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida.
 También ofrece un mejor enfoque cuando el responsable del desarrollo del
software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de
un sistema operativo o de la forma que debería tomar la interacción humano-
máquina.
Desventajas
 El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara
al sistema final.
 A causa de la intención de crear un prototipo de forma rápida, se suelen
desatender aspectos importantes, tales como la calidad y el mantenimiento a
largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una
vez que el prototipo ha cumplido su función.
EORM (Enhanced Object Relationship Methodology)

Es una Metodología de Relación entre Objeto (Enhanced Object Relationship

Methodology), es definido por un proceso iterativo que se concentra en el
modelado orientado a objetos por la representación de relaciones entre los
objetos (acoplamientos) como objetos, es por ello que fue una de las primeras
propuestas para Web centrada en el paradigma de la orientación a objetos.
Podemos mencionar que esta metodología consta de las siguientes fases:

Fase de Definición y Análisis

Fase de Diseño
Fase de Implementación y Salida a Producción
1. FASE DE ANALISIS

Se realizar un estudio de las necesidades de la aplicación, del entorno de trabajo y de los actores. La finalidad
principal de esta fase es conseguir los escenarios que representen las actividades que se pueden llevar a cabo
en el sistema.

2. FASE DE DISEÑO. El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el
propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su
interpretación y realización física. La etapa del Diseño del Sistema encierra cuatro etapas:

A. El diseño de los datos Trasforma el modelo de dominio de la información, creado durante el análisis, en
las estructuras de datos necesarios para implementar el Software.

B. El Diseño Arquitectónico Define la relación entre cada uno de los elementos estructurales del programa.

C. El Diseño de la Interfaz Describe como se comunica el Software consigo mismo, con los sistemas que
operan junto con el y con los operadores que lo emplean.

D. El Diseño de procedimientos Transforma elementos estructurales de la arquitectura del programa. La

importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del diseño es donde
se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar con precisión los
requerimientos del cliente. El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño
es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a
construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones
técnicas: El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe
acumular todos los requisitos implícitos que desea el cliente.
3. FASE DE IMPLEMENTACION Y SALIDA A PRODUCCION
La fase de implementación es conocida también como fase de codificación, pues
supone todo el proceso de escribir el código software necesario que hará posible que
el sistema finalmente implementado cumpla con las especificaciones establecidas en
la fase de análisis de requisitos y responda al diseño del sistema descrito en la fase
anterior.
VENTAJAS
 Flexibilidad entre relaciones de los nodos.
 La reutilización de código y librerías.
 Encajamiento de relaciones semánticas
DESVENTAJAS
 Problemas a funcionamiento del sistema o aspectos de interfaz.
 La captura de requisitos es muy pobre.
 Falta de comentarios o documentación.
MODELO DE ESPIRAL
El modelo en espiral es un tipo de modelo basado en el desarrollo iterativo. Se
diferencia del modelo iterativo incremental en que más que representarlo como una
secuencia de actividades se representa como una espiral donde cada ciclo en la
espiral representa una fase del proceso del software. Así, por ejemplo, el ciclo más
interno podría referirse a la especificación de requerimientos y el siguiente ciclo al
diseño.
CARACTERÍSTICAS DEL MODELO EN ESPIRAL
 Es considerado como un modelo evolutivo ya que combina el modelo clásico con el
diseño de prototipos.
 Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente.
 Este modelo es el indicado para desarrollar software con diferentes versiones
actualizadas como se hace con los programas modernos de PC´s.
 La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de
construcción de prototipos.
 Este es el enfoque más realista actualmente
El modelo en espiral esta compartida en varias actividades estructurales, también llamadas
regiones de tareas. Existen seis regiones de tareas que son:
 Comunicación con el cliente: esta es una tarea requerida para establecer comunicación
entre el desarrollador y el cliente.
 Planificación: esta tarea es necesaria aplicarla para pode definir los recursos, el tiempo y
otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos.
 Análisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo en
espiral, es requerida para evaluar los riesgos técnicos y otras informaciones relacionadas
con el proyecto.
 Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más
representaciones de la aplicación.
 Construcción y adaptación: esta tarea es requerida en el modelo espiral porque se necesita
construir, probar, instalar y proporcionar soporte al usuario.
 Evaluación el cliente: esta también es una tarea principal, necesaria para adquirir la
reacción del cliente según la evaluación de las representaciones del software creadas
durante la etapa de ingeniería y la de implementación creada durante la etapa de
instalación.
FASES DEL MODELO ESPIRAL
 1. Determinar los objetivos: En esta fase del proyecto se definen los objetivos
específicos. Se identifican las restricciones del proceso y del sistema software, y se
traza un plan detallado de gestión. Se identifican los riesgos. Dependiendo de estos
riesgos se planean estrategias alternativas.
 2. Análisis del riesgo: Se lleva a cabo un análisis detallado para cada uno de los
riesgos del proyecto identificados. Se definen los pasos a seguir para reducir los
riesgos.
 3. Desarrollar y validar: Después de la evaluación de riesgos, se elige un modelo para
el desarrollo del sistema software y se desarrolla.
 4. Planificación: El proyecto se revisa y se toma la decisión si se debe continuar con
un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para
la siguiente fase del proyecto.
 Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia
el exterior), se construyen sucesivas versiones del software, cada vez más completa y,
al final, el propio sistema software totalmente funcional.
VENTAJAS DEL MODELO ESPIRAL
 No requiere una definición completa de los requerimientos del software a
desarrollar para comenzar su funcionalidad.
 En la terminación de un producto desde el final de la primera iteración es
muy factible aprobar los requisitos.
 Sufrir retrasos corre un riesgo menor, por que se comprueban los conflictos
presentados tempranamente y existe la forma de poder corregirlos a tiempo.
DESVENTAJAS DEL MODELO ESPIRAL
 Existe complicación cuando se evalúa los riesgos.
 Se requiere la participación continua por parte del cliente.
 Se pierde tiempo al volver producir inicialmente una especificación completa
de los requerimientos cuando se modifica o mejora el software.
MODELO INCREMENTAL
El modelo incremental de gestión de proyectos tiene como objetivo un crecimiento
progresivo de la funcionalidad. Es decir, el producto va evolucionando con cada una de las
entregas previstas hasta que se amolda a lo requerido por el cliente o destinatario.
Este enfoque, que se usó inicialmente para proyectos de software aunque más tarde se
aplicó a otros sectores, establece entregas parciales mediante un calendario de plazos. En
cada una de ellas, el producto debe mostrar una evolución con respecto a la fecha
anterior; nunca puede ser igual.
CARACTERISTICAS:
 Los incrementos son pequeños.
 Permite una fácil administración de las tareas en cada iteración.
 La inversión se materializa a corto plazo.
 Es un modelo propicio a cambios o modificaciones.
 Se adapta a las necesidades que surjan.
FASES DEL MODELO INCREMENTAL:
 Requerimientos: son los objetivos centrales y específicos que persigue el proyecto.
 Definición de las tareas y las iteraciones: teniendo en cuenta lo que se busca, el siguiente paso es
hacer una lista de tareas y agruparlas en las iteraciones que tendrá el proyecto. Esta agrupación no
puede ser aleatoria. Cada una debe perseguir objetivos específicos que la definan como tal.
 Diseño de los incrementos: establecidas las iteraciones, es preciso definir cuál será la evolución
del producto en cada una de ellas. Cada iteración debe superar a la que le ha precedido. Esto es lo
que se denomina incremento.
 Desarrollo del incremento: posteriormente se realizan las tareas previstas y se desarrollan los
incrementos establecidos en la etapa anterior.
 Validación de incrementos: al término de cada iteración, los responsables de la gestión del
proyecto deben dar por buenos los incrementos que cada una de ellas ha arrojado. Si no son los
esperados o si ha habido algún retroceso, es necesario volver la vista atrás y buscar las causas de
ello.
 Integración de incrementos: una vez son validados, los incrementos dan forma a lo que se
denomina línea incremental o evolución del proyecto en su conjunto. Cada incremento ha
contribuido al resultado final.
 Entrega del producto: cuando el producto en su conjunto ha sido validado y se confirma su
correspondencia con los objetivos iniciales, se procede a su entrega final.
Ventajas
 Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya
que se implementa la funcionalidad parcial.
 También provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del Software.
 El modelo proporciona todas las ventajas del modelo en cascada
realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
 Permite entregar al cliente un producto más rápido en comparación del
modelo de cascada.
 Resulta más sencillo acomodar cambios al acotar el tamaño de los
incrementos.
 Por su versatilidad requiere de una planeación cuidadosa tanto a nivel
administrativo como técnico.
Desventajas
 El modelo Incremental no es recomendable para casos de sistemas de tiempo
real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto
índice de riesgos.
 Requiere de mucha planeación, tanto administrativa como técnica.
 Requiere de metas claras para conocer el estado del proyecto.
 METODOLOGIA UWE
Es una herramienta para modelar aplicaciones web, utilizada en la ingeniería web, prestando
Especial atención en sistematización y personalización(sistemas adaptativos).
CARACTERISTICAS:
* Es una metodología detallada para el proceso de autoría de aplicaciones con una definición
exhaustiva del proceso de diseño que debe ser utilizado.
* Este proceso, iterativo e incremental, incluye flujos de trabajo y puntos de control, y sus fases
coinciden con las propuestas en el Proceso Unificado de Modelado.
* UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace especial
hincapié en características de personalización, como es la definición de un modelo de usuario o una
etapa de definición de características adaptativas de la navegación en función de las preferencias,
conocimiento o tareas de usuario.
* Otras características relevantes del proceso y método de autoría de UWE son el uso del paradigma
orientado a objetos, su orientación al usuario, la definición de un meta-modelo (modelo de referencia)
que da soporte al método y el grado de formalismo que alcanza debido al soporte que proporciona para
la definición de restricciones sobre los modelos.
FASES:
1) Captura, análisis y especificación de requisitos: En
simple palabras y básicamente, durante esta fase, se
adquieren, reúnen y especifican las características
funcionales y no funcionales que deberá cumplir la
aplicación web
2) Diseño del sistema: Se basa en la especificación de
requisitos producido por el análisis de los requerimientos
(fase de análisis).
VENTAJAS
* Uso exclusivo de estándares reconocidos como UML
compatible con internacionalmente.
*Establece un formalismo más rígido.
DESVENTAJAS
* Uso de restricciones escritas

3) Codificación del software: Durante esta etapa se

realizan las tareas que comúnmente se conocen como
programación
4) Pruebas: Las pruebas se utilizan para asegurar el
correcto funcionamiento de secciones de código
5) La Instalación o Fase de Implementación: Proceso por
el cual los programas desarrollados son transferidos
apropiadamente al computador destino
6) El Mantenimiento: Es el proceso de control, mejora y
optimización del software ya desarrollado e instalado,
que también incluye depuración de errores y defectos que
puedan haberse filtrado de la fase de pruebas descontrol.
 METODOLOGIA SOHDM(SCENARIO BASED
OBJECT-ORIENTED HYPRMEDIA DESING
METHODOLOGY)
Es un método que desarrolla diseño en panoramas(escenario) orientada a objetos en hipermedia el
Cual presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema. Para
ello propone el uso de escenarios.
CARACTERISTICAS:
* Desarrolla Diseño en panoramas (escenario) Orientada a Objetos en Hipermedia (Scenario - based Object-
oriented Hypermedia Design Methodology).
* Presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema para ello,
propone el uso de escenarios.
* Es una de las primeras propuestas para la web y brinda más importancia a la tarea de tratamiento de
requisitos. Se caracteriza principalmente porque su ciclo de vida comienza con la aplicación de los escenarios
como técnica de licitación y definición de requisitos.
FASE I Fase de Análisis VENTAJAS:
Se realizar un estudio de las necesidades de la
aplicación, del entorno de trabajo y de los
actores. * Tienen la compatibilidad de plataforma que las
aplicaciones descargables.
Fase 2 fase de modelado de objetos
* Están siempre actualizadas con el ultimo
Se desarrolla un diagrama de clases que
representa la estructura conceptual del sistema.
lanzamiento.
* No necesitan ser instaladas ni descargadas ni
Fase 3 fase de diseño de vistas
configuradas.
Se reorganizan los objetos en unidades * Son menos propensas a colgarse como se dice
navegacionales que representan una vista de los
objetos del sistema en el lenguaje informático.
DESVENTAJA:
Fase 4 fase de diseño navegacional
Se enriquecen dichas vistas definiendo los * Requieren de navegadores compatibles
enlaces e hiperenlaces que existen en el
sistema. lo cual es una desventaja ya que el usuario
tendrá que actualizar sus versiones anteriores a
Fase 5 fase de diseño de la implementación
la de ahora.
Se diseñan los paginas, la interfaz y la base de
datos del sistema.
* La compañía rastrea todo lo que hacen los
Fase 6 fase de construcción
usuarios son sencillas y baratos.
Se realiza la construcción de la base de datos
del sistema la que se implementa la aplicación.
 METODOLOGIA RMM(RELATIONSHIP
MANAGEMET METODOLOGY)
Se define como un proceso de análisis, diseño y desarrollo de aplicaciones hipermedia.
Esta metodología es apropiada para dominios con estructuras regulares (es decir con
clases de objetos bien definidas, y con clase relacionales entre esas clases).
Características:
* Es un proceso de análisis diseño y desarrollo de aplicaciones hipermedia.
* El modelo propone un lenguaje que permite describir los objetos del dominio sus
interrelaciones y los mecanismos de navegación hipermedia de la aplicación.
* Permiten combinar primitivas de acceso con otros slices de otros entidades para crear
un m-slice.
FASES:
*Diseño entidad relación.
*Realizar los diseños de slice.
*Diseñar la navegación.
*Definir el protocolo de conversión.
*Diseñar la interfaz.
*Implementar la aplicación.
*Probar la aplicación.
VENTAJAS:
* Permite un enfoque estructurado para el diseño.
* facilita a los usuarios para navegar.
• fácil el mantenimiento.
DESVENTAJAS:
* Se elimina el spaghetti como código.
* Los diferentes grupos al mismo tiempo no pueden
trabajar con el diseño.
* RMM desarrollo sistema web son fáciles de actualizar
pero así también entra un desconocido.
• RMM la revisión del look and feel de un sitio web (que
se hace muy a menudo )
METOLOGIA OOHDM (OBJECT ORIENTED
IPERMEDIA DESING METHOD)
El modelo o metodología OOHDM nos ayuda para el diseño de aplicaciones hipermedia y para
la web, fue diseñada por D. Schwabe, G Rossi, and S. D. J. Barbosa es una extensión de HDM
con orientación a objetos .
Ha sido usada para diseñar diferentes tipos de aplicaciones hipermedia como galerías
interactivas con presentaciones multimedia y sobre todo numerosos sitios web.

CARACTERISTICAS:

* Propone el desarrollo de aplicaciones hipermedia a través de unos procesos.

* Los modelos orientados a objetos se construyen en cada paso que mejorara los modelos
diseñados en iteraciones
* El modelo de interfaz ADVs (vista de datos abstracta) Especifica la organización y
comportamiento de la interfaz pero la apariencia física real o de los atributos y la disposición
de las propiedades de la ADVs en la pantalla real.
FASES:
**Diseño conceptual
El desarrollo se inicia diseñando la capa
conceptual, siendo el principal objetivo de esta
etapa capturar los conceptos involucrados en
el dominio de la aplicación y describirlos en
detalle
**Diseño navegacional
La capa navegacional se compone de objetos
construidos a partir de objetos conceptuales y
construyen en general los elementos
canónicos de las aplicaciones.
**Diseño de Interfaz Abstracta
Una vez que las estructuras navegacionales
son definidas se deben especificar los
aspectos de la interfaz
**Implementación
En esta fase el diseñador debe implementar el
diseño ya que los modelos fueron construidos
en forma independiente de la plataforma de
implementación es tenido en cuenta el entorno
particular en el cual se va acorrer
aplicación.
VENTAJAS:
* Vista de datos abstracta
* Facilita el traslado del diseño conceptual a la
implementación
* Proveyendo al programador con herramientas
que permiten reducir la distancia entre el mundo
real y la programación de la solución
* Una separación clara entre lo conceptual, la
navegación y lo visual
DESVENTAJAS:
* Es un punto crítico en el desarrollo que las
modernas metodologías tienden a descuidar
* A dejado fuera su ámbito en aspecto esencial
la funcionalidad del sistema
la
 METODOLOGIA RNA(METODO DE ANALISIS
DE NAVEGACION RELACIONAL)
Es un método de Análisis de Navegación
Relacional (Relationship Navigational Analysis), que define una secuencia de pasos que se
utilizarán para el desarrollo de la Web. Es especialmente útil para uso de la Web creados en base
de sistema de herencia.
En este método encontramos cinco fases las cuales son: Análisis del entorno, donde el propósito
de esta fase es el de estudiar las características de la audiencia, luego encontramos las
definiciones de elementos de interés, el análisis del conocimiento y navegación y finalmente la
implementación de los análisis realizados.
La propuesta de RNA es quizás una de las que más ha resaltado la necesidad de trabajar con la
especificación de requisitos, incluyendo tareas como el análisis del entorno y de los elementos de
interés. Además, resulta interesante pues plantea la necesidad de analizar los requisitos
conceptuales de manera independiente a los navegacionales.
FASES:
1 Fase de Análisis del Entorno, se determinar y
clasifica a los usuarios finales de la aplicación en VENTAJAS
grupos según sus perfiles
2 Fase de Definición de Elementos: Aquí prosiguen * Analizar los requisitos conceptuales de
los elementos de interés en la cual se han listando manera independiente a los navega
dichos elementos de la aplicación. Por elementos de
interés se entienden los documentos, las pantallas relacionales.
que se van a requerir, la información, etc.
3 Fase de Análisis del * Dispone de documentación
Conocimiento, se desarrollar un esquema que detallada de sistema
represente a la aplicación. Para ello RNA propone
identificar los objetos, los procesos y las operaciones
que se van a poder realizar en la aplicación, así DESVENTAJAS
como las relaciones que se producen entre estos
elementos
4 Fase de Análisis de * Para proyectos web creados en
Navegación, se verifica que el esquema obtenido en
base de sistema de herencia
la fase anterior sea enriquecido con las posibilidades
de navegación dentro de la aplicación
5 Fase de Implementación del Análisis, cuando
una vez obtenido el esquema final en el que ya se
encuentran incluidos los aspectos de navegación, se
pasa el esquema a un lenguaje entendible por la
máquina
 METODOLOGIA UML(LENGUAJE DE
MODELADO UNIFICADO )

UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”. Se trata de un
estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear
esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos)
CARACTERISTICAS:
* Enfoque de ingeniería de software para el dominio web con el objeto de cubrir todo el ciclo.
* Se trata de un método que hace uso de técnicas de procedentes de orientación de objetos para
especificar aplicaciones hipermedia
Moldea aspectos dinámicos
* Se hace uso de modelos de tarea y diagramas de estado mientras la navegación y la presentación se
presentan por medio de UML y de estereotipos creados al efecto.
* Los elementos hipermedia se representan por medio de elementos propios de diagramas de clases
UML
Fase1 Análisis de requisitos
Fija los requisitos funcionales de la aplicación
Web para reflejarlos en un modelo de casos de
uso. Esto da lugar a los diagramas de casos de
uso
Fase 2 Diseño Conceptual
Se construye el modelo conceptual del dominio
de la aplicación considerando los requisitos
reflejados en los casos de uso. El resultado es
el diagrama de clases de dominio.
Fase 3 Diseño navegacional
Se obtiene el modelo de espacio de navegación
y el de estructura de navegación que muestra
como navegar atreves del espacio de
navegación. El resultado son diagramas de
clases que representan estos modelos.
Fase 4 Diseño de Presentación
Representa las vistas del interfaz del usuario
mediante modelos estándares de iteración UML
VENTAJAS:
* Uso de método que hace uso de técnicas
orientado a objetos.
* Ayuda a la navegación (índices o mapas).
* Aumenta la exactitud de los modelos de datos.
* Modelan aspectos dinámicos que hace uso de
modelos de tareas.
DESVENTAJAS:
* Especificación de restricciones
* Se recomienda el uso de restricciones
escritas(OCL: Lenguaje de restricciones de
objetos)
APLICACIÓN:
El modelado sirve no solamente para los
grandes sistemas, aun en aplicaciones de
pequeño tamaño se obtienen beneficios de
modelado, sin embargo es un hecho que entre
más grande y más complejo es el sistema, más
importante es el papel de que juega el
modelado por una simple razón
 METODOLOGIA WSDM(WEB SITE DESIGN
METHOD)
Es un Método de Diseño para Sitios Web (Web Site Design Method), donde hay un acercamiento al
usuario que define los objetos de información basado en sus requisitos de información para el uso
de la Web. En este método se definen una aplicación Web a partir de los diferentes grupos de
usuarios que vaya a reconocer el sistema.

Propone cuatro etapas: modelo de usuario, diseño conceptual, diseño de la implementación e

implementación. El tratamiento de requisitos se lleva a cabo en la etapa inicial, donde, en primer
lugar, se identifican y clasifican los usuarios que van a hacer uso de la aplicación Web.

CARACTERISTICA PRINCIPAL

Basada en grupos de usuarios orientada a kiosco web solo presenta la información al usuario sin
seguridad ni funcionalidad.
Fase de Modelo de Usuario
Se intenta detectar los perfiles de usuarios para
los cuales se construye la aplicación
Fase de Diseño Conceptual
Se desarrolla el modelado conceptual no tiene
el mismo significado que en OOHDM. Durante
el modelado conceptual se realizan dos tareas a
la vez: el modelado de objetos, que es lo que en
OOHDM se llama modelo conceptual y el
diseño de la navegación
Fase de Diseño de Implementación
Se modela la interfaz para cada rol de usuario,
Ahora que se tiene una versión definitiva del
plan se puedan comenzar con la construcción
del sitio web. Durante esta fase
Fase de Realización de Implementación
Se codifican todos estos aspectos en el
lenguaje concreto que se haya seleccionado.
WSDM es también una propuesta viva que está
cambiando y adaptándose a nuevos requisitos.
VENTAJAS:
En cada fase se permite cambios de objetivos.
Funciona bien en proyectos de innovación en la
web.
Es sencillamente, ya que sigue los pasos
intuitivos necesarios a la hora de desarrollar el
software.
Es fácil el uso y una mejor capacidad de
respuesta e interactividad con el usuario.
DESVENTAJAS:
Es crítico en el desarrollo web moderna, las
metodologías tienden a descuidar
A dejado fuera su ámbito en aspecto esencial la
funcionalidad del sistema
Es necesario que los navegadores estén
actualizados ya que tienen algunas dificultades
 MODELO DE CASCADA
En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada (denominado
así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por
gravedad” hacia las siguientes fases), 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. Al final de cada etapa, el modelo está diseñado para llevar a cabo una
revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase.
Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.
CARACTERÍSTICAS

Se debe comprobar el Software después de unirlo y antes de operarlo.

Es el más utilizado.

Deben desarrollarse todas las fases.

Las fases continúan hasta que los objetivos se han cumplido.

Fase 1: Requisitos de la Fase
Ya sea que usted diseñe un pequeño programa para sumar dos números, o usted está en el desarrollo de un sistema de
software para la automatización de toda una compañía aérea, ésta es la primera fase, que no se puede anular. A menos que
usted sepa lo que está pasando con el diseño, no se puede abordar el problema. Aquí, las especificaciones de la salida o el
producto final se estudia y marcado. Si el software que va a ser diseñado no debe contener ciertas características, como por
razones de seguridad, y también se menciona en esta etapa.
Fase 2: Especificación de la Fase
Con todos los requisitos y las limitaciones en la mano, una vista final de cómo el producto debe ser exactamente, se decide. La
forma exacta en que el software debe funcionar se menciona en esta etapa.
Fase 3: Fase de Diseño
Bueno, aquí el trabajo real comienza. Cada tipo de recurso que se necesaria para el correcto diseño del software que se
menciona aquí, en esta fase. ¿Qué tipo de base de datos se requiere, qué tipo de datos debe ser apoyado, etc. son algunos de
los aspectos importantes que se establezca en esta fase. El algoritmo del proceso en el que el software debe estar diseñado se
hace en esta fase.
Etapa 4: Etapa de Implementación y Pruebas
Ahora comienza la parte de codificación. Aquí, el software está diseñado como por el algoritmo. Por lo tanto se hace muy
importante que el algoritmo debe ser diseñada adecuadamente. El software diseñado según el algoritmo tiene que ir a través de
pruebas de software constante y procesos de corrección de errores para saber si hay alguna falla o error.
Etapa 5: Fase de Integración y Ensayos
Aquí los distintos códigos diseñados por diferentes programadores se integran y se comprueba si el software funciona de
acuerdo con las especificaciones establecidas.
Fase 6: Fase de mantenimiento
El trabajo de desarrollo de software no termina con la entrega del software para el cliente. Los diseñadores de software puede
tener que proporcionar constantemente el apoyo al cliente para resolver cualquiera de los problemas que puedan surgir.
VENTAJAS:
* No hace falta mencionar, es un modelo lineal y, por supuesto, los modelos lineales son las más simples a ser
implementadas.
* La cantidad de recursos necesarios para implementar este modelo es mínimo.
* Una gran ventaja del modelo de cascada es que la documentación se produce en cada etapa del desarrollo del
modelo de cascada. Esto hace que la comprensión del producto diseñar procedimiento más sencillo.
DESVENTAJAS:
• Irónicamente, la mayor desventaja del modelo de cascada es uno de sus mayores ventajas. No se puede
volver atrás, si la fase de diseño ha ido mal, las cosas pueden ser muy complicado en la fase de ejecución.
• Los Muchas veces, sucede que el cliente no es muy clara de lo que exactamente quiere de el software.
Cualquier cambio que se menciona en el medio puede causar mucha confusión.
Se aplica en situaciones en las que el software es simple y el dominio de requerimientos es bien conocido
también en proyectos complejos.
METODOLOGIA OMT(Object Modelin Technique)
La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en
1991, mientras James dirigía un equipo de investigación de los laboratorios General Electric. OMT es una de
las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la
actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le
permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución
para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software.
CARACTERISTICAS:
LA METODOLOGÍA OMT++ emplea tres clases de modelos para describir el sistema:
Modelo de objetos. Describe la estructura estática de los objetos del sistema (identidad, relaciones con otros
objetos, atributos y operaciones). El modelo de objetos proporciona el entorno esencial en el cual se pueden
situar el modelo dinámico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real
que sean importantes para la aplicación. Se representa mediante diagramas de objetos.
Modelo dinámico. Describe los aspectos de un sistema que tratan de la temporización y secuencia de
operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para
los sucesos) y la organización de sucesos y estados.
Modelo funcional. Describe las transformaciones de valores de datos (funciones, correspondencias,
restricciones y dependencias funcionales) que ocurren dentro del sistema. Captura lo que hace el sistema,
independientemente de cuando se haga o de la forma en que se haga. Se representa mediante diagramas de
flujo de datos.
FASES
1. Análisis de objetos: se centra en entender y modelar el problema en el dominio de la aplicación.
2. Diseño del sistema: se determina la arquitectura del sistema en términos de subsistemas.
3.Diseño de objetos: se refina y optimiza el análisis de objetos para implementarlo.
4.Implementación: se codifica y prueba lo ya diseñado.
VENTAJAS:
Proporciona una serie de pasos perfectamente definidos al desarrollador.
Tratamiento especial de la herencia.
Facilita el mantenimiento dada la gran cantidad de información que se genera en el análisis.
Es fuerte en el análisis
DESVENTAJAS:
* Hay pocos métodos para encontrar inconsistencias en los modelos.
*Interacción de objetos no soportada explícitamente en ninguna herramienta gráfica.
*Al ser un análisis iterativo es difícil de saber cuando comenzar con el diseño.
*Es débil en el diseño
 MODELO EVOLUTIVO
Los evolutivos son modelos iterativos permiten desarrollar versiones cada vez mas complejas hasta
llegar al objetivo final deseado, incluso evolucionar mas allá durante la fase de aprobación.
CARACTERISTICAS:
* Gestionan bien la naturaleza evolutiva del software.
* Son iterativos construyen versiones de software cada vez mas complejas.
* Se adaptan a los cambios de requisitos del producto
*Se adaptan a las fechas de entrega estrictas poco realistas.
*se adaptan alas especificaciones parciales del producto.
El modelo evolutivo es un procesador de texto que se ha desarrollado bajo el paradigma incremental
podría aportar , en principio funciones básicas de edición de archivo y producción de documentos
(algo como un editor simple)
Etapas del modelo evolutivo Basado en
Componentes
PLANEACION: En esta etapa evalúa la función y el
rendimiento que se asignaron al Software durante la
Ingeniería del Sistema de Computadora para establecer
un ámbito de proyecto que no sea ambiguo, e
incomprensible.
ANÁLISIS DE RIESGOS: en esta etapa l analista se
encarga de analizar los riesgos que el software a crear
estará expuesto y así encontrar la manera de
corregirlos.
CONSTRUCCIÓN Y ADAPTACIÓN DE LA INGENIERÍA:
en esta etapa se construye el software, se prueba si no
tiene algún problema o para detectar errores , se instala
, y luego se le brinda soporte al cliente.
VALUACIÓN DEL CLIENTE: el cliente tiene la tarea de
evaluar el software para verificar si este cumple con los
requisitos que este proporciono y esta en todo la tarea *desarrollo
de aprobar o rechazar el software.
VENTAJAS
*La especificación puede desarrollarse de forma
creciente.
*Los usuarios y desarrolladores logran un mejor
entendimiento del sistema. Esto se refleja en una mejora
de la calidad del software.
* Es más efectivo que el modelo de cascada, ya que
cumple con las necesidades inmediatas del cliente.
DESVENTAJAS
* Proceso no Visible: Los administradores necesitan
entregas para medir el progreso. Si el sistema se
necesita desarrollar rápido, no es efectivo producir
documentos que reflejen cada versión del sistema.
* Sistemas pobremente estructurados: Los cambios
continuos pueden ser perjudiciales para la estructura del
software haciendo costoso el mantenimiento.
Se requieren técnicas y herramientas: Para el rápido
se necesitan herramientas que pueden ser
incompatibles con otras o que poca gente sabe utilizar