Este documento describe varios modelos de procesos de desarrollo de software, incluyendo el modelo en cascada, el modelo V, los modelos basados en prototipos y los métodos formales. El modelo en cascada sigue un enfoque secuencial de análisis, diseño, codificación, prueba y mantenimiento. El modelo V es una evolución del modelo en cascada que agrega pruebas después de cada etapa. Los modelos basados en prototipos involucran la creación y evaluación de prototipos tempranos. Finalmente, los métodos formales util

1. MODELOS DE PROCESOS
Modelo primitivo
Los modelos de datos primitivos estaban absolutamente orientados al fichero:
las entidades se representan en registros (divididos en campos, que
representan sus propiedades), que se agrupan en ficheros. Las relaciones
entre entidades son únicamente aquellas que pueden ser representadas
usando directorios, por ejemplo índices y listas invertidas. Un ejemplo de
DBMS comercial de fichero, concretamente del tipo "lista invertida", es el CA-
DATACOMB de Computer Associates International.
Modelo en Cascada1(Bennington 1956):
El más conocido, está basado en el ciclo convencional de una ingeniería,
el paradigma del ciclo de vida abarca las siguientes actividades:
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.
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.
1 Ingeniería del Software: Un enfoque practico, Roger S. Presuman, 3ra Edición, Pag. 26-30.
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento

2. 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 traduce
los requisitos en una representación del software con la calidad requerida antes
de que comience la codificación.
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 una manera
detallada la codificación puede realizarse mecánicamente.
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.
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.
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.
La ventaja de este método radica en su sencillez ya que sigue los pasos
intuitivos necesarios a la hora de desarrollar el software.

3. Modelo V (Ministerio de Defensa de Alemania, 1992):
El Modelo V tiende a ser muy relacionado con el Modelo de Cascada
puesto que es una evolución del mismo.
Puede notarse que su primera mitad es similar al Modelo en Cascada, y
la otra mitad tiene como finalidad hacer pruebas e integración asociado a cada
una de las etapas de la mitad anterior.
Se puede identificar una ventaja principal con respecto al Modelo
Cascada más simple, y se refiere a que este modelo involucra chequeos de
cada una de las etapas del modelo de cascada.
Desventajas:
ANALISIS DE
REQUERIMIENTOS
DISEÑO DEL
SISTEMA
DISEÑO
DETALLADO
IMPLEMENTACION
DE PROGRAMAS Y
PRUEBA DEL
SISTEMA
PRUEBA DE
ACEPTACION
OPERACION
Y MANTENIMIENTO
PRUEBA DE
INTEGRACION
Plan de
Pruebas
de Integración
Verificar diseño
Plan de
Pruebas
del Sistema
Validar requerimientos
Plan de
Pruebas
de Aceptación
Los planes de prueba son
el nexo entre el desarrollo
y la verificación

4.  El riesgo es mayor que el de otros modelos, pues en lugar de hacer
pruebas de aceptación al final de cada etapa, las pruebas comienzan a
efectuarse luego de haber terminado la implementación, lo que puede
traer como consecuencia un “roll-back” de todo un proceso que costó
tiempo y dinero.
 El modelo no contempla la posibilidad de retornar a etapas
inmediatamente anteriores, cosa que en la realidad puede ocurrir.
 Se toma toda la complejidad del problema de una vez y no en
iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.
A pesar de todo lo antes mencionado, definitivamente se trata de un
modelo más robusto y completo que el Modelo de Cascada, y puede producir
software de mayor calidad que con el modelo de cascada.
MODELOS BASADOS EN PROTOTIPOS
Este modelo consiste en un procedimiento que permite al equipo de desarrollo
diseñar y analizar una aplicación que representa el sistema que sería
implementado (McCracken y Jackson, 1982). Dicha aplicación, llamada
prototipo, está compuesta por los componentes que se desean evaluar
(i.e. las funciones principales). Las etapas del modelo son:
- Investigación preliminar.
- Colecta y refinamiento de los requerimientos y proyecto rápido:
- Análisis y especificación del prototipo.
- Diseño y construcción del prototipo.
- Evaluación del prototipo por el cliente.
- Renacimiento del prototipo.

5. - Diseño técnico.
- Programación y test.
- - Operación y mantenimiento.
http://rguerrero334.blogspot.es/1192897080/
Métodos formales
Un método formal es un camino a la construcción y análisis de modelos
matemáticos que permitan una automatización del desarrollo de sistemas
informáticos; se caracterizan por emplear técnicas y herramientas matemáticas
para lograr una facilitación a la hora de encarar la construcción o el análisis de
un modelo matemático de un sistema. Los métodos formales se refieren
entonces al uso de técnicas de la lógica y de la matemática discreta para
especificar, diseñar, verificar, desarrollar y validar programas. La palabra
“formal” se deriva de la lógica formal, ciencia que estudia el razonamiento
desde el análisis formal de acuerdo con su validez o no validez, y omite el
contenido empírico del razonamiento para considerar sólo la forma
estructurada sin materia. Los métodos formales más rigurosos aplican estas
técnicas para comprobar los argumentos utilizados para justificar los requisitos,

6. u otros aspectos de diseño e implementación de un sistema complejo.
En la lógica formal como en los métodos formales el objetivo es el mismo,
“reducir la dependencia de la institución y el juicio humanos para evaluar
argumentos” (Kiniry & Zimmerman, 2008). Los métodos menos rigurosos
enfatizan en la formalización y renuncian a la computación, definición que
implica un amplio espectro de técnicas, y una gama igualmente amplias de
estrategias. La interacción de las técnicas y estrategias de muchos métodos
formales, en determinados proyectos, se limita por el papel que interpretan y
por los recursos disponibles para su aplicación (García et al., 2006).
Se puede decir también que un método formal es una técnica basada en
matemáticas, usada para describir sistemas de hardware o software, Wing,
Jeannette M. (1990). Los métodos formales permiten representar la
especificación del software, verificación y diseño de componentes mediante
notaciones matemáticas. El uso de métodos formales permite plantear de
manera clara la especificación de un sistema, generando modelos que definen
el comportamiento en términos del “qué debe hacer” y no del “cómo lo hace”.
Gracias al correcto proceso de especificación, se pueden verificar propiedades
derivadas de cada módulo mediante técnicas de razonamiento asociadas a los
modelos formales, como probadores de teoremas y verificadores de modelos
Hall (1996). Para los procesos de especificación se reconoce las siguientes
clasificaciones:
1. Especificaciones basadas en lógicas de primer orden y teoría de
conjunto: 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: VDM, Z, B, OCL.
Niveles de los métodos formales
• Especificación formal: Es una descripción de un sistema que utiliza
notaciones matemáticas para describir precisamente las propiedades que dicho
sistema debe tener, sin preocuparse por la forma de obtener estas
propiedades: “describe lo que el sistema debe hacer sin decir como se va
hacer”.
Algunas de las ventajas que podemos nombrar sobre una especificación formal
son las siguientes:
• Prototipado: Las especificaciones formales pueden llegar a ser ejecutables.
• Corrección del programa: Verificación automática y formal de que el
programa funciona correctamente.
• Reusabilidad: Posibilidad de usar la especificación formal en distintos
ámbitos.
En cuanto a la notación, una descripción formal constará de cuatro (04) partes:
• NOMBRE: Nombre genérico del TAD.

7. • CONJUNTOS: Conjuntos de datos que intervienen en la definición.
• SINTAXIS: Signatura de las operaciones definidas ->
<nombre operación>: <conj_dominio> → <conj_resultado>
• SEMÁNTICA: Indica el significado de las operaciones.
Las distintas notaciones formales existentes difieren en la forma de definir la
semántica:
• Método axiomático o algebraico. Se establece el significado de las
operaciones a través de relaciones entre operaciones (axiomas). Significado
implícito de las operaciones.
Los métodos axiomáticos o algebraicos, poseen la semántica de las
operaciones, como dijimos anteriormente se define a través de un conjunto de
axiomas.
Un axioma es una regla que establece la igualdad de dos expresiones:
<Expresión 1> = <Expresión 2>
Por ejemplo: Suma (dos, dos) = Producto (dos, dos)
Supongamos un TAD, T. Los tipos de operaciones son:
• Constructores: Conjunto mínimo de operaciones del TAD, a partir del cual
se puede obtener cualquier valor del tipo T.
• Modificación: A partir de un valor del tipo obtienen otro valor del tipo T, y no
son constructores.
• Consulta: Devuelven un valor que no es del tipo T.
Además, una especificación es:
• Completa: Si de cualquier expresión se puede encontrar otra más sencilla,
con operaciones de construcción.
• Correcta: Si a partir de una expresión sólo se puede obtener un resultado
final.
Para conseguir que una especificación sea completa y correcta, hay que definir
los axiomas suficientes para relacionar las operaciones de modificación y
consulta con los constructores. Y no incluyendo axiomas que se puedan
deducir de los otros ya descritos.
• Método constructivo u operacional. Se define cada operación por sí misma,
independientemente de las otras. Significado explícito de las operaciones. En la
semántica de este método se establecen las precondiciones y las
poscondiciones de las operaciones:
• Precondición: Relación que se debe cumplir con los datos de entrada para
que la operación se pueda aplicar.
• Poscondición: Relaciones que se cumplen después de ejecutar la operación.
No debe incluir detalles de implementación.
En cuanto a la notación, para cada operación <nombre>:
pre-<nombre> (<param_entrada>)::= <condición_lógica>
post-<nombre> (<param_entrada>;<param_salida>)::= <condición_lógica>
Algunas veces es necesario tener modelos subyacentes para especificar otros
complejos. Por ejemplo: para especificar Pila[T] o Cola[T] el tipo subyacente

8. puede ser Lista[T]. Esta especificación está limitada por la necesidad de estos
modelos.
Ejemplo:
Máximo restringido, que sólo se aplica a enteros positivos: max_restring: Z x Z
→ Z
pre-max_restring (x, y) ::= (x > 0) ^ (y > 0)
post-max_restring (x, y; r) ::= (r ≥ x) ^ (r ≥ y) ^ (r=x V r=y)
Desventajas de los métodos formales
• 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.
No obstante es posible que el enfoque a través de métodos formales tenga
más partidarios entre los desarrolladores del software que deben construir
software de mucha seguridad (por ejemplo: los desarrolladores de aviónica
y dispositivos médicos), y entre los desarrolladores que pasan grandes
penurias económicas al aparecer errores de software.
Métodos formales en ingeniería del software
Los métodos formales en ingeniería de software tienen como objetivo aumentar
la rigurosidad, consistencia y completitud en el desarrollo del software y evitar
los problemas que son origen de errores en el software.
Una de las técnicas utilizadas para garantizar la calidad en un proyecto
software es la verificación formal, que engloba una serie de técnicas
matemáticas para demostrar que el software que se está desarrollando se
ajuste a las especificaciones.
El papel de los métodos formales en la ingeniería del software:
• Se basan en el empleo de técnicas, lenguajes y herramientas definidos
matemáticamente.
• Facilitan el análisis y construcción de sistemas confiables
independientemente de su complejidad.
• Delatan posibles inconsistencias o ambigüedades que de otra manera
pudieran pasar desapercibidas.
• Facilita el desarrollo de especificaciones claras, concisas y no ambiguas.
• Permite el análisis funcional de la especificación.
• Posibilita el desarrollo de implementaciones correctas respecto a sus
especificaciones.
Modelo de Transformación Formal

9. Este modelo, propuesto por Robert Balzer en 1983, aplica una serie de
transformaciones usando un soporte automatizado para convertir una
especificación formal (modelo matemático) en un sistema implementable
(ejecutable). Es decir, este paradigma intenta automatizar las etapas de diseño
e implementación utilizando el concepto de transformación. También se
denomina a este paradigma Síntesis Automática de Software.
Fases:
 Análisis de requisitos
 Especificación formal
 Transformación
 Integración del sistema final
La especificación formal se convierte en forma sistemática en una
representación más detallada del sistema, matemáticamente correcta. Cada
paso agrega detalle hasta que la especificación formal se convierte en un
programa equivalente. Como hay muchos caminos a seguir desde la
especificación hasta el sistema final, la secuencia de transformaciones y su
justificación se reflejan en un registro formal de desarrollo. Se utilizan técnicas
de validación del modelo matemático, como la Simulación.
La especificación de requisitos se refina en una especificación formal detallada,
expresada en notación matemática. Los procesos de diseño, implementación y
prueba de unidades se reemplaza por un proceso de transformaciones donde
la especificación formal se refina hasta llegar a un Software.
Proceso de Transformación formal de Robert Balzer - "Software technology in
the 1990s: using a new paradigm".
http://innovacionpnfi2012.wordpress.com/metodos-formales-2/

10. MODELO EVOLUTIVO
Este modelo, también conocido como Evolutivo, es una derivación del ciclo
de vida en cascada puro, que busca reducir el riesgo que surge entre las
necesidades delUsuario y el Producto final por malos entendidos durante la
etapa de solicitud de requerimientos.
En el ciclo de vida iterativo, en cada Iteración se reproduce el ciclo de vida en
cascada a menor escala. Los objetivos de una Iteración se establecen en
función de la evaluación de las Iteraciones precedentes. Desde el principio, al
final de cada Iteración se le entrega al Cliente una versión completa y mejorada
del Producto. El Cliente es quien luego de cada Iteración evalúa el Producto y
lo corrige o propone mejoras. Estas Iteraciones irán Refinando el sistema y se
repetirán hasta obtener un Producto que satisfaga al Cliente.
La Especificación de requisitos se realiza en forma creciente: a medida que
los Usuarios logran un mejor entendimiento del problema, éste es reflejado en
el sistema software. Es decir, el Producto de cada etapa de Especificación de
requisitos es un agregado o mejora al Producto de la etapa de especificación
anterior.
Este modelo se basa en dos premisas:
1) Los Usuarios a menudo no saben bien lo que quieren o necesitan.
2) Por lo general, los requisitos en algún momento van a cambiar.
Para solucionar el primer punto, los requisitos se determinan en base a alguna
forma operacional del sistema (por ejemplo, un prototipo) para ser revisado por
los Usuarios. Para atender el segundo punto, se realizan entregas parciales del
sistema que permiten incorporar nuevos requisitos o cambios en requisitos
existentes en la siguiente entrega. Es decir, cada versión es una mejora sobre
la predecesora.
Este modelo se utiliza cuando no se puede especificar a priori “todos” los
requisitos del software, sino que el proceso ayudará a ir descubriendo paso a
paso los requisitos a partir de cada nueva Entrega.

11. http://procesosoftware.wikispaces.com/Modelo+Iterativo
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el
enfoque incremental de desarrollocomo una forma de reducir la repetición del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este
modelo se conoce también bajo las siguientes denominaciones:
 Método de las comparaciones limitadas sucesivas.
 Ciencia de salir del paso.
 Método de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la
filosofía interactiva de Construcción de Prototipos. Como se muestra en la
Figura 1, el modelo incremental aplica secuencias lineales de forma
escalonada mientras progresa el tiempo en el calendario. Cada secuencia
lineal produce un incremento del software. El primer incremento generalmente
es un producto esencial denominado núcleo.
En una visión genérica, el proceso se divide en 4 partes:
 Análisis
 Diseño
 Código
 Prueba

12. Sin embargo, para la producción del Software, se usa el principio de trabajo en
cadena o Pipeline. 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
elabora el producto completo. De esta forma el tiempo de entrega se reduce
considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada
incremento la entrega de un producto completamente operacional. Este modelo
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.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes
partes que al final terminará siendo la solución completa requerida por el
cliente, pero éstas partes no se pueden realizar en cualquier orden, sino
que dependen de lo que el cliente este necesitando con más urgencia, de
los puntos más importantes del proyecto, los requerimientos más
básicos, difíciles y con mayor grado de riesgo, ya que estos se deben
hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en
cada versión.
De este modo podemos terminar una aplicación ejecutable (primera versión)
que podrá ser entregada al cliente para que éste pueda trabajar en ella y el
programador pueda considerar las recomendaciones que el cliente efectúe
para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a
ser integradas en la siguiente versión junto con los demás requerimientos que
no fueron tomados en cuenta en la versión anterior.

13. El modelo incremental consiste en un desarrollo inicial de la arquitectura
completa del sistema, seguido de sucesivos incrementos funcionales. Cada
incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su
funcionalidad ni sus interfaces. Una vez entregado un incremento, no se
realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado
que la arquitectura completa se desarrolla en la etapa inicial, es necesario
conocer los requerimientos completos al comienzo del desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos,
las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo
de requisitos funcionales y será el cliente quien se encarga de priorizar que
funcionalidades son mas importantes. Con las funcionalidades priorizadas, se
puede confeccionar un plan de incrementos, donde en cada incremento se
indica un subconjunto de funcionalidades que el sistema entregará. La
asignación de funcionalidades a los incrementos depende de la prioridad dada
a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el
primer incremento.
Características:
 Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
 El usuario se involucra más.
 Dificil de evaluar el costo total.
 Dificil 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 positivo.
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.
 Resulta más sencillo acomodar cambios al acotar el tamaño de los
incrementos.

14. 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.
http://procesosoftware.wikispaces.com/Modelo+Incremental
MODELO ESPIRAL
EL Modelo Espiral, propuesto en 1988 por Barry Boehm, reconoce la
naturaleza iterativa del desarrollo y combina actividades de desarrollo con
gestión de riesgo, para minimizar y controlar el riesgo. Cada ciclo o iteración
del espiral se divide en cuatro fases: determinar objetivos, alternativas y
restricciones; evaluar alternativas, identificar y resolver los riesgos; desarrollar,
verificar el producto del próximo nivel y planificar las siguientes fases.
El modelo espiral es en cierto sentido semejante al Modelo Iterativo pues
maneja cuatro iteraciones o ciclos. Comienza con los requisitos y un plan inicial
de desarrollo (incluye presupuesto, restricciones y alternativas para personal,
diseño y ambiente de desarrollo). Se evalúan riesgos del proyecto y se
construye prototipos de las alternativas. Luego se escribe un documento con el
"concepto de las operaciones" que describe la funcionalidad del sistema en un
nivel alto, desde el punto de vista del usuario. Este es el producto de la 1°
iteración. A partir de este documento se especificación los requisitos del
software, los cuales son validados, éstos son el producto de la 2° iteración. En
la 3° iteración se hace un plan de desarrollo, se produce el diseño, que es
verificado y validado. en la 4° iteración se hace un plan de integración y prueba,
se genera el software y se realizan las pruebas.
En cada iteración se hace un análisis de riesgo de las alternativas según los
requisitos y restricciones, y se construyen prototipos para analizar las
alternativas y seleccionar una. Estos prototipos pueden ser simples maquetas
en papel, prototipos de interfaz de usuario o simulaciones del sistema,
dependiendo del riesgo a evaluar, según el ciclo en el proceso y del tipo de
aplicación.

15. http://procesosoftware.wikispaces.com/Modelo+Espiral
Modelos basados en reutilización
El diseño basado en reutilización puro busca construir un producto software
integrando componentes pre-existentes.
Los beneficios principales que otorga este modelo son:
-Tiempos de desarrollos cortos
-Disminución de errores
-Disminución de costos y riegos ya que se reduce los componentes a
desarrollar
-Existe un aumento de la confiabilidad ya que los componentes a utilizar ya
fueron testeados y utilizados en otro momento previo al comienzo del proyecto
A modo de desventaja podemos mencionar el hecho de que al no poseer algún
componente que cubra con un requisito dado por el usuario, este debe ser
modificado para adaptarlo a los componentes almacenados en el repositorio de
componentes.
Esto se da en el modelo puro. En cambio en el modelo real si no se puede
adaptar un requisito de usuario, se conseguirá o se desarrollara ese modulo
para que cumpla con lo pedido por el usuario.
Otra desventaja de este modelo es que una vez finalizada la etapa de
modificación de requisitos, y ante la eventual necesidad de cambios en estos
últimos, puede pasar que no haya componentes que se adapten a las nuevas
modificaciones.