Buscar en Gazafatonario IT

lunes, febrero 14, 2005

Las Seis Mejores Prácticas

En cuatro de las cinco últimas columnas he hablado de una u otra forma sobre modelado de software, en particular, y sobre desarrollo de aplicaciones, en general. En “El Papel del Modelado en la Transformación de los Requisitos en Software”, por ejemplo, decía que debemos elaborar modelos simples, a partir de cada porción significativa de requerimientos del software.
En “Qué Diagramas Usar?”, expresé mi opinión de que todas las técnicas y elementos en un proceso como RUP tienen múltiples propósitos y que realmente, no hay una “forma corta”, de decidir lo que es apropiado en cada situación (de modelado). Y en “El Imperio de las Metodologías” decía que era práctico dividir un proyecto en pequeñas piezas o mini-proyectos, donde cada mini-proyecto es una iteración.
Estas y otras ideas al respecto son la base de esta nueva entrega, sobre lo que debemos y no debemos hacer al emprender un proyecto de desarrollo de software, en especial sobre lo que sí debemos hacer, las prácticas que quienes nos enfrentamos día a día al reto de construir software de alta calidad consideramos como mejores, como soporte para el éxito anunciado en los proyectos.
Combinadas unas con otras y orientadas a la raíz de los problemas cotidianos de la construcción de software, estas prácticas permiten desarrollar y mantener aplicaciones en forma repetible y predecible. Ellas son:
1. Modelar Visualmente
2. Manejar Requisitos
3. Verificar la Calidad Continuamente
4. Usar Arquitecturas Basadas en Componentes
5. Desarrollar por Iteraciones
6. Controlar los Cambios
Modelar Visualmente
Para Modelar Visualmente, es necesario usar un lenguaje de diseño con una semántica extendida que permita mejorar la comunicación en el equipo de trabajo que elabora y revisa el diseño de la aplicación. Además de los textos gramaticales, el lenguaje debe proporcionar una sintaxis gráfica predominante y rigurosa con la cual expresemos las decisiones tomadas que luego servirán como base para la implementación del sistema. De esta forma, podremos entender mejor el sistema en construcción y razonar acerca de el con precisión. Hablo, por supuesto, de aplicaciones multi-desarrollador, aquellas en las cuales se invierte una cantidad considerable de talento humano, de tiempo y, claro, de recursos.
El Lenguaje de Modelado Unificado –UML cumple con estas características. Y sobre el ya hice una presentación que pueden encontrar en: http://b.1asphost.com/LuchoSalazar/GazafatonarioIT/Prolegmenos%20Sobre%20el%20Lenguaje%20de%20Modelado%20Unificado.pdf. También en el boletín No. 5, en esta misma columna, presenté una breve discusión sobre los distintos tipos de diagramas que usamos para hacer modelado visual. La columna está en: http://gazafatonarioit.blogspot.com/2005/02/qu-diagramas-usar.html.
En resumen, el modelado visual es un requisito porque muestra la esencia del sistema desde una perspectiva particular y oculta los detalles no esenciales. Los modelos, en general, pueden ayudar a:
Ø Entender sistemas complejos
Ø Explorar y comparar alternativas de diseño
Ø Formar una base sólida para la implementación
Ø Capturar los requisitos con precisión
Ø Comunicar decisiones inequívocamente
Manejar Requisitos
El Proceso Unificado define el Manejo de Requisitos como un enfoque sistemático para encontrar, documentar, organizar y hacer seguimiento a los cambios de los requisitos de un sistema.
En este punto sería interesante que hicieran el siguiente ejercicio que les propongo: Definir que es un “requisito”, un requisito de software, ciertamente. No se imaginan ustedes las sorpresas que me he llevado cuando le digo a los asistentes a mis cursos y conferencias que hagan esa tarea, al parecer, simple para muchos. Pues bien, desde el punto de vista de RUP, un requisito es una “condición o capacidad que el sistema debe cumplir o tener”.
Mientras escribo esta columna, John Alexander López prepara un artículo introductorio sobre manejo de requisitos de software. Esperemos a ver lo que tiene que decirnos al respecto. Lo que sí quiero dejar claro desde ya es que la recolección de requisitos puede sonar como una tarea simple y, sin embargo, puede causar estragos significativos en un proyecto porque los requisitos:
Ø no siempre son obvios y pueden venir de muchas fuentes
Ø no siempre son fácilmente expresables en palabras
Ø son de muchos tipos y de distintos niveles de detalle
Ø si no son controlados desde el comienzo del proyecto, su número puede crecer hasta límites inmanejables
Ø están sujetos a cambios “sin previo aviso”
Ahora bien, para manejar requisitos exitosamente, se requiere:
Ø Analizar el problema
Ø Entender las necesidades tanto de los patrocinadores del proyecto, como de los usuarios y demás responsables del mismo
Ø Definir el sistema
Ø Manejar el alcance del proyecto
Ø Refinar la definición del sistema
Ø Manejar los cambios
Cada una de estas actividades requiere de talento y, evidentemente, de tiempo y recursos compartidos en el equipo de desarrollo. En las próximas entregas les hablaré más del asunto.
Verificar Calidad Continuamente
Una vez me dijeron acerca de la Calidad: “yo no sé como describirla, pero soy capaz de reconocerla cuando la veo”. Les dejo una vez más la tarea de definir lo que es Calidad, concretamente, Calidad de Software.
Lo que sí quiero ilustrar en esta columna es que se debe evaluar la calidad de todos los artefactos en distintos puntos del ciclo de vida del proyecto, a medida que este crece. Estos artefactos deben ser validados al término de cada actividad o etapa que los produce (más adelante les hablaré de Iteraciones y de los resultados que se esperan en cada una de ellas). Específicamente, a medida que se producen componentes ejecutables del sistema, estos se deben someter a un proceso de pruebas que abarque los distintos escenarios para los cuales fueron construidos (todos los escenarios, hasta aquel que solo va a acontecer una vez en la vida útil del sistema y quizás hasta el que nunca va a suceder pero que es posible que ocurra).
Este proceso de pruebas conduce a la depuración del sistema y a la eliminación de los defectos arquitectónicos de la aplicación.
Usar Arquitecturas Basadas en Componentes
En ocasiones pienso acerca de cada ser humano como un imperio y acerca de la humanidad como una summa de imperios. Y una característica común a todos los imperios es que poseen tecnología y estrategias de guerra superiores a las de los conquistados, entre las que se encuentra la famosa “divide y vencerás”, utilizada por Julio César o Hernán Cortés y adoptada hoy como herramienta guerrera por las compañías multinacionales simplemente porque los imperios buscan el control puro y escueto de los conquistados.
Esta analogía me sirve para mostrarles que siempre hay que tener control (nosotros, el imperio) sobre lo que hacemos (soluciones de software). La estrategia de Julio César o Cortés se ha aplicado desde siempre en el desarrollo de software y se seguirá aplicando sin importar la metodología, el proceso, los avances tecnológicos o la cantidad y calidad de talento humano utilizado para crear un producto.
Y cuando dividimos ese producto en piezas más pequeñas, controlables, ajustables, intercambiables, lo que nos queda son grupos cohesivos de código, fuente o ejecutable, con interfaces y comportamiento bien definidos que proporcionan un fuerte encapsulamiento de su contenido. Estos grupos forman la arquitectura basada en componentes de nuestro sistema. Una arquitectura así tiende a reducir el tamaño y la complejidad de la solución y, por supuesto, es más robusta y resistente.
Hoy, las plataformas .Net o J2EE suministran las referencias arquitectónicas que necesitamos para diseñar y construir soluciones basadas en componentes. Como antes, ya se encuentra en preparación un artículo sobre la plataforma .Net que será publicado en el sitio Web de la Asociación.
Desarrollar por Iteraciones
Pero la arquitectura y el producto no es lo único que dividimos al ejecutar un proyecto. El mismo proyecto está sujeto a un fraccionamiento que ha mostrado ser muy efectivo.
La división de un proyecto en grupos continuos de proyectos más pequeños, sujetos a incesante revisión, dinámicos y evaluables, hace posible que tengamos completo control de todo el proyecto.
En El Proceso Unificado - Episodio IV, de hace un mes, expuse las razones por las cuales deberíamos adoptar esta práctica sin reparos. Antes de que volvamos a leerla, quisiera dejarlos con estas tres leyes que escribí hace pocos meses, luego de una discusión amena sobre manejo de proyectos:
Ø Todo proyecto de menos de dos semanas, tarda dos semanas
Ø Todo proyecto de entre dos semanas y un mes, tarda un mes
Ø No hay tal cosa como un proyecto que tarde más de un mes
Por supuesto, me refería a las iteraciones, que realmente pueden tardar más tiempo, algunos dicen que entre tres y nueve semanas, otros que entre dos y seis semanas. Bueno, esa fue mi conclusión, quince años de experiencia la soportan.
La última de estas tres leyes también se puede leer así:
Ø Todo proyecto que tarde más de un mes nunca termina
Y el que esté libre de culpa que lance la primera piedra.
Controlar los Cambios
Ya les dije antes que los requisitos de un sistema están sujetos a cambios “sin previo aviso”, sobre todo en proyectos a mediano y largo plazo. Pero primero lo primero, aclaración # 1: me refiero aquí a los cambios que sufren los requisitos luego de haber sido aprobados por los usuarios y de que posiblemente hayan sido implementados en alguna iteración, concluida o en ejecución, del proyecto.
Los desarrolladores noveles son muy dados a engancharse en una carrera contra el tiempo, contra los recursos, contra el contrato, contra el producto, cuando de llevar a cabo una modificación se trata. Y permítanme decirles, damas y caballeros, que antes de hacerlo es necesario estudiar en detalle el impacto que un cambio tendrá sobre todo nuestro sistema.
Un cambio en un requisito puede causar una dispersión de proporciones descomunales en un producto de software si no es definido claramente, evaluado y puesto a consideración de todo el equipo del proyecto. Por supuesto, el desarrollo iterativo y los componentes ayudan a mitigar los efectos ocasionados por los cambios en los requisitos y a que la implantación de estos se haga acorde a un plan establecido de manejo de cambios que no perturbe la ejecución del proyecto.
En el Final
Bueno, es realmente el final de una presentación efímera sobre estas prácticas. Como siempre, sostengo que los problemas más serios que he encontrado en los proyectos son de talento humano, en este caso, de comunicación entre quienes intervienen en un proyecto.
La conclusión es que cada una de estas prácticas debe tener una buena comunicación como prerrequisito. Sin una buena comunicación, todas fallarán al tratar de alcanzar su objetivo, todos fracasaremos sin duda, y seguramente recibiremos una dosis adictiva de apremio para caer en los métodos tradicionales de cascada donde la comunicación real es substituida por montones de documentos que no contribuyen mucho a producir valor para nuestros usuarios.
Ustedes qué creen? Compartan sus opiniones conmigo y con todos en AAII sobre este y otros temas. Pueden escribirme a lucho.salazar@gmail.com.
Referencias
http://www.rational.com/corpinfo/practices.jsp
http://www.aaii.org.co/html/modules.php?name=Content&pa=showpage&pid=11
http://www.aaii.org.co/html/modules.php?name=Content&pa=showpage&pid=24
http://www.aaii.org.co/html/modules.php?name=Sections&op=viewarticle&artid=11
http://www.aaii.org.co/html/modules.php?name=Sections&op=viewarticle&artid=18
El Proceso Unificado de Rational –RUP:
http://www.rational.com/products/rup/prodinfo.jsp
http://www.rational.com/tryit/rup/index.jsp
Luis Antonio Salazar Caraballo
Medellín, Septiembre 29 de 2003

1 comentario:

  1. Si quieren tener proyectos de desarrollo exitosos donde los requerimientos sean muy variables entonces desarrollen por iteraciones, es la mejor manera de lograr los objetivos del cliente sin quebrarse como desarrolladores.

    ResponderEliminar