07-09-2022

P1 ¿ QUÉ ES UN MODELO PRESCRIPTIVO?

R1.1. Los modelos del proceso prescriptivo fueron desarrollados para ordenar la situación en caso de que
exista un gran problema en el proyecto, en este se definen un conjunto de actividades, acciones, tareas,
hitos y demás trabajos que un equipo de software debe realizar para construir sistemas de alta calidad
[Murillo 18].

R1.2 Los modelos de proceso prescriptivo fueron propuestos originalmente para poner orden en el caos del
desarrollo de software. La historia indica que estos modelos tradicionales han dado cierta estructura útil al
trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz para los equipos de
software. Sin embargo, el trabajo de ingeniería de software y el producto que genera siguen al borde del
caos [Pressman 10].
R1.3 Un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que se
requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el trabajo de la ingeniería
del software [Fernández 20].

R1.4 Los modelos prescriptivos de proceso, los cuales definen un conjunto de actividades, acciones y
productos de trabajo usados para desarrollar software de alta calidad. Estos modelos de proceso no son
perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software [Cruz 14].

E1 = EF1: Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente
para poner orden en el caos del desarrollo de software. La historia indica que estos modelos
tradicionales han dado cierta estructura útil al trabajo de ingeniería de software y que constituyen un
mapa razonablemente eficaz para los equipos de software. Sin embargo, el trabajo de ingeniería de
software y el producto que genera siguen al borde del caos. Por su parte [Murillo 18] menciona que
los modelos del proceso prescriptivo fueron desarrollados para ordenar la situación en caso de que
exista un gran problema en el proyecto, en este se definen un conjunto de actividades, acciones,
tareas, hitos y demás trabajos que un equipo de software debe realizar para construir sistemas de alta
calidad. Asimismo [Fernández 20] indica que los modelos prescriptivos son un conjunto distinto de
actividades, acciones, tareas, fundamentos y productos de trabajo que se requieren para desarrollar
software de alta calidad. Proporcionan una guía útil para el trabajo de la ingeniería del software. Por
ultimo [Cruz 14] nos dice que estos modelos de proceso no son perfectos, pero proporcionan una guía
útil para el trabajo de la ingeniería del software.
 P2 ¿ QUÉ ES EL BORDE DEL CAOS?

R2.1. Es el estado natural entre el orden y el caos, un compromiso grande entre la estructura y la sorpresa
[Kau 95].

R2.2. Debido a interconexión e interacción entre sus múltiples elementos, a la retroalimentación y a la no-
linealidad de sus relaciones, los sistemas complejos adaptativos tienen la capacidad de balancearse entre
el orden y el caos. Esta región de balance es llamada el Borde del Caos y es considerada como la zona de
mayor creatividad de los sistemas [Tercero 17].

R2.3. Se trata de un espacio de transición entre el orden y el desorden, una región de inestabilidad limitada,
donde fuerzas progresivas y conservadoras luchan por el control [BBVA 18].

R2.4. El modelo del caos introduce la idea de que el azar, las condiciones cambiantes y la creatividad
pueden introducirse en cualquier momento en un sistema complejo y alterar su curso [Mercado 00].

E2: [Kau 95] menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso
grande entre la estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e
interacción entre sus múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los
sistemas complejos adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región
de balance es llamada el Borde del Caos y es considerada como la zona de mayor creatividad de los
sistemas. Asimismo [BBVA 18] nos dice que se trata de un espacio de transición entre el orden y el
desorden, una región de inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el
control. Por ultimo [Mercado 00], sugiere que introduce la idea de que el azar, las condiciones cambiantes
y la creatividad pueden introducirse en cualquier momento en un sistema complejo y alterar su curso.

EF2: Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen al borde del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo
fueron desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en
este se definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de
software debe realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los
modelos prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el
trabajo de la ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no
son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95]
menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso grande entre la
estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e interacción entre sus
múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos
adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región de balance es llamada
el Borde del Caos y es considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA
18] nos dice que se trata de un espacio de transición entre el orden y el desorden, una región de
inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el control. Por ultimo [Mercado
00], sugiere que introduce la idea de que el azar, las condiciones cambiantes y la creatividad pueden
introducirse en cualquier momento en un sistema complejo y alterar su curso.
 P3 ¿ QUÉ ES UN MODELO?

R3.1. Las acepciones del concepto de modelo son muy diversas. Puede considerarse al modelo, en términos
generales, como representación de la realidad, explicación de un fenómeno, ideal digno de imitarse,
paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno entre una
serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un sistema
social [Caracheo 02].

R3.2. Ejemplar o forma que uno propone y sigue en la ejecución de una obra artística o en otra cosa,
ejemplar para ser imitado, representación en pequeño de una cosa, copia o réplica de un original,
construcción o creación que sirve para medir, explicar e interpretar los rasgos y significados de las
actividades agrupadas en las diversas disciplinas [Gago 99].

R3.3. Los modelos son construcciones mentales que permiten una aproximación a la realidad de un
fenómeno, distinguiendo sus características para facilitar su comprensión. El término modelo, en
consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi cualquier cosa, desde
una maqueta hasta un conjunto de ideas abstractas [Achinstein 67].

R3.4. Un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno, con
miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos los
modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo que
podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento [Flórez 99].

E3: Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.

EF3:
Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen al borde del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo
fueron desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en
este se definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de
software debe realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los
modelos prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el
trabajo de la ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no
son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95]
menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso grande entre la
estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e interacción entre sus
múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos
adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región de balance es llamada
el Borde del Caos y es considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA
18] nos dice que se trata de un espacio de transición entre el orden y el desorden, una región de
inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el control. Por ultimo [Mercado
00], sugiere que introduce la idea de que el azar, las condiciones cambiantes y la creatividad pueden
introducirse en cualquier momento en un sistema complejo y alterar su curso.
Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.

P4 ¿ QUÉ ES UN PROCESO?

R4.1. Un proceso es el conjunto de pasos o etapas para llevar a cabo una actividad [Munch 18].

R4.2. Un proceso es una forma sistemática de hacer las cosas [Benavides 14].

R4.3. El proceso representa la secuencia básica de las pasos o actividades con que la empresa
concibe, diseña y lleva un producto al mercado [Jacobs 21].

R4.4. Se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria determinada y, par
semejanza, avanzar en el tiempo [Etece 21].

E4: Un proceso, según describe [Munch 18] es el conjunto de pasos o etapas para llevar a cabo una
actividad. Par su parte [Benavides 14] menciona que un proceso es una forma sistemática de hacer
las cosas. Asimismo [Jacobs 21] indica que el proceso representa la secuencia básica de las pasos o
actividades con que la empresa concibe, diseña y lleva un producto al mercado. Finalmente [Etece
21] señala que un proceso se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria
determinada y, par semejanza, avanzar en el tiempo.

EF4:
Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen al borde del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo
fueron desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en
este se definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de
software debe realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los
modelos prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el
trabajo de la ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no
son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95]
menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso grande entre la
estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e interacción entre sus
múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos
adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región de balance es llamada
el Borde del Caos y es considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA
18] nos dice que se trata de un espacio de transición entre el orden y el desorden, una región de
inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el control. Por ultimo [Mercado
00], sugiere que introduce la idea de que el azar, las condiciones cambiantes y la creatividad pueden
introducirse en cualquier momento en un sistema complejo y alterar su curso.
Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.
Un proceso, según describe [Munch 18] es el conjunto de pasos o etapas para llevar a cabo una actividad.
Par su parte [Benavides 14] menciona que un proceso es una forma sistemática de hacer las cosas.
Asimismo [Jacobs 21] indica que el proceso representa la secuencia básica de las pasos o actividades con
que la empresa concibe, diseña y lleva un producto al mercado. Finalmente [Etece 21] señala que un
proceso se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria determinada y, par
semejanza, avanzar en el tiempo.
 P5 ¿ QUÉ ES PRESCRIBIR?

R5.1. El término latino praescribere se convirtió, en nuestra lengua, en prescribir. El concepto tiene varios
significados que varían de acuerdo al contexto. Por ejemplo, puede tratarse de la acción de indicar, decretar
o fijar algo, como se puede apreciar en los siguientes ejemplos: “Le voy a prescribir un jarabe para la tos”, “El
médico me prescribió unas pastillas para controlar la presión”, “El jefe va a prescribir la utilización de un
nuevo uniforme en la empresa” [Gardey 13].

R5.2. Ordenar o mandar algo; también dejar de existir un derecho, una obligación o responsabilidad [Raimundo
03].

R5.3. P rescribir según [Espasa 05] es:

1.tr. Ordenar, determinar:
la ordenanza prescribe el pago inmediato de las multas.
2.Recetar el uso de un medicamento o remedio:
le han prescrito una cura de sueño.
3.intr. Extinguirse un derecho, deuda, acción o responsabilidad por el transcurso del tiempo especificado
para ello:
las multas de tráfico prescriben a los dos años.
R5.4. Prescribir es, según [Larousse 22]:
• tr. Ordenar o determinar.
• tr.-prnl.dquirir[una cosa o derecho] por virtud de posesión continuada, o caducar un derecho por paso del
tiempo señalado a este efecto.
• Intr. Concluir o extinguirse una obligación o deuda por el transcurso de cierto tiempo.
• fig.Perderse o mermarse una cosa por el transcurso del tiempo.
• tr. med. Recetar [un tratamiento].

E5: El término latino praescribere se convirtió, en nuestra lengua, en prescribir. El concepto tiene varios
significados que varían de acuerdo al contexto. Por ejemplo, puede tratarse de la acción de indicar, decretar
o fijar algo, como se puede apreciar en los siguientes ejemplos: “Le voy a prescribir un jarabe para la tos”, “El
médico me prescribió unas pastillas para controlar la presión”, “El jefe va a prescribir la utilización de un
nuevo uniforme en la empresa”, así lo menciona [Gardey 13]. Por su parte [Raimundo 03], define prescribir
como Ordenar o mandar algo; también dejar de existir un derecho, una obligación o responsabilida.
Asimismo [Espasa 05] indica que p rescribir según es:
4.tr. Ordenar, determinar:
la ordenanza prescribe el pago inmediato de las multas.
5.Recetar el uso de un medicamento o remedio:
le han prescrito una cura de sueño.
Finalmente [Larousse 22], describe la palabra describir como:
• tr. Ordenar o determinar.
• tr.-prnl.dquirir[una cosa o derecho] por virtud de posesión continuada, o caducar un derecho por paso del
tiempo señalado a este efecto.
• Intr. Concluir o extinguirse una obligación o deuda por el transcurso de cierto tiempo.
• fig.Perderse o mermarse una cosa por el transcurso del tiempo.
• tr. med. Recetar [un tratamiento].

EF5:
Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen al borde del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo
fueron desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en
este se definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de
software debe realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los
 modelos prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el
trabajo de la ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no
son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95]
menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso grande entre la
estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e interacción entre sus
múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos
adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región de balance es llamada
el Borde del Caos y es considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA
18] nos dice que se trata de un espacio de transición entre el orden y el desorden, una región de
inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el control. Por ultimo [Mercado
00], sugiere que introduce la idea de que el azar, las condiciones cambiantes y la creatividad pueden
introducirse en cualquier momento en un sistema complejo y alterar su curso.
Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.
Un proceso, según describe [Munch 18] es el conjunto de pasos o etapas para llevar a cabo una actividad.
Par su parte [Benavides 14] menciona que un proceso es una forma sistemática de hacer las cosas.
Asimismo [Jacobs 21] indica que el proceso representa la secuencia básica de las pasos o actividades con
que la empresa concibe, diseña y lleva un producto al mercado. Finalmente [Etece 21] señala que un
proceso se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria determinada y, par
semejanza, avanzar en el tiempo.
El término latino praescribere se convirtió, en nuestra lengua, en prescribir. El concepto tiene varios
significados que varían de acuerdo al contexto. Por ejemplo, puede tratarse de la acción de indicar, decretar
o fijar algo, como se puede apreciar en los siguientes ejemplos: “Le voy a prescribir un jarabe para la tos”, “El
médico me prescribió unas pastillas para controlar la presión”, “El jefe va a prescribir la utilización de un
nuevo uniforme en la empresa”, así lo menciona [Gardey 13]. Por su parte [Raimundo 03], define prescribir
como Ordenar o mandar algo; también dejar de existir un derecho, una obligación o responsabilida.
Asimismo [Espasa 05] indica que p rescribir según es:
6.tr. Ordenar, determinar:
la ordenanza prescribe el pago inmediato de las multas.
7.Recetar el uso de un medicamento o remedio:
le han prescrito una cura de sueño.
Finalmente [Larousse 22], describe la palabra describir como:
• tr. Ordenar o determinar.
• tr.-prnl.dquirir[una cosa o derecho] por virtud de posesión continuada, o caducar un derecho por paso del
tiempo señalado a este efecto.
• Intr. Concluir o extinguirse una obligación o deuda por el transcurso de cierto tiempo.
• fig.Perderse o mermarse una cosa por el transcurso del tiempo.
• tr. med. Recetar [un tratamiento].
 P6 ¿ Cuándo conviene usar cascada?

R6.1. Los gerentes de proyecto suelen recurrir al método de cascada:

Cuando hay una visión clara de lo que debería ser el producto final, cuando los clientes no tienen
posibilidad de cambiar el alcance del proyecto una vez que ha comenzado, cuando el concepto y la
definición son las claves del éxito (pero no la velocidad), cuando no hay requisitos ambiguos
[Stsepanets 21].
R6.2.
La siguiente lista propuesta por [Rasso 22] enumera algunos de los tipos de proyectos más importantes que han
utilizado las fases del modelo en cascada:
1.Desarrollo de software para la industria automotriz.
2.Creación de sistemas de gestión de recursos humanos.
3.Diseño de sistemas de gestión de la cadena de suministros.
4.Avances en los sistemas de control de las instalaciones nucleares.
5.Estudios y proyectos sobre transbordadores espaciales.

R6.3. La metodología en cascada no es ni mejor ni peor que otras, solo hay que saber elegirla cuando
resulta más conveniente su aplicación, en función del proyecto y sus necesidades. Y esto sucede, por
ejemplo, al enfrentarse a iniciativas estáticas, donde no es muy probable la introducción de cambios se
realizarán a lo largo del proceso de desarrollo o cuando se cuenta con equipos de trabajo de menor
experiencia, que pueden beneficiarse de una estructura más rígida, como la que propone este enfoque
[Pérez 16].
R6.4.
Se usa cuando:
• Equipos que necesitan un cronograma de proyecto más predecible y secuencial. Además tienen un
presupuesto fijo.
• Equipos de proyectos con menos experiencia.
• Empresas con menor tolerancia al cambio o al riesgo.
• Empresas cuyos clientes están limitados por el tiempo, los recursos y además no pueden colaborar con
frecuencia.
• Proyectos sencillos con requisitos sencillos.
• Proyectos que tienen el lujo de plazos más largos.
Como has podido ver existen diferentes escenarios para utilizar una metodología dependiendo de diferentes
factores [Openinnova 22].

E6: [Stsepanets 21] menciona que los gerentes de proyecto suelen recurrir al método de cascada cuando hay
una visión clara de lo que debería ser el producto final, cuando los clientes no tienen posibilidad de cambiar el
alcance del proyecto una vez que ha comenzado, cuando el concepto y la definición son las claves del éxito
(pero no la velocidad), cuando no hay requisitos ambiguos. Por su parte [Rasso 22] nos da los siguientes
ejemplos de uso que le han dado al modelo cascada:

1. Desarrollo de software para la industria automotriz.

2. Creación de sistemas de gestión de recursos humanos.
3. Diseño de sistemas de gestión de la cadena de suministros.
4. Avances en los sistemas de control de las instalaciones nucleares.
5. Estudios y proyectos sobre transbordadores espaciales.

Asimismo [Pérez 16] hace alusión a que la metodología en cascada no es ni mejor ni peor que otras, solo hay
que saber elegirla cuando resulta más conveniente su aplicación, en función del proyecto y sus necesidades. Y
esto sucede, por ejemplo, al enfrentarse a iniciativas estáticas, donde no es muy probable la introducción de
cambios se realizarán a lo largo del proceso de desarrollo o cuando se cuenta con equipos de trabajo de menor
experiencia, que pueden beneficiarse de una estructura más rígida, como la que propone este enfoque.
Finalmente [Openinnova 22], sugiere los siguientes puntos:
• Equipos que necesitan un cronograma de proyecto más predecible y secuencial. Además tienen un
presupuesto fijo.
 • Equipos de proyectos con menos experiencia.
• Empresas con menor tolerancia al cambio o al riesgo.
• Empresas cuyos clientes están limitados por el tiempo, los recursos y además no pueden colaborar con
frecuencia.
• Proyectos sencillos con requisitos sencillos.
• Proyectos que tienen el lujo de plazos más largos.

EF6:
Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen al borde del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo
fueron desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en
este se definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de
software debe realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los
modelos prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el
trabajo de la ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no
son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95]
menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso grande entre la
estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e interacción entre sus
múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos
adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región de balance es llamada
el Borde del Caos y es considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA
18] nos dice que se trata de un espacio de transición entre el orden y el desorden, una región de
inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el control. Por ultimo [Mercado
00], sugiere que introduce la idea de que el azar, las condiciones cambiantes y la creatividad pueden
introducirse en cualquier momento en un sistema complejo y alterar su curso.
Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.
Un proceso, según describe [Munch 18] es el conjunto de pasos o etapas para llevar a cabo una actividad.
Par su parte [Benavides 14] menciona que un proceso es una forma sistemática de hacer las cosas.
Asimismo [Jacobs 21] indica que el proceso representa la secuencia básica de las pasos o actividades con
que la empresa concibe, diseña y lleva un producto al mercado. Finalmente [Etece 21] señala que un
proceso se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria determinada y, par
semejanza, avanzar en el tiempo.
El término latino praescribere se convirtió, en nuestra lengua, en prescribir. El concepto tiene varios
significados que varían de acuerdo al contexto. Por ejemplo, puede tratarse de la acción de indicar, decretar
 o fijar algo, como se puede apreciar en los siguientes ejemplos: “Le voy a prescribir un jarabe para la tos”, “El
médico me prescribió unas pastillas para controlar la presión”, “El jefe va a prescribir la utilización de un
nuevo uniforme en la empresa”, así lo menciona [Gardey 13]. Por su parte [Raimundo 03], define prescribir
como Ordenar o mandar algo; también dejar de existir un derecho, una obligación o responsabilida.
Asimismo [Espasa 05] indica que p rescribir según es:
8.tr. Ordenar, determinar:
la ordenanza prescribe el pago inmediato de las multas.
9.Recetar el uso de un medicamento o remedio:
le han prescrito una cura de sueño.
Finalmente [Larousse 22], describe la palabra describir como:
• tr. Ordenar o determinar.
• tr.-prnl.dquirir[una cosa o derecho] por virtud de posesión continuada, o caducar un derecho por paso del
tiempo señalado a este efecto.
• Intr. Concluir o extinguirse una obligación o deuda por el transcurso de cierto tiempo.
• fig.Perderse o mermarse una cosa por el transcurso del tiempo.
• tr. med. Recetar [un tratamiento].
[Stsepanets 21] menciona que los gerentes de proyecto suelen recurrir al método de cascada cuando hay una
visión clara de lo que debería ser el producto final, cuando los clientes no tienen posibilidad de cambiar el
alcance del proyecto una vez que ha comenzado, cuando el concepto y la definición son las claves del éxito
(pero no la velocidad), cuando no hay requisitos ambiguos. Por su parte [Rasso 22] nos da los siguientes
ejemplos de uso que le han dado al modelo cascada:

1. Desarrollo de software para la industria automotriz.

2. Creación de sistemas de gestión de recursos humanos.
3. Diseño de sistemas de gestión de la cadena de suministros.
4. Avances en los sistemas de control de las instalaciones nucleares.
5. Estudios y proyectos sobre transbordadores espaciales.

Asimismo [Pérez 16] hace alusión a que la metodología en cascada no es ni mejor ni peor que otras, solo hay
que saber elegirla cuando resulta más conveniente su aplicación, en función del proyecto y sus necesidades. Y
esto sucede, por ejemplo, al enfrentarse a iniciativas estáticas, donde no es muy probable la introducción de
cambios se realizarán a lo largo del proceso de desarrollo o cuando se cuenta con equipos de trabajo de menor
experiencia, que pueden beneficiarse de una estructura más rígida, como la que propone este enfoque.
Finalmente [Openinnova 22], sugiere los siguientes puntos:
• Equipos que necesitan un cronograma de proyecto más predecible y secuencial. Además tienen un
presupuesto fijo.
• Equipos de proyectos con menos experiencia.
• Empresas con menor tolerancia al cambio o al riesgo.
• Empresas cuyos clientes están limitados por el tiempo, los recursos y además no pueden colaborar con
frecuencia.
• Proyectos sencillos con requisitos sencillos.
• Proyectos que tienen el lujo de plazos más largos.

P7 ¿Cuáles son las desventajas del método cascada?

R7.1. [Lucidchart 22] nos lista las siguientes desventajas del modelo de cascada:
1. Dificulta los cambios
La metodología de la cascada se basa completamente en seguir una serie de pasos que hacen que los equipos
siempre avancen. Esta metodología, en su forma tradicional, no deja prácticamente ningún lugar para cambios o
revisiones imprevistos.
2. Excluye al cliente o al usuario final
Como proceso interno, el modelo de cascada se concentra muy poco en el usuario o el cliente final de un
proyecto. Su principal objeto siempre ha sido ayudar a que los equipos internos avancen más eficientemente por
las distintas fases del proyecto, lo que puede funcionar bien en el mundo del software.
3. Retrasa las pruebas hasta después de la finalización
Dejar la fase de pruebas para la última mitad de un proyecto es riesgoso, pero la metodología de cascada insiste
en que los equipos esperen hasta el paso cuatro de seis para probar sus productos.
 R7.2. [Risso 22] nos lista las siguientes desventajas del modelo de cascada:
• Si estás realizando un proyecto grande o muy complejo, puede que sea más difícil dividirlo en fases
ordenadas, por lo que este sistema puede no ser el más adecuado.
• Debido a la forma de trabajo lineal, tienes menos tiempo para concluir cada una de las fases del modelo
en cascada.
• No puedes pasar a la etapa siguiente hasta que completes la anterior.
• En ocasiones, los fallos no se detectan hasta la última fase del desarrollo, por lo que, para resolverlo
tendrás que regresar a las fases anteriores y repetirlas o modificarlas.

R7.3.
Este método es increíblemente rígido e inflexible, lo que plante inconvenientes como:
• Alterar el diseño del proyecto en cualquier etapa es muy complicado.
• Una vez que una fase se ha completado, es casi imposible de realizar cambios.
• Es absolutamente necesario reunir todos los requisitos iniciales.
• Resulta muy difícil responder a los problemas que puedan surgir, ya que tanto la retroalimentación, como
las pruebas se retrasan hasta estadios muy tardíos del desarrollo de proyecto.
• Solucionar cualquier cuestión que se plantee requiere una cantidad sustancial de tiempo, esfuerzo y
dinero.
La metodología en cascada no es ni mejor ni peor que otras, solo hay que saber elegirla cuando resulta más
conveniente su aplicación, en función del proyecto y sus necesidades [Pérez 16].

R7.4. [Ricardo 20] menciona las siguientes desventajas del modelo de cascada:

• No permite cambios de alcance

• No permite cambios de requisitos
• Ningún producto funcional hasta casi la finalización del proyecto
• Incapaz de manejar fácilmente riesgos inesperados

E7:
[Lucidchart 22] nos lista las siguientes desventajas del modelo de cascada:
1. Dificulta los cambios
La metodología de la cascada se basa completamente en seguir una serie de pasos que hacen que los equipos
siempre avancen. Esta metodología, en su forma tradicional, no deja prácticamente ningún lugar para cambios o
revisiones imprevistos.
2. Excluye al cliente o al usuario final
Como proceso interno, el modelo de cascada se concentra muy poco en el usuario o el cliente final de un
proyecto. Su principal objeto siempre ha sido ayudar a que los equipos internos avancen más eficientemente por
las distintas fases del proyecto, lo que puede funcionar bien en el mundo del software.
3. Retrasa las pruebas hasta después de la finalización
Dejar la fase de pruebas para la última mitad de un proyecto es riesgoso, pero la metodología de cascada insiste
en que los equipos esperen hasta el paso cuatro de seis para probar sus productos.

Por su parte, [Risso 22] menciona las siguientes desventajas del modelo de cascada:
• Si estás realizando un proyecto grande o muy complejo, puede que sea más difícil dividirlo en fases
ordenadas, por lo que este sistema puede no ser el más adecuado.
• Debido a la forma de trabajo lineal, tienes menos tiempo para concluir cada una de las fases del modelo
en cascada.
• No puedes pasar a la etapa siguiente hasta que completes la anterior.
• En ocasiones, los fallos no se detectan hasta la última fase del desarrollo, por lo que, para resolverlo
tendrás que regresar a las fases anteriores y repetirlas o modificarlas.
Asimismo, [Pérez 16] describe este método como increíblemente rígido e inflexible, lo que plantea
inconvenientes como:
• Alterar el diseño del proyecto en cualquier etapa es muy complicado.
• Una vez que una fase se ha completado, es casi imposible de realizar cambios.
• Es absolutamente necesario reunir todos los requisitos iniciales.
• Resulta muy difícil responder a los problemas que puedan surgir, ya que tanto la retroalimentación, como
las pruebas se retrasan hasta estadios muy tardíos del desarrollo de proyecto.
• Solucionar cualquier cuestión que se plantee requiere una cantidad sustancial de tiempo, esfuerzo y
 dinero.

Finalmente, [Ricardo 20] menciona las siguientes desventajas del modelo de cascada:

• No permite cambios de alcance.

• No permite cambios de requisitos.
• Ningún producto funcional hasta casi la finalización del proyecto.
• Incapaz de manejar fácilmente riesgos inesperados.

EF7:
Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen al borde del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo
fueron desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en
este se definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de
software debe realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los
modelos prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el
trabajo de la ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no
son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95]
menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso grande entre la
estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e interacción entre sus
múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos
adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región de balance es llamada
el Borde del Caos y es considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA
18] nos dice que se trata de un espacio de transición entre el orden y el desorden, una región de
inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el control. Por ultimo [Mercado
00], sugiere que introduce la idea de que el azar, las condiciones cambiantes y la creatividad pueden
introducirse en cualquier momento en un sistema complejo y alterar su curso.
Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.
Un proceso, según describe [Munch 18] es el conjunto de pasos o etapas para llevar a cabo una actividad.
Par su parte [Benavides 14] menciona que un proceso es una forma sistemática de hacer las cosas.
Asimismo [Jacobs 21] indica que el proceso representa la secuencia básica de las pasos o actividades con
que la empresa concibe, diseña y lleva un producto al mercado. Finalmente [Etece 21] señala que un
proceso se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria determinada y, par
semejanza, avanzar en el tiempo.
 El término latino praescribere se convirtió, en nuestra lengua, en prescribir. El concepto tiene varios
significados que varían de acuerdo al contexto. Por ejemplo, puede tratarse de la acción de indicar, decretar
o fijar algo, como se puede apreciar en los siguientes ejemplos: “Le voy a prescribir un jarabe para la tos”, “El
médico me prescribió unas pastillas para controlar la presión”, “El jefe va a prescribir la utilización de un
nuevo uniforme en la empresa”, así lo menciona [Gardey 13]. Por su parte [Raimundo 03], define prescribir
como Ordenar o mandar algo; también dejar de existir un derecho, una obligación o responsabilida.
Asimismo [Espasa 05] indica que p rescribir según es:
10.tr. Ordenar, determinar:
la ordenanza prescribe el pago inmediato de las multas.
11.Recetar el uso de un medicamento o remedio:
le han prescrito una cura de sueño.
Finalmente [Larousse 22], describe la palabra describir como:
• tr. Ordenar o determinar.
• tr.-prnl.dquirir[una cosa o derecho] por virtud de posesión continuada, o caducar un derecho por paso del
tiempo señalado a este efecto.
• Intr. Concluir o extinguirse una obligación o deuda por el transcurso de cierto tiempo.
• fig.Perderse o mermarse una cosa por el transcurso del tiempo.
• tr. med. Recetar [un tratamiento].
[Stsepanets 21] menciona que los gerentes de proyecto suelen recurrir al método de cascada cuando hay una
visión clara de lo que debería ser el producto final, cuando los clientes no tienen posibilidad de cambiar el
alcance del proyecto una vez que ha comenzado, cuando el concepto y la definición son las claves del éxito
(pero no la velocidad), cuando no hay requisitos ambiguos. Por su parte [Rasso 22] nos da los siguientes
ejemplos de uso que le han dado al modelo cascada:

1. Desarrollo de software para la industria automotriz.

2. Creación de sistemas de gestión de recursos humanos.
3. Diseño de sistemas de gestión de la cadena de suministros.
4. Avances en los sistemas de control de las instalaciones nucleares.
5. Estudios y proyectos sobre transbordadores espaciales.

Asimismo [Pérez 16] hace alusión a que la metodología en cascada no es ni mejor ni peor que otras, solo hay
que saber elegirla cuando resulta más conveniente su aplicación, en función del proyecto y sus necesidades. Y
esto sucede, por ejemplo, al enfrentarse a iniciativas estáticas, donde no es muy probable la introducción de
cambios se realizarán a lo largo del proceso de desarrollo o cuando se cuenta con equipos de trabajo de menor
experiencia, que pueden beneficiarse de una estructura más rígida, como la que propone este enfoque.
Finalmente [Openinnova 22], sugiere los siguientes puntos:
• Equipos que necesitan un cronograma de proyecto más predecible y secuencial. Además tienen un
presupuesto fijo.
• Equipos de proyectos con menos experiencia.
• Empresas con menor tolerancia al cambio o al riesgo.
• Empresas cuyos clientes están limitados por el tiempo, los recursos y además no pueden colaborar con
frecuencia.
• Proyectos sencillos con requisitos sencillos.
• Proyectos que tienen el lujo de plazos más largos.
[Lucidchart 22] nos lista las siguientes desventajas del modelo de cascada:
1. Dificulta los cambios
La metodología de la cascada se basa completamente en seguir una serie de pasos que hacen que los equipos
siempre avancen. Esta metodología, en su forma tradicional, no deja prácticamente ningún lugar para cambios o
revisiones imprevistos.
2. Excluye al cliente o al usuario final
Como proceso interno, el modelo de cascada se concentra muy poco en el usuario o el cliente final de un
proyecto. Su principal objeto siempre ha sido ayudar a que los equipos internos avancen más eficientemente por
las distintas fases del proyecto, lo que puede funcionar bien en el mundo del software.
3. Retrasa las pruebas hasta después de la finalización
Dejar la fase de pruebas para la última mitad de un proyecto es riesgoso, pero la metodología de cascada insiste
en que los equipos esperen hasta el paso cuatro de seis para probar sus productos.
Por su parte, [Risso 22] menciona las siguientes desventajas del modelo de cascada:
• Si estás realizando un proyecto grande o muy complejo, puede que sea más difícil dividirlo en fases
 ordenadas, por lo que este sistema puede no ser el más adecuado.
• Debido a la forma de trabajo lineal, tienes menos tiempo para concluir cada una de las fases del modelo
en cascada.
• No puedes pasar a la etapa siguiente hasta que completes la anterior.
• En ocasiones, los fallos no se detectan hasta la última fase del desarrollo, por lo que, para resolverlo
tendrás que regresar a las fases anteriores y repetirlas o modificarlas.
Asimismo, [Pérez 16] describe este método como increíblemente rígido e inflexible, lo que plantea
inconvenientes como:
• Alterar el diseño del proyecto en cualquier etapa es muy complicado.
• Una vez que una fase se ha completado, es casi imposible de realizar cambios.
• Es absolutamente necesario reunir todos los requisitos iniciales.
• Resulta muy difícil responder a los problemas que puedan surgir, ya que tanto la retroalimentación, como
las pruebas se retrasan hasta estadios muy tardíos del desarrollo de proyecto.
• Solucionar cualquier cuestión que se plantee requiere una cantidad sustancial de tiempo, esfuerzo y
dinero.
Finalmente, [Ricardo 20] menciona las siguientes desventajas del modelo de cascada:
• No permite cambios de alcance.
• No permite cambios de requisitos.
• Ningún producto funcional hasta casi la finalización del proyecto.
• Incapaz de manejar fácilmente riesgos inesperados.

P8 ¿ QUÉ ES UN MODELO DE SOFTWARE?

R8.1. Un proceso para producir software de forma organizada, empleando una colección de técnicas
y convenciones de notación predefinidas [Rumbaugh 91].

R8.2. Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los
desarrolladores a realizar nuevo software [Piattini 04].

R8.3. Una metodología es una aproximación organizada y sistemática para el ciclo de vida del
sistema o sus partes. Especifica las tareas individuales y sus secuencias [Palvia 93].

R8.4. Un modelo de proceso de software es una representación simplificada de este proceso. Cada
modelo del proceso representa a otro desde una particular perspectiva y, por lo tanto, ofrece solo
información parcial acerca de dicho proceso [Sommerville 11].

E8: [Rumbaugh 91] define los modelos de software como un proceso para producir software de forma
organizada, empleando una colección de técnicas y convenciones de notación predefinidas. Por otra
parte, [Piattini 04] menciona que es un conjunto de procedimientos, técnicas, herramientas y un
soporte documental que ayuda a los desarrolladores a realizar nuevo software. Asimismo [Palvia 93]
describe los modelos como una aproximación organizada y sistemática para el ciclo de vida del
sistema o sus partes. Especifica las tareas individuales y sus secuencias. Finalmente [Sommerville
11] indica que un modelo de proceso de software es una representación simplificada de este proceso.
Cada modelo del proceso representa a otro desde una particular perspectiva y, por lo tanto, ofrece
solo información parcial acerca de dicho proceso. En otras palabras los modelos de software son un
conjunto de actividades organizadas con el fin de desarrollar software.

EF8: Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado cierta
estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz para los
equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera siguen al borde
del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo fueron
desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en este se
definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de software debe
realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los modelos
prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que
se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el trabajo de la
ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no son perfectos,
pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95] menciona que el borde del
caos es el estado natural entre el orden y el caos, un compromiso grande entre la estructura y la sorpresa. Por
su parte [Tercero 17] indica que debido a interconexión e interacción entre sus múltiples elementos, a la
retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos adaptativos tienen la capacidad
de balancearse entre el orden y el caos. Esta región de balance es llamada el Borde del Caos y es
considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA 18] nos dice que se trata de
un espacio de transición entre el orden y el desorden, una región de inestabilidad limitada, donde fuerzas
progresivas y conservadoras luchan por el control. Por ultimo [Mercado 00], sugiere que introduce la idea de que
el azar, las condiciones cambiantes y la creatividad pueden introducirse en cualquier momento en un
sistema complejo y alterar su curso.
Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.
Un proceso, según describe [Munch 18] es el conjunto de pasos o etapas para llevar a cabo una actividad.
Par su parte [Benavides 14] menciona que un proceso es una forma sistemática de hacer las cosas.
Asimismo [Jacobs 21] indica que el proceso representa la secuencia básica de las pasos o actividades con
que la empresa concibe, diseña y lleva un producto al mercado. Finalmente [Etece 21] señala que un
proceso se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria determinada y, par
semejanza, avanzar en el tiempo.
El término latino praescribere se convirtió, en nuestra lengua, en prescribir. El concepto tiene varios
significados que varían de acuerdo al contexto. Por ejemplo, puede tratarse de la acción de indicar, decretar
o fijar algo, como se puede apreciar en los siguientes ejemplos: “Le voy a prescribir un jarabe para la tos”, “El
médico me prescribió unas pastillas para controlar la presión”, “El jefe va a prescribir la utilización de un
nuevo uniforme en la empresa”, así lo menciona [Gardey 13]. Por su parte [Raimundo 03], define prescribir
como Ordenar o mandar algo; también dejar de existir un derecho, una obligación o responsabilida.
Asimismo [Espasa 05] indica que p rescribir según es:
12.tr. Ordenar, determinar:
la ordenanza prescribe el pago inmediato de las multas.
13.Recetar el uso de un medicamento o remedio:
le han prescrito una cura de sueño.
Finalmente [Larousse 22], describe la palabra describir como:
• tr. Ordenar o determinar.
• tr.-prnl.dquirir[una cosa o derecho] por virtud de posesión continuada, o caducar un derecho por paso del
tiempo señalado a este efecto.
• Intr. Concluir o extinguirse una obligación o deuda por el transcurso de cierto tiempo.
• fig.Perderse o mermarse una cosa por el transcurso del tiempo.
• tr. med. Recetar [un tratamiento].
[Stsepanets 21] menciona que los gerentes de proyecto suelen recurrir al método de cascada cuando hay una
visión clara de lo que debería ser el producto final, cuando los clientes no tienen posibilidad de cambiar el
alcance del proyecto una vez que ha comenzado, cuando el concepto y la definición son las claves del éxito
(pero no la velocidad), cuando no hay requisitos ambiguos. Por su parte [Rasso 22] nos da los siguientes
ejemplos de uso que le han dado al modelo cascada:

1. Desarrollo de software para la industria automotriz.

2. Creación de sistemas de gestión de recursos humanos.
3. Diseño de sistemas de gestión de la cadena de suministros.
4. Avances en los sistemas de control de las instalaciones nucleares.
5. Estudios y proyectos sobre transbordadores espaciales.

Asimismo [Pérez 16] hace alusión a que la metodología en cascada no es ni mejor ni peor que otras, solo hay
que saber elegirla cuando resulta más conveniente su aplicación, en función del proyecto y sus necesidades. Y
esto sucede, por ejemplo, al enfrentarse a iniciativas estáticas, donde no es muy probable la introducción de
cambios se realizarán a lo largo del proceso de desarrollo o cuando se cuenta con equipos de trabajo de menor
experiencia, que pueden beneficiarse de una estructura más rígida, como la que propone este enfoque.
Finalmente [Openinnova 22], sugiere los siguientes puntos:
• Equipos que necesitan un cronograma de proyecto más predecible y secuencial. Además tienen un
presupuesto fijo.
• Equipos de proyectos con menos experiencia.
• Empresas con menor tolerancia al cambio o al riesgo.
• Empresas cuyos clientes están limitados por el tiempo, los recursos y además no pueden colaborar con
frecuencia.
• Proyectos sencillos con requisitos sencillos.
• Proyectos que tienen el lujo de plazos más largos.
[Lucidchart 22] nos lista las siguientes desventajas del modelo de cascada:
1. Dificulta los cambios
La metodología de la cascada se basa completamente en seguir una serie de pasos que hacen que los equipos
siempre avancen. Esta metodología, en su forma tradicional, no deja prácticamente ningún lugar para cambios o
revisiones imprevistos.
2. Excluye al cliente o al usuario final
Como proceso interno, el modelo de cascada se concentra muy poco en el usuario o el cliente final de un
proyecto. Su principal objeto siempre ha sido ayudar a que los equipos internos avancen más eficientemente por
las distintas fases del proyecto, lo que puede funcionar bien en el mundo del software.
3. Retrasa las pruebas hasta después de la finalización
Dejar la fase de pruebas para la última mitad de un proyecto es riesgoso, pero la metodología de cascada insiste
en que los equipos esperen hasta el paso cuatro de seis para probar sus productos.

Por su parte, [Risso 22] menciona las siguientes desventajas del modelo de cascada:
• Si estás realizando un proyecto grande o muy complejo, puede que sea más difícil dividirlo en fases
ordenadas, por lo que este sistema puede no ser el más adecuado.
• Debido a la forma de trabajo lineal, tienes menos tiempo para concluir cada una de las fases del modelo
en cascada.
• No puedes pasar a la etapa siguiente hasta que completes la anterior.
• En ocasiones, los fallos no se detectan hasta la última fase del desarrollo, por lo que, para resolverlo
tendrás que regresar a las fases anteriores y repetirlas o modificarlas.
Asimismo, [Pérez 16] describe este método como increíblemente rígido e inflexible, lo que plantea
inconvenientes como:
• Alterar el diseño del proyecto en cualquier etapa es muy complicado.
• Una vez que una fase se ha completado, es casi imposible de realizar cambios.
• Es absolutamente necesario reunir todos los requisitos iniciales.
• Resulta muy difícil responder a los problemas que puedan surgir, ya que tanto la retroalimentación, como
las pruebas se retrasan hasta estadios muy tardíos del desarrollo de proyecto.
• Solucionar cualquier cuestión que se plantee requiere una cantidad sustancial de tiempo, esfuerzo y
dinero.
Finalmente, [Ricardo 20] menciona las siguientes desventajas del modelo de cascada:
• No permite cambios de alcance.
• No permite cambios de requisitos.
• Ningún producto funcional hasta casi la finalización del proyecto.
• Incapaz de manejar fácilmente riesgos inesperados.
Rumbaugh 91] define los modelos de software como un proceso para producir software de forma organizada,
empleando una colección de técnicas y convenciones de notación predefinidas. Por otra parte, [Piattini 04]
menciona que es un conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a
los desarrolladores a realizar nuevo software. Asimismo [Palvia 93] describe los modelos como una
aproximación organizada y sistemática para el ciclo de vida del sistema o sus partes. Especifica las tareas
individuales y sus secuencias. Finalmente [Sommerville 11] indica que un modelo de proceso de software es
una representación simplificada de este proceso. Cada modelo del proceso representa a otro desde una
particular perspectiva y, por lo tanto, ofrece solo información parcial acerca de dicho proceso. En otras
palabras los modelos de software son un conjunto de actividades organizadas con el fin de desarrollar software.

P9 ¿ QUÉ ES EL MÉTODO CASCADA?

R9.1. Este toma las actividades fundamentales del proceso de especificación, desarrollo, validación y
evolución y, luego, los representa como fases separadas del proceso, tal como especificación de
requerimientos, diseño de software, implementación, pruebas, etcétera [Sommerville 11].

R9.2. El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y
secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por
parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el
apoyo del software terminado [Pressman 10].

R9.3. Es un modelo de desarrollo lineal secuencial. El proyecto de software es dividido en fases que deben
procesarse en forma secuencial [Pantaleo 15].

R9.4. El modelo en cascada refleja la necesidad impuesta por la realidad de retornar con frecuencia desde
una fase hacia las anteriores con la información generada al avanzar el desarrollo [Palacios 06].

E9: El modelo de cascada toma las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución y, luego, los representa como fases separadas del proceso, tal como
especificación de requerimientos, diseño de software, implementación, pruebas, etcétera. Esto según
menciona [Sommerville 11]. Por otro lado [Pressman 10] describe que el modelo de cascada sugiere un
enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los
requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue,
para concluir con el apoyo del software terminado. [Pantaleo 15] plantea que es un modelo de desarrollo
lineal secuencial. El proyecto de software es dividido en fases que deben procesarse en forma secuencial.
Finalmente [Palacios 06] indica que este modelo refleja la necesidad impuesta por la realidad de retornar
con frecuencia desde una fase hacia las anteriores con la información generada al avanzar el desarrollo. En
otras palabras el método cascada separa el proyecto en fases secuenciales que satisface la necesidad de
retornar entre fases durante el desarrollo.

EF9:
Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen al borde del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo
fueron desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en
este se definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de
software debe realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los
modelos prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el
trabajo de la ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no
son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95]
 menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso grande entre la
estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e interacción entre sus
múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos
adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región de balance es llamada
el Borde del Caos y es considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA
18] nos dice que se trata de un espacio de transición entre el orden y el desorden, una región de
inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el control. Por ultimo [Mercado
00], sugiere que introduce la idea de que el azar, las condiciones cambiantes y la creatividad pueden
introducirse en cualquier momento en un sistema complejo y alterar su curso.
Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.
Un proceso, según describe [Munch 18] es el conjunto de pasos o etapas para llevar a cabo una actividad.
Par su parte [Benavides 14] menciona que un proceso es una forma sistemática de hacer las cosas.
Asimismo [Jacobs 21] indica que el proceso representa la secuencia básica de las pasos o actividades con
que la empresa concibe, diseña y lleva un producto al mercado. Finalmente [Etece 21] señala que un
proceso se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria determinada y, par
semejanza, avanzar en el tiempo.
El término latino praescribere se convirtió, en nuestra lengua, en prescribir. El concepto tiene varios
significados que varían de acuerdo al contexto. Por ejemplo, puede tratarse de la acción de indicar, decretar
o fijar algo, como se puede apreciar en los siguientes ejemplos: “Le voy a prescribir un jarabe para la tos”, “El
médico me prescribió unas pastillas para controlar la presión”, “El jefe va a prescribir la utilización de un
nuevo uniforme en la empresa”, así lo menciona [Gardey 13]. Por su parte [Raimundo 03], define prescribir
como Ordenar o mandar algo; también dejar de existir un derecho, una obligación o responsabilida.
Asimismo [Espasa 05] indica que p rescribir según es:
14.tr. Ordenar, determinar:
la ordenanza prescribe el pago inmediato de las multas.
15.Recetar el uso de un medicamento o remedio:
le han prescrito una cura de sueño.
Finalmente [Larousse 22], describe la palabra describir como:
• tr. Ordenar o determinar.
• tr.-prnl.dquirir[una cosa o derecho] por virtud de posesión continuada, o caducar un derecho por paso del
tiempo señalado a este efecto.
• Intr. Concluir o extinguirse una obligación o deuda por el transcurso de cierto tiempo.
• fig.Perderse o mermarse una cosa por el transcurso del tiempo.
• tr. med. Recetar [un tratamiento].
[Stsepanets 21] menciona que los gerentes de proyecto suelen recurrir al método de cascada cuando hay una
visión clara de lo que debería ser el producto final, cuando los clientes no tienen posibilidad de cambiar el
alcance del proyecto una vez que ha comenzado, cuando el concepto y la definición son las claves del éxito
(pero no la velocidad), cuando no hay requisitos ambiguos. Por su parte [Rasso 22] nos da los siguientes
ejemplos de uso que le han dado al modelo cascada:

1. Desarrollo de software para la industria automotriz.

2. Creación de sistemas de gestión de recursos humanos.
3. Diseño de sistemas de gestión de la cadena de suministros.
4. Avances en los sistemas de control de las instalaciones nucleares.
5. Estudios y proyectos sobre transbordadores espaciales.

Asimismo [Pérez 16] hace alusión a que la metodología en cascada no es ni mejor ni peor que otras, solo hay
que saber elegirla cuando resulta más conveniente su aplicación, en función del proyecto y sus necesidades. Y
esto sucede, por ejemplo, al enfrentarse a iniciativas estáticas, donde no es muy probable la introducción de
cambios se realizarán a lo largo del proceso de desarrollo o cuando se cuenta con equipos de trabajo de menor
experiencia, que pueden beneficiarse de una estructura más rígida, como la que propone este enfoque.
Finalmente [Openinnova 22], sugiere los siguientes puntos:
• Equipos que necesitan un cronograma de proyecto más predecible y secuencial. Además tienen un
presupuesto fijo.
• Equipos de proyectos con menos experiencia.
• Empresas con menor tolerancia al cambio o al riesgo.
• Empresas cuyos clientes están limitados por el tiempo, los recursos y además no pueden colaborar con
frecuencia.
• Proyectos sencillos con requisitos sencillos.
• Proyectos que tienen el lujo de plazos más largos.
[Lucidchart 22] nos lista las siguientes desventajas del modelo de cascada:
1. Dificulta los cambios
La metodología de la cascada se basa completamente en seguir una serie de pasos que hacen que los equipos
siempre avancen. Esta metodología, en su forma tradicional, no deja prácticamente ningún lugar para cambios o
revisiones imprevistos.
2. Excluye al cliente o al usuario final
Como proceso interno, el modelo de cascada se concentra muy poco en el usuario o el cliente final de un
proyecto. Su principal objeto siempre ha sido ayudar a que los equipos internos avancen más eficientemente por
las distintas fases del proyecto, lo que puede funcionar bien en el mundo del software.
3. Retrasa las pruebas hasta después de la finalización
Dejar la fase de pruebas para la última mitad de un proyecto es riesgoso, pero la metodología de cascada insiste
en que los equipos esperen hasta el paso cuatro de seis para probar sus productos.

Por su parte, [Risso 22] menciona las siguientes desventajas del modelo de cascada:
• Si estás realizando un proyecto grande o muy complejo, puede que sea más difícil dividirlo en fases
ordenadas, por lo que este sistema puede no ser el más adecuado.
• Debido a la forma de trabajo lineal, tienes menos tiempo para concluir cada una de las fases del modelo
en cascada.
• No puedes pasar a la etapa siguiente hasta que completes la anterior.
• En ocasiones, los fallos no se detectan hasta la última fase del desarrollo, por lo que, para resolverlo
tendrás que regresar a las fases anteriores y repetirlas o modificarlas.
Asimismo, [Pérez 16] describe este método como increíblemente rígido e inflexible, lo que plantea
inconvenientes como:
• Alterar el diseño del proyecto en cualquier etapa es muy complicado.
• Una vez que una fase se ha completado, es casi imposible de realizar cambios.
• Es absolutamente necesario reunir todos los requisitos iniciales.
• Resulta muy difícil responder a los problemas que puedan surgir, ya que tanto la retroalimentación, como
las pruebas se retrasan hasta estadios muy tardíos del desarrollo de proyecto.
• Solucionar cualquier cuestión que se plantee requiere una cantidad sustancial de tiempo, esfuerzo y
dinero.
Finalmente, [Ricardo 20] menciona las siguientes desventajas del modelo de cascada:
• No permite cambios de alcance.
• No permite cambios de requisitos.
• Ningún producto funcional hasta casi la finalización del proyecto.
• Incapaz de manejar fácilmente riesgos inesperados.
Rumbaugh 91] define los modelos de software como un proceso para producir software de forma
organizada, empleando una colección de técnicas y convenciones de notación predefinidas. Por otra parte,
 [Piattini 04] menciona que es un conjunto de procedimientos, técnicas, herramientas y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software. Asimismo [Palvia 93] describe los
modelos como una aproximación organizada y sistemática para el ciclo de vida del sistema o sus partes.
Especifica las tareas individuales y sus secuencias. Finalmente [Sommerville 11] indica que un modelo de
proceso de software es una representación simplificada de este proceso. Cada modelo del proceso
representa a otro desde una particular perspectiva y, por lo tanto, ofrece solo información parcial acerca
de dicho proceso. En otras palabras los modelos de software son un conjunto de actividades organizadas
con el fin de desarrollar software.
El modelo de cascada toma las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución y, luego, los representa como fases separadas del proceso, tal como
especificación de requerimientos, diseño de software, implementación, pruebas, etcétera. Esto según
menciona [Sommerville 11]. Por otro lado [Pressman 10] describe que el modelo de cascada sugiere un
enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los
requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue,
para concluir con el apoyo del software terminado. [Pantaleo 15] plantea que es un modelo de desarrollo
lineal secuencial. El proyecto de software es dividido en fases que deben procesarse en forma secuencial.
Finalmente [Palacios 06] indica que este modelo refleja la necesidad impuesta por la realidad de retornar
con frecuencia desde una fase hacia las anteriores con la información generada al avanzar el desarrollo. En
otras palabras el método cascada separa el proyecto en fases secuenciales que satisface la necesidad de
retornar entre fases durante el desarrollo.

P10 ¿ Cuáles son las ventajas del método cascada?

R10.1. [Lucidchart 22] nos lista las siguientes ventajas del modelo de cascada:
▪ Usa una estructura clara. En comparación con otras metodologías, la cascada se concentra
mayormente en una serie de pasos claros y definidos.
▪ Determina el objetivo final rápidamente. Uno de los pasos definitorios del método de cascada es
comprometerse con un producto final, un objetivo o un entregable desde el principio, y los
equipos deberían evitar desviarse de ese compromiso.
▪ Transmite bien la información. El enfoque de la cascada es sumamente metódico, así que no
debería resultar una sorpresa que la metodología enfatice una transferencia clara de información
en cada paso.
R10.2. [Risso 22] nos lista las siguientes ventajas del modelo de cascada:
• Te ayuda a llevar un orden y organizar tu trabajo.
• Es muy útil si no tienes demasiada experiencia.
• Funciona de manera óptima en la mayoría de los dispositivos.
• Es sencillo y fácil de seguir.
• Te brinda las herramientas necesarias para tener claridad en tus objetivos desde el comienzo del
proyecto.
• Al encontrar un problema, ofrece la oportunidad de detectar la fase del modelo en cascada en la que
surgió y así arreglarlo lo más rápido posible.

R10.3.
Debido a que el método de cascada requiere una amplio esfuerzo de preparación previa, permite:
• Comenzar con el software con bastante rapidez.
• Estimar calendarios y presupuestos con mayor precisión.
• Lograr un nivel de satisfacción del cliente más elevado que otros enfoques, ya desde el principio.
La metodología en cascada supera algunas de las limitaciones de otros métodos, como: A/ Scrum: los procesos
de desarrollo que siguen la metodología en cascada tienden a ser más seguro, ya que existe una firme
orientación al plan [Pérez 16].

R10.4. [Ricardo 20] menciona las siguientes ventajas del modelo cascada:
 • Adecuado para proyectos simples o pequeños.
• Los requisitos se entienden bien
• Fácil de entender
• Fácil de manejar
• Hitos claros
• Documentación extensa

E10: [Lucidchart 22] nos lista las siguientes ventajas del modelo de cascada:
▪ Usa una estructura clara. En comparación con otras metodologías, la cascada se concentra
mayormente en una serie de pasos claros y definidos.
▪ Determina el objetivo final rápidamente. Uno de los pasos definitorios del método de cascada es
comprometerse con un producto final, un objetivo o un entregable desde el principio, y los
equipos deberían evitar desviarse de ese compromiso.
Transmite bien la información. El enfoque de la cascada es sumamente metódico, así que no debería
resultar una sorpresa que la metodología enfatice una transferencia clara de información en cada paso.
Por su parte [Risso 22] hace mención de las siguientes ventajas del modelo de cascada:
• Te ayuda a llevar un orden y organizar tu trabajo.
• Es muy útil si no tienes demasiada experiencia.
• Funciona de manera óptima en la mayoría de los dispositivos.
• Es sencillo y fácil de seguir.
• Te brinda las herramientas necesarias para tener claridad en tus objetivos desde el comienzo del
proyecto.
Al encontrar un problema, ofrece la oportunidad de detectar la fase del modelo en cascada en la que surgió y
así arreglarlo lo más rápido posible. Asismismo [Pérez 16], nos plantea que debido a que el método de
cascada requiere una amplio esfuerzo de preparación previa, permite:
• Comenzar con el software con bastante rapidez.
• Estimar calendarios y presupuestos con mayor precisión.
• Lograr un nivel de satisfacción del cliente más elevado que otros enfoques, ya desde el principio.
La metodología en cascada supera algunas de las limitaciones de otros métodos, como: A/ Scrum: los
procesos de desarrollo que siguen la metodología en cascada tienden a ser más seguro, ya que existe una
firme orientación al plan [Pérez 16]. Por ultimo [Ricardo 20] sugiere las siguientes ventajas:

• Adecuado para proyectos simples o pequeños.

• Los requisitos se entienden bien.
• Fácil de entender.
• Fácil de manejar.
• Hitos claros.
• Documentación extensa.

EF10: Un proceso, según describe [Munch 18] es el conjunto de pasos o etapas para llevar a cabo una
actividad. Par su parte [Benavides 14] menciona que un proceso es una forma sistemática de hacer las
cosas. Asimismo [Jacobs 21] indica que el proceso representa la secuencia básica de las pasos o actividades
con que la empresa concibe, diseña y lleva un producto al mercado. Finalmente [Etece 21] señala que un
proceso se refiere a la acci6n de ir hacia adelante, de avanzar en una trayectoria determinada y, par semejanza,
avanzar en el tiempo.
Según [Caracheo 02], las acepciones del concepto de modelo son muy diversas. Puede considerarse al
modelo, en términos generales, como representación de la realidad, explicación de un fenómeno, ideal digno
de imitarse, paradigma, canon, patrón o guía de acción; idealización de la realidad; arquetipo, prototipo, uno
entre una serie de objetos similares, un conjunto de elementos esenciales o los supuestos teóricos de un
sistema social. Por su parte, [Gago 99] menciona que un modelo es un Ejemplar o forma que uno propone
y sigue en la ejecución de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve para medir, explicar
e interpretar los rasgos y significados de las actividades agrupadas en las diversas disciplinas.
Asimismo, de acuerdo con [Achinstein 67] los modelos son construcciones mentales que permiten una
 aproximación a la realidad de un fenómeno, distinguiendo sus características para facilitar su comprensión.
El término modelo, en consecuencia, tiene una amplia gama de usos en las ciencias y puede referirse a casi
cualquier cosa, desde una maqueta hasta un conjunto de ideas abstractas. Finalmente [Flórez 99]
indica que un modelo es la imagen o representación del conjunto de relaciones que definen un fenómeno,
con miras a su mejor comprensión. Aunque difieren cualitativamente en cuanto a su valor explicativo, todos
los modelos comparten la característica de ser imágenes o representaciones construidas acerca de lo
que podría ser la multiplicidad de fenómenos o cosas observables reducidas a una raíz común que permita
captarlas como similares en su estructura o al menos en su funcionamiento.
El término latino praescribere se convirtió, en nuestra lengua, en prescribir. El concepto tiene varios
significados que varían de acuerdo al contexto. Por ejemplo, puede tratarse de la acción de indicar, decretar
o fijar algo, como se puede apreciar en los siguientes ejemplos: “Le voy a prescribir un jarabe para la tos”, “El
médico me prescribió unas pastillas para controlar la presión”, “El jefe va a prescribir la utilización de un
nuevo uniforme en la empresa”, así lo menciona [Gardey 13]. Por su parte [Raimundo 03], define prescribir
como Ordenar o mandar algo; también dejar de existir un derecho, una obligación o responsabilida.
Asimismo [Espasa 05] indica que p rescribir según es:
16.tr. Ordenar, determinar:
la ordenanza prescribe el pago inmediato de las multas.
17.Recetar el uso de un medicamento o remedio:
le han prescrito una cura de sueño.
Finalmente [Larousse 22], describe la palabra describir como:
• tr. Ordenar o determinar.
• tr.-prnl.dquirir[una cosa o derecho] por virtud de posesión continuada, o caducar un derecho por paso del
tiempo señalado a este efecto.
• Intr. Concluir o extinguirse una obligación o deuda por el transcurso de cierto tiempo.
• fig.Perderse o mermarse una cosa por el transcurso del tiempo.
• tr. med. Recetar [un tratamiento].

Rumbaugh 91] define los modelos de software como un proceso para producir software de forma
organizada, empleando una colección de técnicas y convenciones de notación predefinidas. Por otra parte,
[Piattini 04] menciona que es un conjunto de procedimientos, técnicas, herramientas y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software. Asimismo [Palvia 93] describe los
modelos como una aproximación organizada y sistemática para el ciclo de vida del sistema o sus partes.
Especifica las tareas individuales y sus secuencias. Finalmente [Sommerville 11] indica que un modelo de
proceso de software es una representación simplificada de este proceso. Cada modelo del proceso
representa a otro desde una particular perspectiva y, por lo tanto, ofrece solo información parcial acerca
de dicho proceso. En otras palabras los modelos de software son un conjunto de actividades organizadas
con el fin de desarrollar software.

Según [Pressman 10] los modelos de proceso prescriptivo fueron propuestos originalmente para poner
orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado
cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen al borde del caos. Por su parte [Murillo 18] menciona que los modelos del proceso prescriptivo
fueron desarrollados para ordenar la situación en caso de que exista un gran problema en el proyecto, en
este se definen un conjunto de actividades, acciones, tareas, hitos y demás trabajos que un equipo de
software debe realizar para construir sistemas de alta calidad. Asimismo [Fernández 20] indica que los
modelos prescriptivos son un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Proporcionan una guía útil para el
trabajo de la ingeniería del software. Por ultimo [Cruz 14] nos dice que estos modelos de proceso no
son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.[Kau 95]
menciona que el borde del caos es el estado natural entre el orden y el caos, un compromiso grande entre la
estructura y la sorpresa. Por su parte [Tercero 17] indica que debido a interconexión e interacción entre sus
múltiples elementos, a la retroalimentación y a la no-linealidad de sus relaciones, los sistemas complejos
adaptativos tienen la capacidad de balancearse entre el orden y el caos. Esta región de balance es llamada
 el Borde del Caos y es considerada como la zona de mayor creatividad de los sistemas. Asimismo [BBVA
18] nos dice que se trata de un espacio de transición entre el orden y el desorden, una región de
inestabilidad limitada, donde fuerzas progresivas y conservadoras luchan por el control. Por ultimo [Mercado
00], sugiere que introduce la idea de que el azar, las condiciones cambiantes y la creatividad pueden
introducirse en cualquier momento en un sistema complejo y alterar su curso.

El modelo de cascada toma las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución y, luego, los representa como fases separadas del proceso, tal como
especificación de requerimientos, diseño de software, implementación, pruebas, etcétera. Esto según
menciona [Sommerville 11]. Por otro lado [Pressman 10] describe que el modelo de cascada sugiere un
enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los
requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue,
para concluir con el apoyo del software terminado. [Pantaleo 15] plantea que es un modelo de desarrollo
lineal secuencial. El proyecto de software es dividido en fases que deben procesarse en forma secuencial.
Finalmente [Palacios 06] indica que este modelo refleja la necesidad impuesta por la realidad de retornar
con frecuencia desde una fase hacia las anteriores con la información generada al avanzar el desarrollo. En
otras palabras el método cascada separa el proyecto en fases secuenciales que satisface la necesidad de
retornar entre fases durante el desarrollo.

[Lucidchart 22] nos lista las siguientes ventajas del modelo de cascada:
▪ Usa una estructura clara. En comparación con otras metodologías, la cascada se concentra
mayormente en una serie de pasos claros y definidos.
▪ Determina el objetivo final rápidamente. Uno de los pasos definitorios del método de cascada es
comprometerse con un producto final, un objetivo o un entregable desde el principio, y los
equipos deberían evitar desviarse de ese compromiso.
Transmite bien la información. El enfoque de la cascada es sumamente metódico, así que no debería
resultar una sorpresa que la metodología enfatice una transferencia clara de información en cada paso.
Por su parte [Risso 22] hace mención de las siguientes ventajas del modelo de cascada:
• Te ayuda a llevar un orden y organizar tu trabajo.
• Es muy útil si no tienes demasiada experiencia.
• Funciona de manera óptima en la mayoría de los dispositivos.
• Es sencillo y fácil de seguir.
• Te brinda las herramientas necesarias para tener claridad en tus objetivos desde el comienzo del
proyecto.
Al encontrar un problema, ofrece la oportunidad de detectar la fase del modelo en cascada en la que surgió y
así arreglarlo lo más rápido posible. Asismismo [Pérez 16], nos plantea que debido a que el método de
cascada requiere una amplio esfuerzo de preparación previa, permite:
• Comenzar con el software con bastante rapidez.
• Estimar calendarios y presupuestos con mayor precisión.
• Lograr un nivel de satisfacción del cliente más elevado que otros enfoques, ya desde el principio.
La metodología en cascada supera algunas de las limitaciones de otros métodos, como: A/ Scrum: los
procesos de desarrollo que siguen la metodología en cascada tienden a ser más seguro, ya que existe una
firme orientación al plan. Por ultimo [Ricardo 20] sugiere las siguientes ventajas:

• Adecuado para proyectos simples o pequeños.

• Los requisitos se entienden bien.
• Fácil de entender.
• Fácil de manejar.
• Hitos claros.
• Documentación extensa.

[Lucidchart 22] nos lista las siguientes desventajas del modelo de cascada:

1. Dificulta los cambios

La metodología de la cascada se basa completamente en seguir una serie de pasos que hacen que los equipos
siempre avancen. Esta metodología, en su forma tradicional, no deja prácticamente ningún lugar para cambios o
revisiones imprevistos.
2. Excluye al cliente o al usuario final
Como proceso interno, el modelo de cascada se concentra muy poco en el usuario o el cliente final de un
proyecto. Su principal objeto siempre ha sido ayudar a que los equipos internos avancen más eficientemente por
las distintas fases del proyecto, lo que puede funcionar bien en el mundo del software.
3. Retrasa las pruebas hasta después de la finalización
Dejar la fase de pruebas para la última mitad de un proyecto es riesgoso, pero la metodología de cascada insiste
en que los equipos esperen hasta el paso cuatro de seis para probar sus productos.

Por su parte, [Risso 22] menciona las siguientes desventajas del modelo de cascada:
• Si estás realizando un proyecto grande o muy complejo, puede que sea más difícil dividirlo en fases
ordenadas, por lo que este sistema puede no ser el más adecuado.
• Debido a la forma de trabajo lineal, tienes menos tiempo para concluir cada una de las fases del modelo
en cascada.
• No puedes pasar a la etapa siguiente hasta que completes la anterior.
• En ocasiones, los fallos no se detectan hasta la última fase del desarrollo, por lo que, para resolverlo
tendrás que regresar a las fases anteriores y repetirlas o modificarlas.
Asimismo, [Pérez 16] describe este método como increíblemente rígido e inflexible, lo que plantea
inconvenientes como:
• Alterar el diseño del proyecto en cualquier etapa es muy complicado.
• Una vez que una fase se ha completado, es casi imposible de realizar cambios.
• Es absolutamente necesario reunir todos los requisitos iniciales.
• Resulta muy difícil responder a los problemas que puedan surgir, ya que tanto la retroalimentación, como
las pruebas se retrasan hasta estadios muy tardíos del desarrollo de proyecto.
• Solucionar cualquier cuestión que se plantee requiere una cantidad sustancial de tiempo, esfuerzo y
dinero.
Finalmente, [Ricardo 20] menciona las siguientes desventajas del modelo de cascada:
• No permite cambios de alcance.
• No permite cambios de requisitos.
• Ningún producto funcional hasta casi la finalización del proyecto.
• Incapaz de manejar fácilmente riesgos inesperados.
[Stsepanets 21] menciona que los gerentes de proyecto suelen recurrir al método de cascada cuando hay una
visión clara de lo que debería ser el producto final, cuando los clientes no tienen posibilidad de cambiar el
alcance del proyecto una vez que ha comenzado, cuando el concepto y la definición son las claves del éxito
(pero no la velocidad), cuando no hay requisitos ambiguos. Por su parte [Rasso 22] nos da los siguientes
ejemplos de uso que le han dado al modelo cascada:

1. Desarrollo de software para la industria automotriz.

2. Creación de sistemas de gestión de recursos humanos.
3. Diseño de sistemas de gestión de la cadena de suministros.
4. Avances en los sistemas de control de las instalaciones nucleares.
5. Estudios y proyectos sobre transbordadores espaciales.

Asimismo [Pérez 16] hace alusión a que la metodología en cascada no es ni mejor ni peor que otras, solo hay
que saber elegirla cuando resulta más conveniente su aplicación, en función del proyecto y sus necesidades. Y
esto sucede, por ejemplo, al enfrentarse a iniciativas estáticas, donde no es muy probable la introducción de
cambios se realizarán a lo largo del proceso de desarrollo o cuando se cuenta con equipos de trabajo de menor
experiencia, que pueden beneficiarse de una estructura más rígida, como la que propone este enfoque.
Finalmente [Openinnova 22], sugiere los siguientes puntos:
• Equipos que necesitan un cronograma de proyecto más predecible y secuencial. Además tienen un
presupuesto fijo.
• Equipos de proyectos con menos experiencia.
• Empresas con menor tolerancia al cambio o al riesgo.
• Empresas cuyos clientes están limitados por el tiempo, los recursos y además no pueden colaborar con
frecuencia.
• Proyectos sencillos con requisitos sencillos.
Proyectos que tienen el lujo de plazos más largos.
 RB REFERENCIAS BIBLIOGRÁFICAS

[BBVA 18] BBVA; Del caos al orden: cómo aplicar la teoría de la

complejidad en el trabajo; 2018;
https://www.bbva.com/es/caos-orden-aplicar-teoria-
complejidad-trabajo/

[García 18] García, F.; Ingenieria de software I; 2018; Universidad de

Salamanca;
https://repositorio.grial.eu/bitstream/grial/1150/1/5.%20IngR
eq.pdf

[Gómez 19] Gómez Fuentes, María del Carmen; Fundamentos de Ingeniería de

Software; 2019 Universidad Autónoma Metropolitana; México D.F;
http://www.cua.uam.mx/pdfs/conoce/libroselec/Fundamentos_Ing_SW-
VF.pdf

[Larousse 22] Larousse, Editorial; Gran diccionario de la Lengua Española;

2022; L.S; https://es.thefreedictionary.com/prescribir

[Lucidchart 22] Lucidchart; Modelo de cascada: Ventajas y desventajas; 2022;

https://es.thefreedictionary.com/prescribir

[Murillo 18] Murillo, Jeniffer; Modelos del proceso: Modelo prescriptivo; 2018;
https://jraquelm2.wixsite.com/ingenieriadesoftware/single-
post/2015/04/21/-tema-2-modelos-del-proceso-modelo-
prescriptivo

[Pantaleo 15] Guillermo Pantaleo; Ingeniería de Software; Universidad de Buenos Aires;

Alfaomega Grupo Editor 2015; Argentina;
https://books.google.com.mx/books?
id=a8j2DQAAQBAJ&printsec=frontcover&hl=es#v=onepage&q&f=false

[Pérez 16] Pérez, Anna; ¿Qué son las metodologías de desarrollo de software?;
2016; https://www.obsbusiness.school/blog/que-son-las-metodologias-
de-desarrollo-de- software

[Ricardo 20] Ricardo, Rodrigo; Modelo de cascada: ventajas y

desventajas; 2020; Estudyando;
https://blog.ganttpro.com/es/metodologia-de-cascada/

[Risso 22] Risso, Ignacio; Domina el modelo de cascada y potencia al

máximo tus proyectos de software; 2022; Crehana;
https://www.crehana.com/blog/desarrollo-web/modelo-en-
cascada/
 [Sommerville 11] Sommerville, Ian; Ingenieria en software; 2011;
https://sistemamid.com/panel/uploads/biblioteca/2018-06-11_03-37-
12144643.pdf

[Stesepanets 21] Stsepanets, Anastasia; Modelo cascada; 2021; Ganttpro;

https://blog.ganttpro.com/es/metodologia-de-cascada/

[Pressman 10] Pressman, Roger S; Ingeniería del software. Un enfoque

práctico ; 2010;
http://cotana.informatica.edu.bo/downloads/ld-
Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF