1. Desarrollo en espiral
Análisis del riesgo
Desarrollar, verificar y validar (probar)
• Tareas de la actividad propia y de prueba.
• Análisis de alternativas e identificación resolución de riesgos.
• Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el
desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo,
cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un
modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo
riesgos de protección son la principal consideración, un desarrollo basado en
transformaciones formales podría ser el más apropiado.
Tareas
Para cada ciclo habrá cuatro actividades:
No. 1-Planificación:
Determinación de objetivos,
alternativas y restricciones.
Revisamos todo lo hecho,
evaluándolo, y con ello decidimos
si continuamos con las fases
siguientes y planificamos la
próxima actividad.
No. 2-Análisis de riesgo:
Análisis de alternativas e
identificación/resolución de
riesgos.
No. 3-Ingeniería:
Desarrollo del producto del “siguiente nivel”
Tareas de la actividad propia y se prueba.
Análisis de alternativas e identificación resolución de riesgos.
No.4-Evaluación del cliente:
Valorización de los resultados de la ingeniería
Ventajas
• Reduce riesgos del proyecto
• Incorpora objetivos de calidad

2. • Integra el desarrollo con el mantenimiento.
Desventajas
• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso
• Requiere experiencia en la identificación de riesgos
Inconvenientes
Planificar un proyecto con esta metodología es a menudo imposible, debido a la
incertidumbre en el número de iteraciones que serán necesarias. En este contexto la
evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha
evaluación requiere la intervención de profesionales de gran experiencia.
El IEEE clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones
de MCV
METODOS FORMALES
La denominación métodos formales se usa para referirse a cualquier actividad relacionada
con representaciones matemáticas del software, incluyendo la especificación formal de
sistemas, análisis y demostración de la especificación, el desarrollo transformacional y la
verificación de programas. Todas estas actividades dependen de una especificación formal
del software.
Una especificación formal del software es una especificación expresada en un
lenguaje cuyo vocabulario, sintaxis y semántica están formalmente definidos. Esta
necesidad de unadefinición formal significa que los lenguajes de especificación deben
basarse en conceptos matemáticos cuyas propiedades se comprendan bien. La rama de las
matemáticas usada es lade matemática discreta, y los conceptos matemáticos provienen
de la teoría de conjuntos, lalógica y el álgebra.
En la década de los 80, muchos investigadores de ingeniería del software propusieron que
el uso de métodos formales de desarrollo era la mejor forma de mejorar la calidad del
software. Argumentaban que el rigor y el análisis detallado, que son una parte esencial de
los métodos formales, podrían dar lugar a programas con menos errores y más adecuados
a las necesidades de los usuarios. Predijeron que, en el siglo XXI, una gran proporción del
software estaría desarrollado usando métodos formales.
Claramente, esta predicción no se ha hecho realidad. Existen cuatro razones principales
para esto:
1. Una ingeniería del software exitosa. El uso de otros métodos de ingeniería del software
como los métodos estructurados, gestión de configuraciones y ocultación de la
información en el diseño del software y procesos de desarrollo ha conducido a mejoras en

3. la calidad del software. La gente que sugirió que la única forma de mejorar la calidad del
software era usando métodos formales estaba claramente equivocada.
2. Cambios en el mercado. En la década de los 80, la calidad del software fue vista como un
problema clave de la ingeniería del software. Sin embargo, desde entonces, la cuestión
crítica para muchas clases de desarrollo del software no es la calidad, sino la oportunidad
de mercado. El software debe desarrollarse rápidamente, y los clientes están dispuestos a
aceptar software con algunos defectos si se les entrega rápidamente. Las técnicas para el
desarrollo rápido del software no funcionan de forma efectiva con las especificaciones
formales. Por supuesto, la calidad todavía es un factor importante, pero debe lograrse en el
contexto de entrega rápida.
3. Ámbito limitado de los métodos formales. Los métodos formales no son muy apropiados
para la especificación de interfaces de usuario e interacciones del usuario. El componente
de interfaz de usuario se ha convertido en una parte cada vez mayor de la mayoría de los
sistemas, de manera que realmente s6lo pueden usarse métodos formales cuando se
desarrollan las otras partes del sistema.
4. Escalabilidad limitada de los métodos formales. Los métodos formales todavía no son
muy escalables. La mayoría de los proyectos con éxito que han usado estas técnicas han
estado relacionados con núcleos de sistemas críticos relativamente pequeños. A medida
que los sistemas incrementan su tamaño, el tiempo y esfuerzo requerido para desarrollar
una especificación formal crece de forma desproporcionada.
Ventajas
Se comprende mejor el sistema.
La comunicación con el cliente mejora ya que se dispone de una descripción clara y no
ambigua de los requisitos del usuario.
El sistema se describe de manera más precisa.
El sistema se asegura matemáticamente que es correcto según las especificaciones.
Mayor calidad software respecto al cumplimiento de las especificaciones.
Mayor productividad
Desventajas

4. El desarrollo de herramientas que apoyen la aplicación de métodos formales es
complicado y los programas resultantes son incómodos para los usuarios.
Los investigadores por lo general no conocen la realidad industrial.
Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se
muestra demasiado dogmático.
Se considera que la aplicación de métodos formales encarece los productos y ralentiza su
desarrollo.
El uso de métodos formales está creciendo en el área del desarrollo de sistemas críticos, en
donde las propiedades emergentes del sistema tales como seguridad, fiabilidad y
protección son muy importantes. El alto coste de los fallos de funcionamiento en estos
sistemas implica que las compañías están dispuestas a aceptar los costes elevados iniciales
de los métodos formales para asegurar que su software es tan confiable como sea posible.
Los sistemas críticos en los que los métodos formales se han aplicado con éxito incluyen
un sistema de información de control de tráfico aéreo, sistemas de señalización de redes
ferroviarias, sistemas de naves espaciales y sistemas de control médico.
Clasificación
La clasificación más común se realiza en base al modelo matemático subyacente en cada
método, de esta manera podrían clasificarse en:
Especificaciones basadas en lógica de primer orden y teoría de conjuntos: permiten
especificar el sistema mediante un concepto formal de estados y operaciones sobre
estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se
expresan en lógica de primer orden. La semántica de los lenguajes está basada en la teoría
de conjuntos. Los métodos de este tipo más conocidos son: Z, VDM y B.
Especificaciones algebraicas: proponen una descripción de estructuras de datos
estableciendo tipos y operaciones sobre esos tipos. Para cada tipo se define un conjunto de
valores y operaciones sobre dichos valores. Las operaciones de un tipo se definen a través
de un conjunto de axiomas o ecuaciones que especifican las restricciones que deben
satisfacer las operaciones. Métodos más conocidos: Larch, OBJ, TADs.
Especificación de comportamiento:
Métodos basados en álgebra de procesos: modelan la interacción entre procesos
concurrentes. Esto ha potenciado su difusión en la especificación de sistemas de
comunicación (protocolos y servicios de telecomunicaciones) y de sistemas distribuidos y
concurrentes. Los más conocidos son: CCS,CSP y LOTOS.
Métodos basados en Redes de Petri: una red de petri es un formalismo basado en
autómatas, es decir, un modelo formal basado en flujos de información. Permiten expresar
eventos concurrentes. Los formalismos basados en redes de petri establecen la noción de
estado de un sistema mediante lugares que pueden contener marcas. Un conjunto de

5. transiciones (con pre y post condiciones) describe la evolución del sistema entendida
como la producción y consumo de marcas en varios puntos de la red.
Métodos basados en lógica temporal: se usan para especificar sistemas concurrentes y
reactivos. Los sistemas reactivos son aquellos que mantienen una continua interacción con
su entorno respondiendo a los estímulos externos y produciendo salidas en respuestas a
los mismos, por lo tanto el orden de los eventos en el sistema no es predecible y su
ejecución no tiene por qué terminar.
Modelo prototipado
Chefloy
Vamos creando muestra para lo
que vamos haciendo y luego
documentando.
Para mi este modelo es uno de los modelos mas amigables debido a que hay
másinteracción con el cliente, logrando satisfacer al CLIENTE con el producto final el cual
lo aprueba ahora que el problema es que tu puedes crear muchos prototipos hasta que
alguno logre convencer al usuario hay que tener mucho cuidado y sobretodo tino.
el modelo también te puede servir para crear un prototipo en un campo, en fin lo mejor del
modelo en mi concepto es la facilidad para realizar pruebas y la codificación corregir
errores.
En todo caso el modelo es bueno con un equipo de trabajo pequeño y utilizando las
herramientas adecuadas y no tomar el prototipo como el producto final.
PROTOTIPO DESECHABLE.
para mi funciona siempre y cuando se evalue los requerimientos, interfaz, etc.... ya que esa
es su funcion
PROTOTIPO EVOLUTIVO:
En este modelo se necesita un poco mas de
cuidado porque este va a ser la base del

6. software a desarrolla junto con un documento para respaldar el prototipo.
Etapas
Plan rápido
Modelado, diseño rápido
Construcción del Prototipo
Desarrollo, entrega y retroalimentación
ComunicaciónYurley
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.
La construcción de prototipos se puede utilizar como un modelo del proceso
independiente, se emplea más comúnmente como una técnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos.
Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos
ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el
resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este
ciclo de vida en particular, involucra al cliente más profundamente para adquirir el
producto.
Inconvenientes
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. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo
se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero
partiendo de un estado poco recomendado.
En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas
decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de
programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del
tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones,
con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema
final...

7. Modelo Incremental
El Modelo Incremental combina elementos del MLS con la filosofía interactiva de
construcción de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba.
Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o
“Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al
cliente en constante contacto con los resultados obtenidos en cada incremento.
Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de
que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se
elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza
interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un
producto completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de
personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de
personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los
incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma grafica:

8. - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar
como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de
datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada
una la salida de la anterior.
Esta arquitectura es muy común en el desarrollo de programas para el intérprete de
comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).
También es una arquitectura muy natural en el paradigma de programación funcional, ya
que equivale a la composición de funciones matemáticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecución de mandatos
obtenidos del usuario por medio de una interfaz alfanumérica.
Características
- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta
frecuencia.
- El usuario se involucre más.
- Difícil de evaluar el costo total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar
como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se
implementa la funcionalidad parcial.

9. - 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.