PLANTEL 164 PLAN DE AYALA

SEMESTRE 2022-A
MTRO. RAMON DE JESUS
CALDERON HERNANDEZ

SEPTIEMBRE 2022
 ACTIVIDADES

Actividad 1:
 Resuelve la Evaluación diagnostica de la materia.

Actividad 2:
El alumno elaborara una infografía sobre el ciclo de vida del
software.

Actividad 3:
El alumno elabora un cuadro sinóptico sobre
los modelos del ciclo de vida del software.

Actividad 4:
 El alumno deberá realizar un análisis sobre las fases del proceso de
desarrollo del software.

Actividad 5:
El alumno deberá realizar un
mapa conceptual sobre los
Modelos del Proceso de
Desarrollo.
 COLEGIO DE BACHILLERES DE
CHIAPAS O.P.D. PLANTEL 164
PLAN DE AYALA SISTEM AS DE
INFORMACION/PROGRAMACION
MTRO. RAMON DE JESUS CALDERON
HERNANDEZ
EVALUACION DIAGNOSTICA

NOMBRE:

GRADO: GRUPO: FECHA: CALIFICAION:

I.- RESUELVE LAS SIGUIENTES PREGUNTAS.

1.- Que es un sistema de información:

2.- Describe con tus propias palabras que entiendes por metodología:

3.- Anota el significado de necesidad:

4.- Que entiendes por análisis:

5.- Que es para ti un diseño:

6.- Menciona el significado de codificación:

7.- Que significa para ti la palabra prueba:

8.- Describe que es una validación:

9.- Que entiendes por mantenimiento y evaluación:

10.- Sabes que es una base de datos, describe su significado:

11.- Que entiendes por consulta:

12.- Describe que es un formulario:

13.- Menciona que es un algoritmo:

14.- Que es un diagrama de flujo:

15.- Describe con tus propias palabras que entiendes por pseudocodigo:

16.- Anota el significado de ciclo:

17.- Que entiendes por lenguaje de programación:

18.- Que es para ti una variable:

19.- Menciona el significado de operadores:

20.- Que significa para ti la palabra constantes:

21.- Describe que es una estructura:

22.- Que entiendes por Condición y repetición:

 CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
Actividad 2:
 El alumno analiza la información sobre el ciclo de vida del
software para elaborar una infografía.

El ciclo de vida del desarrollo de software

(en inglés: SDLC – Systems Development
Life Cycle) es la estructura que contiene los
procesos, actividades y tareas relacionadas
con el desarrollo y mantenimiento de un
producto de software, abarcando la vida
completa del sistema, desde la definición de
los requisitos hasta la finalización de su uso.

Se trata de evitar los costes de rectificar

errores de implementación mediante un
método que permita a los programadores
adelantarse para mejorar sus resultados
finales.

Este sistema de desarrollo (o ciclo de vida

del proceso de software), necesita de varios pasos imprescindibles para garantizar que
los programas ofrezcan una buena experiencia al usuario, seguridad, eficiencia,
estabilidad y fiabilidad de uso.

LAS FASES DE SDLC

El SDLC es parte del ADN computacional de Ungoti y por este motivo apoyamos el ciclo
de vida completo del proyecto a través de las siguientes fases:

Comunicación
Este es el momento en el que un cliente solicita un
producto de software determinado. Nos contacta
para plasmar sus necesidades concretas y
presenta su solicitud de desarrollo de software.
 Planificación y análisis
El desarrollo de software comienza con una fase
inicial de planificación incluyendo un análisis de
requisitos. Nos fijamos en los requisitos que piden
los clientes para estudiar cuales están poco claros,
incompletos, ambiguos o contradictorios. Se
indaga en profundidad y se hacen demostraciones
prácticas incluyendo a los usuarios clave. Los
requisitos se agrupan en requisitos del usuario,
requisitos funcionales y requisitos del sistema. La
recolección de todos los requisitos se lleva a cabo:
estudiando el software actual que tengan,
entrevistando a usuarios y desarrolladores, consultando bases de datos o mediante
cuestionarios.

En la siguiente fase se fija el alcance del proyecto y se plasma por escrito en un

documento.

Estudio de viabilidad

Después de la recolección de requisitos, se idea

un plan para procesar el software. Se analiza
que parte del software cubre los requisitos de
cada usuario. Se investiga la viabilidad
financiera y tecnológica. Se utilizan algoritmos
para saber si el proyecto de software es factible
o no.
 Análisis del sistema

En este paso el equipo del proyecto asigna recursos

y planifica el tiempo de duración del proyecto. Se
buscan limitaciones del producto y se identifican los
impactos del proyecto sobre toda la organización en
su conjunto.

Diseño

En esta fase ya se comienza a

visualizar la solución con la
ayuda de las anteriores fases.
Se hace un diseño lógico y otro
físico. Se crean metadatos,
diagramas o pseudocódigos.
La duración de esta fase varía
de un proyecto a otro.

Codificación

Esta fase también denominada ‘fase de

programación’ o ‘fase de desarrollo’ es en la que
elige el lenguaje de programación más
conveniente, y se desarrollan programas
ejecutables y sin errores de manera eficiente.
Nuestro enfoque es construir trozos de
funcionalidad. Por lo tanto, entregar unidades de
funcionalidad concisa. Al final de esta fase se
puede obtener un PMV (Producto mínimo viable) o
el software completamente desarrollado y listo
para implementarse.
Integración

El Software puede necesitar estar integrado con

bibliotecas, bases de datos o con otros programas.
Esta fase del SDLC integra el software con las
entidades del mundo exterior.

Pruebas

Esta fase junto con la fase de desarrollo entra en

un ciclo continuo hasta que se completan el
desarrollo y las pruebas. Probamos, probamos y
luego volvemos a probar tanto como sea necesario
hasta que la funcionalidad sea del 100%.

Además se hacen evaluaciones para evitar

errores, incluyendo la evaluación de módulos,
programas, productos, y finalmente evaluación con
el cliente final. Encontrar errores y su arreglarlos a
tiempo es la clave para conseguir un software
confiable y eficiente.
 Implementación

Aquí se instala el software, se evalúa la

integración, la adaptabilidad, la portabilidad y se
instalan las configuraciones posteriores
necesarias.

Formación

Esta es la fase más interesante, ¡La formación!

La adopción del usuario es muy importante y
para ello ofrecemos capacitación inicial para
cada usuario. Es importante comprobar el nivel
de uso, la experiencia de usuario y resolver
cualquier dificultad que pueda surgir a la hora de
enfrentarse a un nuevo sistema o plataforma.

Mantenimiento y Funcionamiento

Por último, pero no menos importante el mantenimiento es

uno de los elementos clave de éxito de cualquier proyecto.
En esta fase se minimizan pequeños errores, se confirma
el buen funcionamiento del software, su eficiencia y
estabilidad. El proyecto ya está completado y necesitamos
monitorear y mantener de forma continua para garantizar
que el proyecto siga ejecutándose bien.

Si es necesario se dan
nuevas formaciones, o se
presta documentación
sobre como operar y mantener el software en
perfecto estado de funcionamiento. Se adaptan
entornos del usuario o tecnológicos, dando
mantenimiento al software, actualizando el
código y configuración.
El software es efectivo cuando se usa de
forma apropiada y por eso el mantenimiento y la
mejora de los productos de software es
crucial para poder corregir defectos que vayan
surgiendo o para poder atender a los requisitos del software.
 MODELOS DE CICLOS DE VIDA DEL SOFTWARE

Actividad 3:
 El alumno analiza la información sobre los modelos del ciclo de
vida del software y elabora un cuadro sinóptico del tema.

La ingeniería del software se vale de una serie de modelos que establecen y muestran
las distintas etapas y estados por los que pasa un producto software, desde su
concepción inicial, pasando por su desarrollo, puesta en marcha y posterior
mantenimiento, hasta la retirada del producto. A estos modelos se les denomina
“Modelos de ciclo de vida del software”. El primer modelo concebido fue el de Royce,
más comúnmente conocido como “Cascada” o “Lineal Secuencial”. Este modelo
establece que las diversas actividades que se van realizando al desarrollar un producto
software, se suceden de forma lineal.

Los modelos de ciclo de vida del software describen las fases del ciclo de software y el
orden en que se ejecutan las fases.
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren
durante el desarrollo de software, intenta determinar el orden de las etapas involucradas
y los criterios de transición asociados entre estas etapas. Un modelo de ciclo de vida del
software:

• Describe las fases principales de desarrollo de software.

• Define las fases primarias esperadas de ser ejecutadas durante esas fases.
• Ayuda a administrar el progreso del desarrollo.
• Provee un espacio de trabajo para la definición de un proceso detallado de desarrollo
de software.

Las principales diferencias entre distintos modelos de ciclo de vida están en:

• El alcance del ciclo dependiendo de hasta dónde llegue el proyecto

correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del
desarrollo de un producto, o su desarrollo completo o en el extremo, toda la historia del
producto con su desarrollo, fabricación y modificaciones posteriores hasta su retirada del
mercado.

• Las características (contenidos) de las fases en que dividen el ciclo. Esto puede
depender del propio tema al que se refiere el proyecto, o de la organización.

• La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si

tenemos libertad de repetirlas (iterar).

MODELO EN CASCADA.
Es un enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del
software, de forma que el inicio de cada etapa debe esperar a la finalización de la
inmediatamente anterior. El modelo en cascada es un proceso de desarrollo secuencial,
en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases
que componen el ciclo de vida.

La primera descripción formal del modelo en cascada se cree que fue en un artículo
publicado en 1970 por Winston W. Royce, aunque Royce no usó el término cascada en
este artículo. Irónicamente, Royce estaba presentando este modelo como un ejemplo de
modelo que no funcionaba, defectuoso. En el modelo original de Royce, existían las
siguientes fases:
1.Especificación de requisitos.
2.Diseño.
3.Construcción (Implementación o codificación).
4.Integración.
5.Pruebas.
6.Instalación.
7.Mantenimiento.

Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma
puramente secuencial.
Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue
siendo el paradigma más seguido a día de hoy.

MODELO V.

El modelo en v se desarrolló para terminar con algunos de los problemas que se vieron
utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados
demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final
del proyecto. El modelo en v dice que las pruebas necesitan empezarse lo más pronto
posible en el ciclo de vida. También muestra que las pruebas no son sólo una actividad
basada en la ejecución. Hay una variedad de actividades que se han de realizar antes
del fin de la fase de codificación. Estas actividades deberían ser llevadas a cabo en
paralelo con las actividades de desarrollo, y los técnicos de pruebas necesitan trabajar
con los desarrolladores y analistas de negocio de tal forma que puedan realizar estas
actividades y tareas y producir una serie de entregables de pruebas.

El modelo en v es un proceso que

representa la secuencia de pasos en el
desarrollo del ciclo de vida de un proyecto.
Describe las actividades y resultados que
han de ser producidos durante el
desarrollo del producto. La parte izquierda
de la v representa la descomposición de
los requisitos y la creación de las
especificaciones del sistema. El lado
derecho de la v representa la integración
de partes y su verificación. V significa
“Validación y Verificación”.

Realmente las etapas individuales del proceso pueden ser casi las mismas que las del
modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de
una forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificación,
formando una v. La razón de esto es que para cada una de las fases de diseño se ha
encontrado que hay un homólogo en las fases de pruebas que se correlacionan.

MODELO ITERATIVO.
Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo
que surge entre las necesidades del usuario y el producto final por malos entendidos
durante la etapa de recogida de requisitos.

Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se

le entrega al cliente una versión mejorada o con mayores funcionalidades del producto.
El cliente es quien, después de cada iteración, evalúa el producto y lo corrige o propone
mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las
necesidades del cliente.

Este modelo se suele utilizar en proyectos en los que los requisitos no están claros por
parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para
presentarlos y conseguir la conformidad del cliente.

MODELO DE DESARROLLO INCREMENTAL.

El modelo incremental combina elementos del modelo en cascada con la filosofía

interactiva de construcción de prototipos. Se basa en la filosofía de construir
incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales
de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal
produce un incremento del software.
Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto
esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un
producto operativo con cada incremento. Los primeros incrementos son versiones
incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa
y también una plataforma para la evaluación.

MODELO EN ESPIRAL
El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en
1985, utilizado de forma generalizada en la ingeniería del software. Las actividades de
este modelo se conforman en una espiral, cada bucle representa un conjunto de
actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en
función del análisis de riesgos, comenzando por el bucle anterior.

Al ser un modelo de ciclo de vida orientado a la gestión de riesgos se dice que uno de
los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la
necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos.

Tareas: Para cada ciclo habrá cuatro actividades:

1. Determinar o fijar objetivos:
• Fijar también los productos definidos a obtener: requerimientos, especificación, manual
de usuario.
• Fijar las restricciones.
• Identificar riesgos del proyecto y estrategias alternativas para evitarlos.
• Hay una cosa que solo se hace una vez: planificación inicial o previa

2. Análisis del riesgo:

• Estudiar todos los riesgos potenciales y se seleccionan una o varias alternativas
propuestas para reducir o eliminar los riesgos

3. Desarrollar, verificar y validar (probar):

• Tareas de la actividad propia y de prueba.
• Análisis de alternativas e identificación de resolución de riesgos.
• Dependiendo del resultado de la evaluación de riesgos, se elige un modelo para el
desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo,
cascada, etc. Así, por ejemplo, si los riesgos de la interfaz de usuario son dominantes,
un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos.

4. Planificar:
• Revisar todo lo que se ha llevado a cabo, evaluándolo y decidiendo si se continúa con
las fases siguientes y planificando la próxima actividad.

El proceso empieza en la posición central. Desde allí se mueve en el sentido de las agujas
del reloj.
MODELO DE PROTOTIPOS.

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El

desarrollador y el cliente encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más
definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una
representación de esos aspectos del software que serán visibles para el usuario/cliente.
El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el
cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La
iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del
cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se
necesita hacer.
 FASES DEL PROCESO DE DESARROLLO DE SOFTWARE

Actividad 4:
 El alumno deberá realizar un análisis sobre las fases del proceso de desarrollo del
software.

1.- Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo.
Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se
requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos
incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el
cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema,
cuya estructura puede venir definida por varios estándares, tales como CMM-I.
Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las
principales entidades que participarán en el desarrollo del software. La captura, análisis
y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta
etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos
y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se
habla de la Ingeniería de Requisitos. La IEEE Std. 830-1998 normaliza la creación de las
Especificaciones de Requisitos Software (Software Requirements Specification).
2.- Diseño y arquitectura
Se refiere a determinar cómo funcionará de forma general sin entrar en detalles. Consiste
en incorporar consideraciones de la implementación tecnológica, como el hardware,
la red, etc. Se definen los casos de uso para cubrir las funciones que realizará el sistema,
y se transforman las entidades definidas en el análisis de requisitos en clases de diseño,
obteniendo un modelo cercano a la programación orientada a objetos.

3.- Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de
software, pero no es necesariamente la porción más larga. La complejidad y la duración
de esta etapa está íntimamente ligada al o a los lenguajes de programación utilizados.

4.- Pruebas
Consiste en comprobar que el software realice correctamente las tareas indicadas en la
especificación. Una técnica de prueba es probar por separado cada módulo del software,
y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena
práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la
programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador
debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un
área de pruebas, la primera es que esté compuesta por personal inexperto y que
desconozca el tema de pruebas, de esta forma se evalúa que la documentación]
entregada sea de calidad, que los procesos descritos son tan claros que cualquiera
puede entenderlos y el software hace las cosas tal y como están descritas. El segundo
enfoque es tener un área de pruebas conformada por programadores con experiencia,
personas que saben sin mayores indicaciones en que condiciones puede fallar una
aplicación y que pueden poner atención en detalles que personal inexperto no
consideraría.

5.- Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión
del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de
usuario, manuales técnicos, etc; todo con el propósito de eventuales
correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

6.-Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos.
Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de
2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña
parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en
extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de
toda la Ingeniería civil, Arquitectura y trabajo de construcción es dar mantenimiento.
Se puede decir que con la mejora continua garantiza la calidad del producto, ya que el
estarla aplicando día con día es la mejor decisión que puede llegar a tener cualquier
empresa, porque de esta manera evita grandes problemas en la elaboración o desarrollo
de los productos. Esto es fundamental para todas las empresas ya que se vuelven
competitivas, con mayor productividad y eficiencia. No hay que olvidar que la mejora se
da porque el cliente es el rey y hay que satisfacer todas y cada una de sus necesidades
siempre garantizando la calidad.
 MODELOS DEL PROCESO DE DESARROLLO SOFTWARE

Actividad 5:
 El alumno deberá leer el tema de los Modelos del Proceso de
Desarrollo Software, y elaborar un mapa conceptual.

No existe consenso sobre cuál es el mejor modelo del proceso software. Distintos
equipos de desarrollo pueden utilizar diferentes modelos de proceso software para
producir el mismo tipo de sistema software. Sin embargo, algunos modelos son más
apropiados para producir ciertos tipos de sistemas, de forma que si no se utiliza un
modelo adecuado puede ocurrir que el sistema software resultante sea de menor calidad.

El reparto de costes entre las distintas fases del proceso de desarrollo es difícil de
determinar dado los distintos modelos de proceso existentes. Sin embargo, en
dependencia del modelo que se adopte, al menos el 60% del coste total se emplea en la
actividad de evolución del sistema. La estimación de este porcentaje es pesimista, ya
que la tasa de crecimiento de nuevos productos software es mucho mayor que la tasa de
productos software que quedan en desuso (no tienen que ser mantenidos), por lo que el
número de operaciones de mantenimiento que se realizan sigue aumentando. El proceso
de diseño software debería, por tanto, tener en cuenta la posterior evolución del sistema.

Las características deseables de un proceso de desarrollo software son:

Claridad: El proceso de desarrollo es claro cuando se entiende con facilidad.

Visibilidad: Un proceso de desarrollo es visible cuando sus actividades producen

resultados claros identificables externamente.

Facilidad de soporte: Exige disponer de herramientas CASE (Computer-Aided Software

Engineering) que den soporte a todas o alguna de las actividades del proceso de
desarrollo.

Fiabilidad: Un proceso de desarrollo es fiable cuando es capaz de detectar posibles

errores.

Facilidad de mantenimiento: Requiere capacidad para incorporar nuevos requisitos o

modificar alguno o algunos de los existentes.

Rapidez: Un proceso software es rápido cuando se puede obtener, a partir de la

especificación, una implementación del sistema en un tiempo reducido.
1.- Modelo en cascada o convencional
Tomado de otras ingenierías es el primer modelo de desarrollo software propuesto.
Ampliamente usado en la industria por su facilidad de gestión y visibilidad. En la figura 1
se representa el secuenciamiento de las actividades de este modelo de desarrollo.

Figura 1: Modelo en cascada o convencional.

Sin embargo, su principal problema reside en su poca flexibilidad al separar el proceso

de desarrollo en etapas totalmente distintas. En la práctica estas etapas no tienen
fronteras tan bien definidas, lo que hace que, en no pocas ocasiones, se solapen y
compartan información.
Los principales problemas de este modelo son: dificultad para realizar prototipos,
reutilizar software y realizar pruebas sin disponer de una implementación del sistema.

2.- Modelo evolutivo

En este modelo se entrelazan las actividades de especificación, desarrollo y validación.
Inicialmente, se desarrolla rápidamente un sistema inicial a partir de una especificación
muy abstracta. El sistema se va refinando con la información que van suministrando los
clientes y/o usuarios hasta que se obtiene un sistema final que satisfaga todas las
necesidades previstas. El sistema final obtenido puede rediseñarse para producir otro
más robusto y más fácil de mantener. En la figura 2 se esquematiza este modelo.
 Figura 2: Modelo evolutivo.

Existen dos tipos de procesos de desarrollo evolutivos:

Exploratorio: Su objetivo es trabajar con el cliente para identificar y construir el sistema

final a partir de una especificación informal. El resultado del proceso es el sistema final.

Prototipado desechable: Su objetivo es entender los requisitos del cliente. El resultado

del proceso es la especificación del sistema (el prototipo se deshecha).

Los principales problemas de este modelo son: escasa visibilidad; los continuos cambios
que hacen que los sistemas desarrollados estén deficientemente estructurados; y la
necesidad de disponer, en muchos casos, de un equipo de desarrollo altamente
calificado. Estos problemas hacen que la aplicación de este modelo se suela limitar a
sistemas interactivos de tamaño pequeño o mediano.

La deficiente estructura dificulta las tareas de mantenimiento de ahí que se suela aplicar
a sistemas con una vida corta y a partes de grandes sistemas, especialmente a sistemas
de inteligencia artificial y a interfaces de usuario.
3.- Modelo transformacional
Se basa en disponer de una especificación formal del sistema y en transformar, con
métodos matemáticos, esta especificación en una implementación. Si las
transformaciones que se aplican son correctas es posible asegurar que el sistema
construido satisface la especificación, es decir, es posible obtener programas correctos
por construcción.

Figura 3: Modelo transformacional.

Otra de sus ventajas es la posibilidad de realizar el mantenimiento a nivel de

especificación. Por lo que es necesario disponer de una especificación inicial correcta y
de diseñadores altamente calificados. Además no existe apenas experiencia en la
aplicación de este modelo a grandes proyectos.

Modelo basado en reutilización: En este modelo se supone que alguno de los

componentes del sistema final ya existe. El proceso de desarrollo se centra en integrar
las partes ya existentes más que en construir todo el sistema desde el principio.
Las ventajas que desde un punto de vista económico puede producir este modelo
actualmente empiezan a ser estudiadas en profundidad. Prácticamente no existe
experiencia sobre el empleo de este modelo, si bien, se están haciendo numerosos
estudios e investigaciones para posibilitar su uso.
4.- Modelo en espiral
Desarrollado por Boehm en el año 1988 con el objetivo de reunir las ventajas de los
modelos de proceso software en cascada y de prototipado. Se incluye el análisis de
riesgo como una parte importante del proceso de desarrollo software.

El modelo tiene la forma de una espiral en la que cada vuelta representa cada una de las
fases en las que se estructura el proceso software y está organizada en cuatro sectores:

1. Definición de objetivos, alternativas y restricciones de cada fase del proyecto.

2. Evaluación de alternativas y análisis de riesgos.

3. Desarrollo y validación. Se elige el modelo de proceso de desarrollo que se considere

más adecuado.

4. Planificación de las siguientes fases del proyecto.