Universidad Politécnica de Tapachula

“innovación y tecnología al servicio de la sociedad”

Materia
Procesos de desarrollo de software

Nombre del alumno- Matricula

José Ángel Victorio Escobar

Catedrático

Rene servando Rivera Roblero

Cuatrimestre/ periodo escolar

Segundo cuatrimestre

Nombre de la practica o proyecto

Modelo de cascada ejemplos

Plan de estudios

Ingeniería en software
14/02/2022
Ejemplo numero 1

Las personas a las que les gusta el modelo en cascada lo llaman un proceso de
ingeniería de sistema de compuerta de etapa secuencial. Las personas que no les
gusta lo llaman cascada.

A muchos gerentes les gusta el modelo en cascada porque creen que les permite
minimizar el riesgo (riesgo personal, político y organizacional) al hacer que todos
firmen el alcance, el tiempo y el costo en cada etapa del proyecto. Los ingenieros
que trabajan y los desarrolladores de software generalmente no les gusta la
cascada porque es increíblemente frustrante y conduce a malos resultados.

Aquí hay un ejemplo de cómo se usa el modelo en cascada para construir

software en 2016. Estas etapas se muestran secuencialmente a menos que se
indique lo contrario.

• Estimación del proyecto (+/- 50%) y justificación comercial (4 semanas –

hoja de cálculo compleja + documento de 20 páginas – realizada por el
gerente comercial y el gerente del proyecto – generalmente basada en
vagos beneficios indirectos)
• Revisión de casos de negocios (4 semanas – reunión de revisión mensual
por ejecutivos y contadores – insistirá en beneficios comerciales más
directos y eliminará toda contingencia)
• Reprocesamiento y aprobación de casos de negocios (4 semanas – por el
gerente de negocios y el gerente de proyectos con la revisión y aprobación
del equipo ejecutivo – los beneficios son exagerados y las estimaciones
reducidas – el presupuesto es fijo)
• Requisitos (3 meses: documento de 80 a 100 páginas del equipo de
analistas de negocios que intenta racionalizar y priorizar una lista de deseos
masiva de requisitos de una amplia gama de partes interesadas sin tener
en cuenta el costo)
• Revisión de requisitos (2 semanas por partes interesadas)
• Reprocesamiento y aprobación de requisitos (2 semanas por parte de BA
con aprobación de SH; los requisitos son fijos)
• Arquitectura técnica (3 meses: documento de 80 páginas del equipo de
arquitectura de software que diseña una solución para cumplir con todos los
requisitos utilizando la última arquitectura de software disponible (porque el
último software es divertido) sin tener en cuenta el costo)
• Revisión de arquitectura técnica (2 semanas por partes interesadas y BA)
• Retrabajo y aprobación de la arquitectura técnica (2 semanas por
arquitectos con aprobación de SH – La arquitectura es fija y los arquitectos
tienen poco más que ver con el proyecto)
• Proyecto reestimado +/- 30% (4 semanas por el gerente de proyectos de
tecnología y el proveedor de software, realizado al mismo tiempo que el
diseño funcional)
• Bastidores de alambre de diseño funcional (2 meses: realizado por el
equipo de UX Design que diseña la solución funcional ideal para cumplir
con todos los requisitos, generalmente con poca comprensión de los
impactos técnicos o de costos del diseño)
• Revisión del diseño funcional y pruebas de usabilidad (2 a 4 semanas por
SH y usuarios)
• Diseño y aprobación del diseño funcional (2 semanas por UX Designer –
diseño funcional corregido)
• Diseño visual y guía de estilo (2 a 3 meses – por el equipo de diseño visual
que desarrolla el diseño visual ideal para entregar los marcos de acuerdo
con la guía de estilo de la marca sin comprender las implicaciones técnicas
o de costo)
• Pruebas de usabilidad y revisión de diseño (2 a 4 semanas por el gerente
de negocios y el diseñador de experiencia de usuario a veces prueban el
diseño con clientes reales en un laboratorio de usabilidad, pero
principalmente solo reciben comentarios de SH)
• Revisión y aprobación del diseño visual (2 a 4 semanas; el diseño visual y
la guía de estilo son fijos)
• Declaración de trabajo desarrollada para el equipo de desarrollo de
software externo (2 semanas por Tech PM, que solicita de uno a cinco
vendedores para proporcionar un precio fijo, alcance fijo, tiempo de
respuesta fijo para entregar el proyecto en un proceso de cascada cerrada
por etapas)
• Revisión y aprobación de la SOW (2 semanas por departamento de
compras: impulsarán un contrato tradicional de alcance fijo, precio fijo y
tiempo fijo con ofertas competitivas)
• Responda a SOW (2 a 3 semanas por proveedor – documento de 200
páginas – asume que todos los requisitos, el diseño y la arquitectura son
fijos – el proveedor pone un precio tan bajo como creen que puede con
tantas excepciones y suposiciones como sea posible – la estrategia es para
ganar el trabajo al igualar la oferta inicial y obtener ganancias con las
solicitudes de cambio)
• Revisiones de SOW (2 a 4 semanas por gerentes de proyecto y SH que
buscan la mejor relación calidad-precio)
• Negociación y aprobación de SOW (2 semanas – alcance y precio
reducidos – SH no informado de las reducciones de alcance – el proveedor
acepta el alcance, el tiempo y el costo “fijos”)
• Plan de prueba (2 meses: el administrador de pruebas redacta un plan de
prueba que define el proceso de prueba, las funciones de prueba y las
áreas funcionales que se probarán, que se realiza al mismo tiempo que el
proceso SOW)
• Revisión del plan de prueba (2 semanas por el PM – un ejercicio de
casillero en el que nadie está interesado)
• Reelaboración y aprobación del plan de prueba (2 semanas por el
Administrador de pruebas – El plan de prueba es fijo)
• Diseño técnico (2 meses por los líderes de desarrollo del proveedor, hecho
como un modelo de relación de entidad, incluye configuración técnica y
 talones de programa, el proveedor plantea solicitudes de cambio por
violación de supuestos y excepciones)
• Revisión del diseño técnico (2 semanas por colegas de Dev Lead – Los
arquitectos generalmente se niegan a involucrarse, algunos CR aceptaron
el aumento del tiempo y el costo del proyecto)
• Retrabajo y aprobación del diseño técnico (2 semanas por líderes de
desarrollo, no aprobado por el arquitecto que no quiere asumir ninguna
responsabilidad por la implementación de su arquitectura técnica)
• Proceso de control de cambios (de 2 a 4 semanas por el equipo del
proveedor: el proveedor plantea la solicitud de cambio cuando se viola
cualquiera de las suposiciones o exclusiones de SOW o se modifica el
alcance), el proveedor solicita fondos adicionales para analizar y pagar el
CR. cinco veces el costo real para obtener ganancias en el proyecto)
• Revisión de solicitud de cambio (2 semanas: la junta de control de cambios
revisa los CR cada dos semanas. El cliente y el proveedor discuten si el
cambio está dentro del alcance o no. El proveedor se niega a hacer el
trabajo hasta que se proporcione el tiempo y el presupuesto adicionales).
• Modificación y aprobación de la solicitud de cambio (2 semanas – CR
simplificado para reducir costos. Vuelve a otro CCB para su aprobación. La
mayoría de los CR finalmente se aprueban)
• Casos de prueba (3 meses: el equipo de prueba escribe múltiples pruebas
funcionales y de integración para cada requisito funcional; produce una
matriz de capacidad de rastreo de requisitos y casos de prueba en la
herramienta de prueba, realizada al mismo tiempo que el diseño técnico y el
desarrollo de software)
• Revisión del caso de prueba (2 semanas por el administrador de prueba
para verificar que todos los requisitos tengan pruebas)
• Aprobación de caso de prueba (2 semanas por el administrador de prueba
– Casos de prueba corregidos)
• Desarrollo de software (6 meses planeados – 9 a 12 meses reales –
realizado por el equipo de desarrollo de software del proveedor en India con
un pequeño equipo local de tecnología líder – el equipo de desarrollo
intenta construir lo que se ha especificado y diseñado, incluso si no tiene
ningún sentido No funciona: este es un agujero negro para los PM del
cliente y las partes interesadas que no tienen idea de lo que está
sucediendo: el proveedor eleva los CR por violaciones de suposiciones)
• Pruebas de software (1 mes planificado – 3 a 6 meses reales – el equipo de
software entrega el software “completado” al equipo de prueba tarde – los
evaluadores descubren la funcionalidad faltante y cientos o miles de
defectos mayores y menores)
• Retrabajo de software (1 mes planificado – 3 a 18 meses real – el
proveedor trabaja heroicamente para corregir defectos – el proveedor se da
cuenta de que su estimación era incorrecta y plantea muchas solicitudes de
cambio para todo lo que se les ocurre – el equipo del proyecto se da cuenta
de que los requisitos, la arquitectura y los requisitos “fijos” el diseño es
incorrecto – muchos conflictos con el equipo del cliente – aumento de
tiempo y costo del proyecto – reemplazo de PM de empresas y proveedores
 – proyecto cancelado o alcance reducido y el tiempo y costo del proyecto
aumentaron sustancialmente)
• Pruebas de aceptación del usuario (2 semanas planificadas – 1 a 3 meses
reales – expertos en la materia de negocios prueban el software por
primera vez – descubren que el sistema es muy difícil de usar, le faltan
funciones importantes, es demasiado complejo en muchas áreas y tiene
cientos de pequeños defectos. Todos se dan cuenta de que nadie
realmente entendió lo que se requería hasta que realmente comenzaron a
usar el software)
• Retrabajo UAT (2 semanas planificadas – 4 semanas a 6 meses reales – el
proveedor plantea una gran cantidad de solicitudes de cambio – proyecto
cancelado o alcance reducido y tiempo y costo del proyecto aumentados
sustancialmente)
• Pruebas de rendimiento (2 semanas planificadas – 4 semanas a 3 meses
reales – un equipo de pruebas de rendimiento especializado simula grandes
cantidades de transacciones simultáneas de usuarios para ver si se
cumplen los requisitos no funcionales)
• Retrabajo de rendimiento (1 semana planificada – 1 a 3 meses real – el
equipo de software del proveedor realiza cambios importantes en el diseño
técnico para entregar el rendimiento esperado – el proveedor eleva los CR
– proyecto cancelado o alcance reducido y el tiempo y costo del proyecto
aumentaron sustancialmente)
• Paquete final de implementación de software creado y probado (1 semana)
• Software implementado (planificado 1 día; el equipo puede tener que
esperar de 1 a 3 meses para una ventana de implementación empresarial;
los ejecutivos celebran su éxito)
• Soporte de software (planeado para que el equipo central de software
brinde soporte durante un mes, en realidad de 3 a 6 meses; los usuarios se
quejan de una gran cantidad de problemas con el nuevo software; el equipo
central de desarrollo de software trabaja heroicamente para solucionarlos
en base a tiempo y materiales – los costos del proyecto continúan
aumentando)

Al final del día, el proyecto lleva de 3 a 5 años de principio a fin y cuesta el doble y
dura el doble de lo esperado.

Por cierto, el modelo Waterfall para el desarrollo de software se atribuye

erróneamente a Winston Royce.
Ejemplo numero 2

Si un equipo desarrollara una libreta de direcciones de clientes utilizando la

metodología Cascada, el orden de trabajo sería el siguiente (los plazos son solo
para fines de demostración):

Análisis.

El Jefe del Proyecto se reúne con el cliente. El método de educción de requisitos

elegido es “la entrevista”. Se crea el documento con la información recabada que
permitirá a los Analistas de Requerimientos determinar los requerimientos
relevantes que facilitarán el correcto desarrollo del software.

El Equipo de Analistas deducen los siguientes requerimientos:

• El sistema deberá permitir crear nuevos contactos.

• El sistema deberá permitir listar contactos.

• El sistema deberá permitir modificar contactos.

• El sistema deberá permitir eliminar contactos.

Marco de tiempo: 2 semanas.

Diseño.

El Equipo de Desarrolladores crea un diseño de funcionalidad; que incluye modelo

de datos, diagramas de casos de uso y de clases. Herramienta utilizada: Enterprise
Architect.
Diagrama Entidad-Relación

Diagrama de Casos de Uso

Diagrama de Clases

Marco de tiempo: 2 semanas

Creación de código.

El Equipo de Desarrolladores desarrolla la funcionalidad y la prepara para las

pruebas.

Interfaz de Usuario
Marco de tiempo: 1 semana.

Pruebas.

El Equipo del Pruebas prueba toda la funcionalidad.

Marco de tiempo: 2 semanas.

Lanzamiento.

La funcionalidad del producto es lanzada.

TOTAL del tiempo transcurrido: 7 semanas.