… obedece a la mala adaptación de la planeación predictiva al desarrollo de software
Salvo excepciones, el modelo en cascada no funciona bien en el desarrollo de software
El modelo en cascada ……
En este modelo, se aborda una secuencia definitiva de eventos, tal cual se hace en la planeación predictiva
Requerimientos
Análisis y diseño
Codificación
Pruebas
Diseño detallado
Operaciones
Lo cual normalmente no funciona …..
Integración en etapas finales y problemas tardíos de diseño
Mucho re trabajo
Software que no satisface las necesidades de clientes y usuarios
Y conduce a …
Sobre costos, proyectos muy demorados en el tiempo, baja calidad. En general, proyectos impredecibles.
Foco en documentos y reuniones formales de diseño (IWKIWISI). Quizá por esta razón se habla que las aproximaciones basadas en planes producen muchos documentos
Insatisfacción generalizada de los interesados (Cliente, usuarios, grupo de ingeniería, proveedor del software, etc.)
Etcétera
Pérdida de dinero (sobre costos, necesidad
del producto, etc.)
Cuestionamiento al grupo de ingeniería (interno
o externo)
Abordar el problema incorrecto
Hoy en día no triunfan las empresas mas poderosas económicamente, lo hacen las más rápidas y más innovadoras
Lo que significa ….
El desarrollo es cascada, que se le atribuye a Royce [1970], tuvo una gran influencia, sobre todo a partir de las necesidades de la ingeniería de sistemas, no la ingeniería de software (Royce realmente pregonó el desarrollo iterativo)
El desarrollo en cascada es fácil de explicar. El iterativo e incremental es mas complejo
Por qué se persiste en un modelo que no funciona?
“Para cada problema complejo, existe una solución simple, ordenada e incorrecta” (Mencken). Ejemplos: La tierra es plana, todo gira alrededor de la tierra, la creación del hombre, etc.
Puede dar la ilusión , en algunas personas, de un proceso ordenado, predecible y medible
Por qué se persiste en un modelo que no funciona?
Porque no se quiere hacer el esfuerzo para buscar otras formas de hacerlo
Por presión de compradores, la cual a su vez proviene de los CEO, CIO, etc. “Cuánto se demora”, “Cuánto vale”, etc.
Por la legislación de compras de los gobiernos
Porque la Ingeniería de Software no es fácil, aunque no es para seres especiales
Todas las aproximaciones Ágiles
son un subconjunto de las aproximaciones Iterativas
La respuesta a los problemas de la aproximación en cascada y basadas en documentos son las aproximaciones denominadas Ágiles
XP (eXtreme Programming)
Scrum
UP (o su versión RUP)
ASD (Adaptive Software Development)
Crystal
Evo (como referencia)
Las aproximaciones iterativas mas conocidas son …
Una aproximación para construir software (o cualquier cosa), en la cual el ciclo de vida se descompone en varias iteraciones en secuencia. Cada iteración es un mini – proyecto autocontenido
El desarrollo Iterativo es …
Liberar un sistema parcialmente completo, probado, integrado y estable.
Algunas iteraciones son internas, otras se liberan a operaciones.
El objetivo de cada iteración consiste en …
IID no es nuevo …
IBM publicó en 1972 documentos que contenían esta aproximación
Los japoneses utilizaron IID para el desarrollo de nuevos productos en electrónica de consumo, vehículos, etc.
EVO (Evolutionary Project Management) data de los años 60.
Alexander Proudfoot aplicó a fines de los 40, lo que el denominó el SIS (Short Interval Scheduling) en una compañía de correo masivo en Chicago
Las nuevas aproximaciones están basadas en ideas ya viejas
Iterativo e Incremental significa …
Iteración 1
Iteración 2
Iteración 3
Feedback
Feedback
Release 1
Iteración 4
Iteración 5
Iteración 6
Feedback
Feedback
Release 2
La longitud de cada iteración es de 1 a 6 semanas como máximo
La planeación de iteraciones contiene elementos diferentes a la aproximación tradicional …
Planeación basada en el riesgo o en el cliente
El tiempo de cada iteración es fijo, pase lo que pase (timeboxing)
No se aceptan cambios de interesados externos
No se hacen cronogramas en su forma tradicional
Se trabaja en varias disciplinas simultáneamente aunque el énfasis cambia (requerimientos, análisis, diseño, codificación, testing, etc.)
El cono de incertidumbre se va estrechando a medida que avanza el proyecto
Estimados y cronogramas
prematuramente definidos
Período realista
para estimados
X
4X
0.1 X
I 1
I 2
Aunque el IID es la base, las aproximaciones ágiles adoptan otra serie de paradigmas …
Manifiesto Ágil
Individuos y sus interacciones sobre procesos y
herramientas
Software sobre documentación comprensiva
Colaboración del cliente sobre contratos
Respuesta a los cambios sobre el seguimiento de
un plan
Enfatiza mas sobre las posturas a la izquierda de sobre
Y aproximaciones metodológicas diferentes …..
Y aproximaciones metodológicas diferentes …..
Paradójicamente, XP y SCRUM son quizá las aproximaciones mas disciplinadas que existen, y requieren de mucho talento en los integrantes del grupo.
Se resquebrajan fácilmente sin disciplina y talento …
… y pueden presentar problemas serios
El conocimiento tácito promueve la agilidad, pero presenta serios problemas de escalamiento cuando el grupo crece o no tiene el talento
Se requieren personas muy talentosas
El diseño simple (YAGNI) puede llegar a ser muy riesgoso y costoso, en proyectos de alguna importancia donde pueda preverse el cambio.
El Peer Review ha mostrado mejores resultados que el Pair Programming
La carencia de procesos definidos puede llevar al caos. Es muy disciplinado y controlado el desarrollo (“Chaordic”).
… y puede presentar problemas serios
Es útil en grupos pequeños, requerimientos cambiantes o desconocidos
Vamos a cambiar otra vez el plan?
“Yo no le puedo dar mantenimiento a eso, no existe documentación de ninguna naturaleza”
Balance entre adaptación y optimización (*)
Liviana
Pesada
Bajo
Alto
Habilidades, conocimiento
Procesos, documentación
(*) Tomado de Cockburn y Highsmith
La solución ha consistido en introducir elementos basados en el plan
Mejor definición de milestones para evitar “acabar sin acabar”
Planes que abarquen la definición y prueba de arquitectura
Mejor elicitación de requerimientos, cuando es posible
Utilización de patrones de diseño y soluciones de arquitectura en lugar de YAGNI
Procesos definidos pero no mecánicos. Métodos formales de monitoreo (CEP)
Crystal y RUP son buenos ejemplos de aproximaciones mixtas
Seleccione su aproximación basado en el riesgo
No se vuelva un defensor a ultranza de una u otra aproximación. Al fin y al cabo usted lo que requiere es:
Producir software de buena calidad, que cumpla
los requerimientos de su cliente
Estar en capacidad de mantenerlo y evolucionarlo
No ser persona dependiente
No insista en lo que no funciona, eso solo lo conducirá al caos
 Página anterior | Volver al principio del trabajo | Página siguiente  |