Desarrollo de software. Ciclo de vida clásico o en cascada
Este enfoque del desarrollo de software ha sido el más utilizado y en la actualidad, pese a la aparición de metodologías ágiles, sigue siendo la solución predominante, si bien, en cada organización o en cada de proyecto se puede llevar a cabo con ciertas variantes.
Además, en función del autor, las fases en que se divide el ciclo de vida clásico, pueden ser diferentes. Para este artículo voy a utilizar las que estableció Roger Pressman (no obstante para la descripción del alcance de las mismas voy a basarme principalmente en Métrica V.3, pero adaptándome a esta clasificación), si bien otras muchas alternativas podrían ser válidas:
– Análisis: Esta fase comprendería desde la posible obtención de unos objetivos o requisitos iniciales para determinar la viabilidad del sistema y escrutar las distintas alternativas de solución, pasando por la elaboración del catálogo de requisitos, hasta la realización de casos de uso, prototipado de pantallas e informes, como una primera especificación del plan de pruebas.
– Diseño: El análisis describe el sistema sin entrar en características propias de la implementación, es en esta fase donde se adapta ese análisis generalista a la solución concreta que se quiere llevar a cabo, definiéndose la arquitectura general del sistema de información, su división en subsistemas de diseño, el modelo de datos lógico, el modelo de clases (en el caso de un diseño orientado a objetos), la especificación detallada del plan de pruebas, etc…
– Codificación: En esta fase se realiza la construcción del sistema de información y las pruebas relacionadas con dicho proceso, como son las unitarias, integración y de sistema, así como otras actividades propias de las etapas finales de un desarrollo como es la realización de la carga inicial de datos (si bien en muchos casos se deja esto para cuando el producto está en producción) y/o la construcción del procedimiento de migración.
– Pruebas: En esta etapa se realizaría la instalación del sistema en un entorno de pruebas lo más parecido posible al de producción (entorno de preproducción) donde se realizarían las pruebas de implantación (que verifican principalmente aspectos no funcionales) y las de aceptación, donde los usuarios validan que el sistema hace lo que realmente esperaban (sin que se deba olvidar que los límites los establecen los modelos realizados previamente y que han debido ser validados). Por último se realizaría la implantación del sistema en el entorno de producción.
– Mantenimiento: Una vez que el sistema se encuentra en producción, se realizarán sobre el mismo diversas tareas de mantenimiento, que en función de su naturaleza se clasifican en correctivos, evolutivos, adaptativos y perfectivos. Estas tareas de mantenimiento serán consecuencia de incidencias y peticiones reportadas por los usuarios y los directores usuarios.
En el ciclo de vida clásico en función de las modificaciones y/o correcciones que se realizan en una etapa será necesario la vuelta a fases previas para hacer coherente el proceso de desarrollo y los modelos.
El principal inconveniente que se le ha achacado siempre a este tipo de ciclo de vida es que los usuarios tardan demasiado en ver los resultados, lo que hace que el tiempo transcurrido desde que se define el sistema hasta que está disponible sea lo suficientemente amplio como para que hayan ocurrido muchas cosas: desde que no estén la mayoría de las personas que participaron en la especificación, como cambios en los procesos, cambios de criterio, etc…, lo que provoca a hacer replantemiento de los requisitos en etapas más tardías del desarrollo con el coste que eso conlleva (un refinamiento de los requisitos es razonable siempre y cuando no se superen unos límites) y a que muy probablemente el sistema finalmente disponible esté alejado de lo que realmente quiere el conjunto de usuarios en estos momentos que es distinto a lo que querían hace meses y a lo que querrán dentro de otros tantos.
Otro inconveniente ligado con el anterior es que al tratarse el sistema como un todo, los modelos generados (catálogo de requisitos, casos de uso, etc…) serán lo suficientemente grandes como para no poder ser revisados y comprendidos en toda su magnitud, sobre todo por personal no informático. Esto crea una incertidumbre sobre los requisitos del sistema que más adelante traerá problemas.
No todo es malo en este modelo, ya que describe un procedimiento racional y ordenado de desarrollo de software, la clave para su éxito o su fracaso es como se gobierne el mismo y las circunstancias que rodeen al proyecto en el momento de su ejecución. Además, existen variantes que ofrecen una mayor flexibilidad al mismo y que permite reducir sus riesgos.
Pingback: La crisis del ciclo de vida en cascada « Jummp's Blog
Pingback: Damnificados por el ciclo de vida clásico o en cascada « Jummp
Pingback: Desarrollo de software. Ciclo de vida RUP (Rational Unified Process) « Jummp
Pingback: Desarrollo de software. Sin miedo a proponer e implementar soluciones « Jummp
Pingback: Desarrollo de software. Ciclo de vida en cascada o clásico y otros modelos centrados en la documentación « Jummp
Pingback: Desarrollo de software. Evolucionar o rehacer funcionalidades no es perder el tiempo « Jummp
Pingback: Desarrollo de software. Integración continua « Jummp
Pingback: Desarrollo de software. David Lorge Parnas. Feedback, adaptación y satisfacción del usuario. « Jummp
Pingback: Desarrollo de software. David Lorge Parnas. Predecibilidad y adaptación « Jummp
Pingback: Desarrollo de software. Planificación. Conservar la ventaja « Jummp
Pingback: Desarrollo de software. Pruebas de aceptación « Jummp
Pingback: Desarrollo de software. Exceso de frentes abiertos « Jummp
Pingback: Desarrollo de software. Delimitar el alcance del proyecto « Jummp
Pingback: Desarrollo de software. Testing. Modelo en V « Jummp
Pingback: Desarrollo de software. Usuarios, producto, evolución « Jummp
Pingback: Desarrollo de software. Objetivos generales sobre intereses particulares de los equipos « Jummp
Pingback: Desarrollo de software. El inicio del proyecto no es la programación « Jummp
Pingback: Desarrollo de software. Ciclo de vida en cascada. Lo de siempre « Jummp
Pingback: Desarrollo de software. Barry Boehm. Detección temprana de errores « Jummp
Pingback: Desarrollo de software. Lo clásico « Jummp
Pingback: Desarrollo de software. Ciclo de vida en cascada vs Metodologías ágiles « Jummp
Pingback: Desarrollo de software. Ciclo de vida en cascada. La larga travesía en el desierto « Jummp
Pingback: Desarrollo de software. Daniel McCracken. Michael Anthony Jackson. Requisitos y el cambio de percepción del usuario en el proceso de desarrollo « Jummp
Pingback: Desarrollo de software. ¿De verdad que tenemos en cuenta la incertidumbre y riesgos inherentes a un proyecto? « Jummp
Pingback: Desarrollo de software. El prototipado no es el antídoto a los problemas del ciclo de vida en cascada « Jummp
Pingback: Desarrollo de software. Plan de sistemas de información ágil « Jummp
Pingback: Desarrollo de software. Crisis, problemas, asumir decisiones, mirar adelante « Jummp
Pingback: Desarrollo de software. Sun Tzu. La importancia de ir liberando versiones operativas cuanto antes « Jummp
Pingback: Desarrollo de software. Ciclo de vida en cascada. Puertas abiertas o cerradas. « Jummp
Pingback: Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología « Jummp
Pingback: Desarrollo de software. Avance del proyecto y expectativas « Jummp
Pingback: Desarrollo de software. Cascada y sin dinero para el mantenimiento « Jummp
Pingback: Desarrollo de software. Antipatrón. Simulacro de incendio « Jummp
Pingback: Desarrollo de software. Antipatrón. Ingeniería de diapositivas « Jummp
Pingback: Desarrollo de software. Enfoques iterativos incrementales y el concepto de proyecto, ¿conflicto? « Jummp
Pingback: Desarrollo de software. Contratación ágil II « Jummp
Pingback: Desarrollo de software. La evolución en el enfoque del proceso de desarrollo « Jummp
Pingback: Desarrollo de software. La agilidad es un paraguas en la tormenta « Jummp
Pingback: Desarrollo de software. Metodologías ágiles y sistemas que requieren una documentación exhaustiva « Jummp
Pingback: Desarrollo de software. Productividad y experiencia de usuario « Jummp
Pingback: Desarrollo de software. Feedback y expectativas « Jummp
Pingback: Agilidad y descubrimiento « Jummp
Pingback: El cambio no solo es provocado por nuevos contextos « Jummp
Pingback: Joel Spolsky. La importancia del paso a producción del producto « Jummp
Pingback: Mike Cohn. Enfoque clásico vs Enfoque evolutivo « Jummp
Pingback: Ken Schwaber. Software que funciona, métricas y desarrollo en cascada « Jummp
Pingback: Desarrollo de software. ¿No son adecuados los desarrollos iterativos incrementales para proyectos críticos? « Jummp
Pingback: Agilidad y documentación « Jummp
Pingback: Desarrollo de software. La dificultad de salir del enfoque clásico « Jummp
Pingback: Desarrollo de software. La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas II « Jummp
Pingback: Desarrollo de software. Estimaciones y proyecto « Jummp
Pingback: Desarrollo de software. Antipatrón. Síndrome de la última versión « Jummp
Pingback: Desarrollo de software. Antipatrón. Alcance incremental « Jummp
Pingback: Desarrollo de software. Requisitos detallados o visión del producto « Jummp
Pingback: Desarrollo de software. Antipatrón. El culto a la agenda « Jummp
Pingback: Los 25 artículos más leídos de mi blog III « Jummp
Pingback: Steven Wright. La experiencia suele llegar tarde a la primera cita « Jummp
Pingback: Desarrollo de software. Antipatrón. Modelo en avalancha « Jummp
Pingback: Diferencia entre el ciclo de vida iterativo y el ciclo de vida iterativo incremental « Jummp
Pingback: Peter Drucker. Planificación e incertidumbre « Jummp
Pingback: Desarrollo de software. Antipatrón. Desarrollo a la primera « Jummp
Pingback: Desarrollo de software. Bienvenida a los cambios incluso en etapas tardías « Jummp
Pingback: Desarrollo de software. La visión del producto es necesaria pero no requiere una especificación detallada del sistema « Jummp
Pingback: Desarrollo de software. Modelos predictivos o cómo gestionar el desgaste I | Jummp
Pingback: Desarrollo de software. Modelos predictivos o cómo gestionar el desgaste V | Jummp
Pingback: El product owner o responsable funcional es clave | Jummp
Pingback: Desarrollo de software. Sprints e implicación | Jummp
Pingback: Desarrollo de software. ¿Qué es un proyecto? | Jummp
Pingback: Desarrollo de software. Evitar la complejidad. Tratamiento a diferentes escalas. | Jummp
Pingback: Desarrollo de software. ¿Es el enfoque iterativo incremental una sucesión de cascadas? | Jummp
Pingback: Desarrollo de software. Limitar el valor no debe ser el objetivo | Jummp
Pingback: El analista y los proyectos ágiles | Jummp
Pingback: El analista y los proyectos ágiles | StackPointerBlog
Pingback: Desarrollo de software. El daño de los tiempos de espera | Jummp
Pingback: Ley de Gall II | Jummp
Pingback: Aplicar prácticas ágiles no convierte a tu proyecto en ágil | Jummp
Pingback: Aplicar prácticas ágiles no convierte a tu proyecto en ágil | StackPointerBlog
Pingback: Calidad del software y valor III | Jummp
Pingback: Parece que los enfoques ágiles siempre tienen que estar justificándose | Jummp
Pingback: La estrategia o metodología de desarrollo no te ofrece una solución | Jummp
Pingback: La estrategia o metodología de desarrollo no te ofrece una solución | StackPointerBlog
Pingback: Lao-Tsé. Construir desde lo simple | Jummp
Pingback: Los enfoques ágiles requieren más intensidad | Jummp
Pingback: Escapar de la llave en mano, ¿quién asume el riesgo? | Jummp
Pingback: Desarrollo de software. Muy probablemente las condiciones iniciales van a cambiar | Jummp
Pingback: Asimilar la agilidad I | Jummp
Pingback: Los 25 artículos más leídos de mi blog IV | Jummp
Pingback: Desarrollo de software. La descomposición en tareas más simples y los enfoques ágiles | Jummp
Pingback: Desarrollo de software. ¿Existe el control del proyecto? III | Jummp
Pingback: Desarrollo de software. Predicción e incertidumbre | Jummp