Procesos de Desarrollo

 Quizás  para quien sólo recibe software y lo usa puede parecer sencillo pero, para quienes lo desarrollamos, no queda ninguna duda de que el proceso de desarrollo de software es realmente algo complejo de administrar

Para mantener la casa en orden es que se maduran metodologías, con la intención de prevenir riesgos (o en el peor caso de detectarlos y mitigarlos) de manera de garantizar el éxito. Y cómo se mide ese éxito? Cómo asegurarnos que lo hemos alcanzado o que hemos perdido la chance? Normalmente la percepción de éxito se fundamenta en dos criterios: costo total y presupuesto. Ambos deben estar dentro de lo presupuestado. Estadísticas como el Chaos Report (de The Standish Group) alegan que sólo una pequeña porción de estos proyectos son exitosos
Existen tres factores que, si bien no garantizan el éxito, cuando están presentes ayudan a alcanzarlo. Las metodologías, a su manera, tratan de controlar la influencia de los mismos
  • Iniciativas de negocio. Que abaraten costos, que mejoren los ingresos o bien la combinación de ambas: que mejoren la productividad (hacer más con menos)
  • Personas del equipo. Que posean el perfil necesario (no todos el mismo sino una inteligente combinación a lo largo del equipo), que observen la conducta adecuada, que aporten la experiencia necesaria (esto último pareciera que deja fuera de carrera a los novatos pero nada de eso: que conozcan lo suficiente como para no venir a aprender al proyecto, pero a la vez que desconozcan lo necesario como para no perder el afán investigador ni caer en prejuicios)
  • Tecnologías. Herramientas que aceleren el proceso, que ayuden a llevar la gestión sin agregar burocracia, API’s fáciles de aprender, arquitecturas comprensible que simplifiquen el desarrollo de la lógica de aplicación)
Los diferentes procesos (que hoy sólo enumeramos pero que profundizaremos en una serie) comparten cierta estructura que contempla las siguientes actividades (con variaciones en los nombres, en la implementación y también en la frecuencia)
  • Definición Conceptual, donde se fijan los alcances del proyecto en términos del negocio, y se estiman los esfuerzos
  • Especificación, que detalla para el equipo técnico esos requerimientos de negocio de la actividad anterior
  • Diseño, que planea la estrategia de la actividad siguiente
  • Construcción, el momento donde las ideas se tornan en realidades
  • Control de Calidad, que busca anticipar la experiencia del usuario para verificar que los estándares de aceptación prefijados estén cubiertos
  • Distribución, que comienza cuando la aplicación se pasa a producción e incluye todo el mantenimiento posterior de la misma
Tradicionalmente los procesos ejecutaban estas etapas en forma única y ordenada. Eso se conocía como cascada (waterfall). Fue siendo sustituído porque para proyectos largos era altísimo el riesgo de que las definiciones conceptuales o las especificaciones de requerimientos caducasen conforme evolucionase el negocio
Los procesos actuales reducen ese riesgo repartiendo el alcance del proyecto general en etapas lo suficientemente largas como para poder medir el impacto de los entregables, pero al mismo tiempo lo suficientemente cortas como para no perder conexión con los cambios del negocio
Hay un par de consideraciones más:
  • Algunas procesos consideran que todo o parte del equipo de desarrollo esté geograficamente alejado de los usuarios finales (offshore). De hecho es una tendencia creciente que sea externo a la organización (outsourcing) por una mejora evidente en la ecuación costo-beneficio. El desafío en estos casos es mitigar diferencias culturales, de lenguaje, de contexto físico e -inevitablemente- de idiosincracia
  • Otros procesos ponen énfasis en la actividad de Mantenimiento, considerando que no son pocas las organizaciones que tienen gente abocada a nuevos desarrollos y gente abocada a soportar lo que ya está en producción. En otras palabras, estos procesos consideran que los que mantienen la aplicación son otros que los que la hicieron, tienen otras motivaciones, pueden incluso desconocer cuáles fueron los "por qués" de ciertas decisiones de diseño
En nuestros días, los procesos más destacados son
  • eXtreme Programming (XP). Metodología ágil con eje en la codificación como actividad primaria. No es proclive a una documentación exhaustiva sino que "el programa es la documentación". Es muy orientada a resultados, con entregables frecuentes y una íntima interacción con el usuario. En organizaciones con procesos formales ha levantado barreras por ser disruptiva respecto de la cultura organizacional
  • Capacity Maturity Model (CMM/SEI). Más que una metodología es una forma de asignar un puntaje basado en la madurez de los procesos de una organización. Cada punto a alcanzar implica observar ciertas prácticas hasta llegar a un nivel donde el proceso tenga por retroalimentación elementos que lo mejoren. Aunque comprensivo del ciclo de vida, requiere de grupos adicionales para definir y medir cómo madurar
  • El Framework de Zachman. Consiste en una matriz que encolumna diferentes perspectivas de la arquitectura. En cada fila pone un interesado (stakeholder) partiendo de los niveles más gerenciales del negocio hasta los más técnicos del área de TI. Se le reconoce ser una de las técnicas procesales más detallistas, si bien no todos los proyectos requieren tal grado de profundidad
  • Model-Driven Arquitecture (MDA). Especifica una serie de estándares para poder modelar componentes desde herramientas compatibles. A su vez, mapeadores disponibles por terceros se encargan de convertir los modelos a ejecutables de plataformas específicas. En otras palabras, persigue desacoplar y automatizar los modelos de la implementación
  • Rational Unified Process (RUP). Mecanismo basado en fases iterativas y disciplinas que debe su éxito tanto a un subproducto para comunicar requerimientos (el Lenguaje Unificado de Modelado o UML) como al soporte al proceso que Rational brindó con sus herramientas. Existen adaptaciones de RUP tanto para proyectos livianos como para procesos de mayor envergadura. Esta característica no es por todos conocida y se corre riesgo de fracaso si se aplica inadecuadamente el RUP "oficial"
Estos procesos no son mutuamente excluyentes: las organizaciones suelen tomar prácticas de varias metodologías y crear así “su” metodología. Aquí la clave consiste en balancear adecuadamente flexibilidad y disciplina, acorde a circunstancias del proyecto y del ritmo del negocio
 
Microsoft, al respecto, tiene para decir lo suyo con Microsoft Solutions Framework (MSF), del cual hemos hablado anteriormente. MSF consiste en un conjunto de prácticas aplicables según el contexto del proyecto. De esta forma, la adecuada combinación de algunas de ellas termina conformando un proceso específico para cada ocasión. En Octubre pasado grabamos un webcast mostrando con ejemplos el soporte incorporado a la herramienta de desarrollo Visual Studio 2005 Team System
Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s