Fases y Metodologías Clave en el Desarrollo de Software: De la Iniciación al Cierre

Interacción entre las Fases de un Proyecto

Las fases típicas de un proyecto incluyen:

Iniciación
Planificación
Ejecución
Control
Cierre

Consideraciones de Software: ¿Comprar o Desarrollar?

Al abordar las necesidades de software, una decisión crucial es si adquirir una solución existente o desarrollar una a medida. Factores a considerar:

Filosofía empresarial: ¿Cómo encaja la decisión con la estrategia general de la empresa?
Cobertura funcional: Se recomienda adquirir aplicaciones que cubran al menos el 70% de los requerimientos funcionales.
Tiempo de desarrollo: Evitar tiempos de desarrollo superiores a 18 meses o dos años para soluciones a medida.
Prácticas del sector: Comprar generalmente implica adquirir productos con funcionalidades genéricas basadas en las mejores prácticas comunes del sector.

Características Clave en la Decisión

Necesidades: Identificar las necesidades verdaderamente indispensables y determinar los rasgos más importantes del software requerido.
Recursos: Examinar críticamente los recursos disponibles: tiempo, personal y presupuesto financiero.
Unicidad: ¿Qué tan únicos son los requerimientos? ¿Existen soluciones estándar que los cubran?
Soporte: Considerar el soporte a largo plazo, tanto para software comprado como desarrollado.

Características Inherentes del Software

No se desgasta ni envejece físicamente, por lo que no requiere reparaciones ocasionales como el hardware.
Su duplicación es económica; el costo principal reside en el desarrollo inicial.
Puede ser modificado fácilmente, lo que hace necesario un estricto control de versiones.

Ciclo de Vida del Software

El ciclo de vida del software es el conjunto de fases por las que pasa un sistema desde que se inicia su desarrollo hasta que es retirado o reemplazado. Consiste en determinar:

El orden de las fases del proceso de desarrollo.
Los criterios de transición para pasar de una fase a otra.
Las entradas y salidas definidas para cada fase.

DEVELOPMENT >> USE >> MODIFICATION

Fases Típicas de Desarrollo

Un ciclo de vida de desarrollo comúnmente incluye:

PLANIFICACIÓN >> ANÁLISIS >> DISEÑO >> IMPLEMENTACIÓN >> PRUEBAS (TESTING)

Métodos Tradicionales de Desarrollo

Modelo en Cascada

Es una visión del proceso de desarrollo de software como una sucesión lineal de etapas que producen productos intermedios.

Características

Es el modelo más tradicional y, en el pasado, el más utilizado.
Para que el proyecto tenga éxito, deben completarse todas las fases secuencialmente.
Las fases continúan hasta que los objetivos de esa etapa se han cumplido.
Se asume que cambiar el orden de las fases resultará en un producto final de inferior calidad.

Limitaciones

No permite fácilmente las iteraciones o volver a fases anteriores.
Los requisitos tienden a congelarse al principio del proyecto, dificultando la adaptación a cambios.
No existe un entregable funcional hasta el final del proyecto.
No refleja fielmente el proceso real de desarrollo de software, que suele ser más iterativo.
Puede tardar mucho tiempo en completar todo el ciclo.
La comunicación con el usuario final es mínima después de la fase inicial de requisitos.
El mantenimiento se realiza sobre el código fuente final, sin integrar feedback temprano.
Las revisiones de proyectos de gran complejidad son muy difíciles bajo este esquema rígido.

Modelo de Proceso en Espiral

Introduce el análisis de riesgo como elemento fundamental para guiar la evolución del proceso de desarrollo. En la dimensión radial se representa el esfuerzo realizado (siempre creciente).

Cada iteración consta de 4 fases:

PLANIFICACIÓN: Determina qué parte del desarrollo se abordará en ese ciclo.
ANÁLISIS DE RIESGO: Evalúa diferentes alternativas para esa parte del desarrollo, seleccionando la más ventajosa y tomando precauciones para evitar posibles inconvenientes.
INGENIERÍA: Se realizan las actividades de desarrollo (análisis, diseño, implementación, pruebas) como en los modelos clásicos.
EVALUACIÓN: Se analizan los resultados de la fase de ingeniería y se planifica la siguiente iteración.

RUP (Rational Unified Process)

Es un proceso de desarrollo de software que, en conjunto con UML (Lenguaje Unificado de Modelado), constituye una metodología estándar ampliamente utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Métodos Ágiles

Manifiesto Ágil

«Estamos poniendo al descubierto formas mejores de desarrollo de software, haciéndolo y ayudando a otros a que lo hagan. A través de este trabajo hemos llegado a valorar:

Individuos e interacciones sobre procesos y herramientas.
Software que funciona sobre documentación exhaustiva.
Colaboración con el cliente sobre negociación contractual.
Respuesta ante el cambio sobre seguir un plan.»

Desarrollo Evolutivo

Problemas

Los sistemas a menudo pueden resultar pobremente estructurados si no se gestionan adecuadamente.
Puede ser necesario contar con habilidades especiales (por ejemplo, lenguajes para prototipos rápidos).

Aplicabilidad

Para sistemas interactivos pequeños o de mediano tamaño.
Para partes específicas de sistemas grandes (por ejemplo, la interfaz de usuario).
Para sistemas de corta vida útil.

XP (Programación Extrema)

Método ágil basado en cuatro valores fundamentales:

Simplicidad
Comunicación
Retroalimentación (Feedback)
Valor (Coraje/Valentía en versiones posteriores)

Prácticas Asociadas en XP

Programación en Pares (Pair Programming)

Todo el código es escrito por parejas de programadores en una sola máquina, con un teclado y un ratón.
No consiste en un programador trabajando y el otro simplemente mirando.
No es una sesión de aprendizaje unidireccional para un programador junior.
El programador que no está escribiendo activamente piensa de forma más estratégica y revisa el código en tiempo real.
Los roles (conductor/navegador) pueden cambiarse varias veces durante el día.
Fundamentos: Se basa en que dos programadores trabajando juntos son más efectivos que por separado, el conocimiento grupal crece más rápido y trabajar en equipo es más motivador.

Ritmo Sostenible (40 Horas Semanales)

El desarrollo de software es un ejercicio creativo; es crucial estar fresco y descansado.
Evitar la cultura de los «héroes» que trabajan horas excesivas.
Se busca reducir la rotación de personal.
Mejora la calidad del producto al evitar errores por cansancio.
Se permiten excepciones puntuales, pero más de una semana seguida de horas extra indica un problema subyacente.

Lugar de Trabajo Abierto

Idealmente, una sala amplia, preferiblemente sin divisiones.
Al centro: puestos para la programación en pares.
En la periferia: máquinas individuales para otras tareas.
Ventajas del espacio abierto: Mayor comunicación, facilita una agenda dinámica, etc.

Scrum

Scrum no es una metodología de desarrollo completa por sí misma, sino un marco de trabajo (framework) que complementa otras metodologías (como XP, MSF, RUP).

Enfatiza valores y prácticas de gestión de proyectos, más que cuestiones técnicas específicas de desarrollo.

Equipos auto-dirigidos y auto-organizados: No hay un manager que asigne tareas o decida cómo hacerlas. No existen títulos jerárquicos más allá de «Miembro del Equipo» (o «Cerdos», implicados directamente). La excepción es el Scrum Master, que facilita el proceso, elimina impedimentos y protege al equipo (idealmente con experiencia técnica, pero no es un jefe). Los observadores externos se denominan «Gallinas» (pueden observar, pero no interferir).
Sprint Backlog Fijo: Una vez elegida una tarea para un Sprint, no se agrega trabajo extra. Si algo urgente debe incluirse, se recomienda quitar otra tarea de alcance similar.
Daily Scrum (Reunión Diaria): Encuentros diarios (normalmente 15 minutos) con las tres preguntas clave: ¿Qué hice ayer? ¿Qué haré hoy? ¿Qué impedimentos tengo? Se realizan siempre en el mismo lugar, en círculo y de pie para fomentar la brevedad.
Iteraciones Fijas (Sprints): Iteraciones de duración fija, comúnmente de 1 a 4 semanas (el texto original menciona treinta días).
Sprint Review: Demostración del incremento de producto funcional a los stakeholders (participantes externos) al final de cada iteración.
Sprint Planning: Al principio de cada iteración, se realiza una planificación adaptativa guiada por el Product Owner (representante del cliente/negocio).

Prácticas Adicionales de Scrum

Al final de cada iteración (Sprint), hay una demostración (Sprint Review) a cargo del equipo, facilitada por el Scrum Master.
Las presentaciones en PowerPoint suelen desaconsejarse en favor de mostrar software funcionando. En los encuentros diarios, las «gallinas» deben estar fuera del círculo.
Se valora la puntualidad; algunas implementaciones establecen «multas» simbólicas (por ejemplo, para caridad) por llegar tarde.
Es permitido usar artefactos de las metodologías que Scrum complemente (ej. Listas de Riesgos si se usa con UP, Planguage si se usa con Evo, Planes de Proyecto de MSF).
No es compatible con instrumentos de planificación predictiva detallada como diagramas PERT, ya que parten del supuesto de que todas las tareas se pueden identificar y ordenar de antemano.
El supuesto dominante en Scrum es que el desarrollo es inherentemente complejo, cambiante y tiene demasiado «ruido» como para aplicarle un proceso completamente definido y predictivo.

Feature Driven Development (FDD)

Método ágil donde el seguimiento del progreso se realiza mediante el examen de pequeñas funcionalidades (features) descompuestas y valoradas por el cliente.

No cubre todo el ciclo de vida; se enfoca principalmente en las fases de diseño y construcción.
Se considera apto para proyectos mayores o de misión crítica, a diferencia de otros métodos ágiles más orientados a equipos pequeños.
Existen roles definidos, incluyendo Arquitectos.
Utiliza numerosos artefactos para el control del proceso.

FDD es un método de desarrollo de ciclos cortos:

En la primera fase, el modelo global de dominio es elaborado por expertos del dominio y desarrolladores.
El modelo de dominio consiste en diagramas de clases con clases, relaciones, métodos y atributos.
Los métodos en el modelo no reflejan necesariamente conveniencias de programación, sino rasgos funcionales del negocio.

Software Capability Maturity Model (CMM / CMMI)

CMMI es el acrónimo de Capability Maturity Model Integration (Integración de Modelos de Madurez de Capacidades). Se define como un modelo para la mejora de los procesos de desarrollo y mantenimiento de sistemas y productos de software.

Fue creado por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon (EE.UU.) y publicado en su primera versión (CMMI) en el año 2002, evolucionando del CMM original.

Objetivos de CMMI

Producir servicios y productos de alta calidad.
Crear valor para los accionistas.
Mejorar la satisfacción del cliente.
Incrementar la participación en el mercado.
Ganar reconocimiento en la industria.

Niveles de Madurez (Representación Escalonada)

Utilizado en la representación escalonada para enfocar la mejora en la capacidad del proceso que la organización espera obtener:

INICIAL: No se tienen procesos definidos ni documentados en la organización. El desarrollo es caótico y ad hoc, dependiente de esfuerzos individuales («heroicidades»).
ADMINISTRADO (Gestionado): La organización cuenta con procesos básicos de administración de proyectos (planificación, seguimiento, control) que se utilizan a nivel de proyecto.
DEFINIDO: La organización cuenta con un conjunto estándar de procesos documentados y establecidos para toda la organización, que pueden ser ajustados (tailoring) bajo determinadas condiciones para proyectos específicos.
ADMINISTRADO CUANTITATIVAMENTE (Gestionado Cuantitativamente): La organización controla sus procesos mediante el uso de estadísticas y otras técnicas cuantitativas para entender y controlar la variación.
OPTIMIZADO: La organización se enfoca en la mejora continua de sus procesos, abordando las causas comunes de variación y buscando la innovación. Es el estado ideal o «Nirvana» de la madurez de procesos.

SCAMPI (Standard CMMI Appraisal Method for Process Improvement)

Es un método desarrollado por el SEI para evaluar el estado de los procesos de software de una organización, basado en los modelos CMMI.

Existen tres clases de evaluaciones SCAMPI: A, B y C, que varían en profundidad, duración, costo y uso. Las evaluaciones formales (especialmente la Clase A, que puede resultar en una calificación de nivel) son realizadas por un Asesor Líder (Lead Appraiser) acreditado por el SEI (o CMMI Institute).

Los resultados de un SCAMPI permiten a la organización conocer la situación actual de sus procesos, establecer prioridades, enfocar las actividades de mejora, reforzar áreas de oportunidad y tener una base sobre la cual establecer el siguiente ciclo de mejora.