Una de las principales tareas en el proceso de desarrollo de software es lidiar con los riesgos que aparecen ligados a todos los proyectos. Es uno de los requisitos del proceso unificado de desarrollo el tener una lista de riesgos, pero esto no significa que una vez elaborada esta lista se guarda en un cajon o se archiva en un documento de los tantos que se elaboran. Al contrario, esta lista debe servir como guia a lo largo del ciclo de vida, de manera de ir reduciendo estos riesgos en forma paulatina. Esto es, la lista de riesgos debe ocupar un lugar importante en la documentacion de soporte del proyecto, los riesgos deben ser identificados tempranamente, documentados con su descripcion, impacto, tamaño, importancia e ideas acerca de como deben reducirse. Debe haber un responsable en el equipo de trabajo que se encargue del seguimiento, y lo mas importante, los riesgos deben identificarse y enfrentarse tempranamente, reconocerlos, asumirlos y enfrentar los problemas anticipadamente.

El SWEBOK (cuerpo del conocimiento de la ingenieria del software), elaborado por la IEEE es un proyecto para lograr condensar el conocimiento aceptado generalmente (las practicas establecidas tradicionalmente y recomendadas por multiples organizaciones) y lograr un consenso en un cuerpo de conocimientos central acerca de la ingenieria del software.

A pesar de los millones de profesionales del software que existen en todo el mundo, y la amplia presencia y ubicua del software en nuestra sociedad, la ingenieria del software no ha alcanzado el estado de una disciplina de ingeniera y reconocimiento profesional. Desde 1993, la IEEE Computer Society y ACM han venido promoviendo activamente la ingenieria del software como una profesion.

En otras disciplinas, la acreditacion de contenidos universitarios y el licenciamiento y certificacion de la practica profesional se toman muy en serio. Estas actividades estan vistas como criticas para la constante actualizacion y mejora profesional y, por lo tanto, la mejora de los niveles de la practica profesional. Reconocer un cuepo de conocimientos central es fundamental para el desarrollo y acreditacion de contenidos universitarios y el licenciamiento y certificacion de profesionales.

Alcanzar este consenso mediante la realizacion de un cuerpo de conocimiento es un paso clave en todas las disciplinas y ha sido identificado como crucial para la evolucion de la ingenieria del software hacia un estatus profesional. El proyecto de la Guia del Software Engineering Body of Knowledge es una iniciativa que apunta a alcanzar este consenso.

Aqui puede descargarse una presentacion donde se explica el porque del SWEBOK, y aqui puede descargarse la version Ironman del 23 de Junio de 2003.

Todas las metodologias mas conocidas para desarrollo de software, establecen que el desarrollo completo de un proyecto es un proceso iterativo (esto es, que se realiza como una serie de pasos repetitivos) e incremental (con cada repeticion nos vamos acercando mas al resultado deseado).
Aquellos viejos “ciclos de vida” (procesos de desarrollo de software) en cascada donde primero se comenzaba con la captura de requerimientos, luego el analisis, diseño, implementacion y testing, ahora se ven reemplazados por versiones iterativas de los mismos pasos. Uno de las metodologias mas populares ultimamente es el Proceso Unificado de Desarrollo de Software. No voy a intentar una aproximacion al proceso unificado, sino intentar explicar de que se trata el diseño y modelado de sistemas dentro de este proceso.

Todos sabemos que lo que conocemos por realidad esta moldeada por la percepcion que tenemos de esta, nuestros sentidos (vista, oido, tacto, olfato, gusto) nos permiten percibir ciertos aspectos de la realidad, y cada ser humano (con sus diferencias) tiende a percibirla de manera ligeramente distinta. Bien, podemos entonces establecer aqui una analogia: la realidad es la selva en la que vivimos, y nuestra percepcion de la realidad es solo un plano de esta selva. Con este ejemplo podemos entender que no es lo mismo un plano de la selva (en 2D, en escala, con aclaraciones, puntos cardinales, etc.) que la selva misma (en 3D, con otros objetos, que no aparecen representados en el mapa, en tamaño real, etc.).

Lo mismo sucede con el modelado de sistemas. A medida que vamos avanzando en las iteraciones de los diferentes procesos de desarrollo de software, vamos aproximandonos en la construccion de un “mapa de la selva”, y vamos creando un modelo del problema que estamos intentando comprender. Un modelo es una simplificacion del tema en cuestion, es por esto que en las primeras iteraciones (analisis) tenemos una aproximacion simple (que en el proceso unificado llamamos “casos de uso”) que nos permite comprender el problema desde el punto de vista de quien va a usarlo.
En iteraciones mas avanzadas (diseño) nos paramos sobre los resultados de nuestra primera aproximacion, y vamos refinando los detalles que ya habiamos recolectado anteriormente. Volviendo a encarar el problema es que podemos comprenderlo y abarcarlo mas ampliamente. Asi vamos ahondando en detalles, volviendo a pensar conceptos, contrastando nuestras ideas con la realidad, es que refinamos el detalle de nuestro “mapa”.

Esto no es una tarea menor, se considera que el diseño (nuestra segunda iteracion) es por lo menos cinco veces mas larga (en tiempo) que la primera iteracion de analisis. En la etapa de diseño no solo debemos comprender en profundidad nuestro problema, sino hacer consideraciones respecto a donde va a estar funcionando (hardware, entornos de red, etc.) y como va a estar distribuido. Al final de esta etapa, debemos tener un mapa 90% definitivo de que es lo que queremos hacer.

Sin un mapa de nuestro sistema, como podremos construirlo correctamente?

El servidor mas seguro de la linea Windows (hasta el dia de hoy) va en camino de tener su primer service pack! En este link pueden encontrar como bajar el Release Candidate (la version casi casi final) del Service Pack 1 para Windows 2003. Personalmente creo que es una de las mejores versiones de Windows que existen, mas alla de que tiene sus caprichos y vueltas especiales (IIS es un poquito distinto…). Aquellos que aun se resisten, ok, es cierto, Windows 2000 es muy bueno, cierto, pero el 2003 es realmente un paso adelante!

En los ultimos años hemos visto grandes avances en la industria del software, esto puede verse como una maduracion de la forma de producir software. De las viejas tecnicas empleadas anteriormente solo quedan las malas experiencias, y avanza el uso de metodologias cada vez mas cercanas a otras disciplinas de Ingenieria. El software, que comenzo como una construccion artesanal, y como una tarea de investigacion, muy vinculada a la matematica, hoy en dia se ha convertido en una industria que mueve millones de dolares alrededor del mundo, y que no puede darse el lujo de seguir cometiendo los mismos errores que hace años. Paradigmas como la programacion estructurada (en los ’80) parecia que iba a dominar la industria del software por siempre. La solucion que hemos escuchado desde hace un tiempo es que nuevos niveles de abstraccion iban a permitirnos la liberacion de las tediosas tareas de programacion que no estan exclusivamente vinculadas al dominio del problema que estamos abordando. Asi es como nacio el paradigma de orientacion a objetos, y mas tarde, el concepto de maquinas virtuales, administracion de memoria automatica (con garbage collectors por ejemplo) y otros. Asi hemos descubierto que una de las claves de la alta productividad de ciertos lenguajes de produccion tiene mas que ver con la administracion automatica de memoria (que libera a los programadores de tener que estar solicitando y liberando diferentes areas de memoria) que con la “abstraccion de la plataforma”. Dos ejemplos exitosos de este principio son Visual Basic y Java. En los ultimos dos años, con la aparicion de .NET tambien vemos esta ventaja extendida con nuevos lenguajes como C# y VB.NET. Si bien la orientacion a objetos es una gran ventaja, creo que la posibilidad de no tener que estar preocupandose por temas tecnologicos que no tienen que ver con las “reglas” de negocios que queremos implementar, es inmensa. Habiendo llegado a un nivel de madurez en este flanco, es que aparecen nuevos desafios que permitan la madurez del software como Ingenieria. Parte de esto es la existencia de frameworks (conjuntos de librerias) que no solo estandarizan el codigo y la posibilidad de utilizar multiples funcionalidades que aparecen una y otra vez en los proyectos, sino en la velocidad de utilizar codigo ya probado por otros. Es lo que la ciencia llama ‘pararse en los hombros del gigante’: utilizar lo que otros han construido para seguir adelante con nuestro problema especifico.

El MSDN Smart Client Developer Centerfue actualizado recientemente… Chris Sells ahora sera ahora co-editor con Jonathan Wells del nuevo y mejorado sitio. El objetivo del sitio es ayudar a comprender los smart clients, que son, cuando son lo mas apropiado, y lo mas importante, la mejor y mas eficiente forma de construirlos. Realmente vale la pena consultar el sitio, esta lleno de recursos para los desarrolladores.

Como vengo diciendo en mis ultimos posts, y reflexionando acerca de la complejidad de la construccion del software, es que pienso que es cada vez mas necesario que una compañía de software tenga su propio framework para la construccion de aplicaciones. Tuve la experiencia de trabajar hasta julio de 2004 en una consultora en la que estuve involucrado en el equipo de desarrollo del framework interno y puedo decir que fue uno de los desafios mas interesantes que tuve que abordar en mi vida profesional: dejar de pensar en una determinada funcionalidad y comenzar a pensar en bloques constructivos (pequeños ladrillos) para una aplicacion mucho mas grande, documentar todo, ejecutar tareas de ingenieria, pensar para el mantenimiento, pensar en lo que vamos a estar haciendo de aca a dos o tres años, etc.

En este espiritu es que Microsoft penso el .NET Framework y ahora elabora la estrategia de las Software Factories, pensando en automatizar toda tarea que sea posible. Esta automatizacion (principalmente manejada con generadores de codigo) apunta a reducir los tiempos de produccion del software y relevar a los programadores de las tareas repetitivas, esto ultimo por dos razones: primero, las tareas repetitivas son facilmente reproducibles por un generador de codigo, y ademas, son las que mayor cantidad de errores generan a la hora de programar.

En los proximos años veremos cada vez mas esta clase de asistentes, y esto sera parte de nuestra tarea cotidiana de programacion. Despues de todo, no fue hace tanto que nos maravillabamos con las ‘VBX’ primero, y luego con las ‘OCX’, y con la construccion de software basado en componentes …

Interesante como siempre, el weblog de Miguel de Icaza, nos advierte acerca de la complejidad del modelo de objetos de Avalon (la nueva API de programacion de GUI de Longhorn, que con el reschedule del esta sistema operativo, tambien estara disponible para XP y W2K3). Un post muy interesante para leer, el analisis de la complejidad del modelo de objetos y otras observaciones que hace Miguel, estan basadas en la falta de recursos que tiene disponible para implementar esta API en el proyecto mono (que es una implementacion libre de .NET que corre en varias plataformas: Linux, MacOsX y otros). Un post realmente muy interesante para leer..

Tambien esta la respuesta de Chris Anderson, de Microsoft, donde analiza las conclusiones de Miguel, desde el punto de vista de la etapa en la que se encuentra el desarrollo actualmente (antes de fase beta). Una respuesta un poco liviana (a mi pobre entender) para una serie de conclusiones bastante fuertes.

Cw o C omega language es un lenguaje de programacion de investigacion, con extensiones al lenguaje C#, en dos areas que anteriormente estaban separadas: – Abstraccion de concurrencia (conocido anteriormente como Polyphonic C#). – Una extension de datos al C# (conocida como X#).

Hoy tuve el agrado de encontrarme con estos dos artículos, publicados en el Microsoft Architect’s Journal:

The case of Software Factories.
Problems and Innovations.

El primero de estos artículos explica en detalle los problemas a los que se enfrenta hoy la industria del software; poca mano de obra calificada, falta de herramientas de productividad, aumento exponencial de la complejidad de la administración de proyectos al incorporar recursos en proporción lineal, etc. Luego continúa haciendo un pequeño raconto de la evolución de la construcción del software, haciendo una comparación con el concepto de paradigma en las preciencias / ciencias normales de Kuhn. Y esboza una serie de soluciones (componentización, utilización de frameworks) y un muy interesante análisis de las economías de escala (scale economies), y las economías de alcance(scope economies), y explica el clásico error al comparar el proceso de producción de bienes en economías de escala, con el proceso de desarrollo en economías de alcance.

El segundo artículo (más largo que el primero) se adentra en los actuales problemas y posibles soluciones que enfrentamos al intentar industrializar el proceso de construcción del software. Y da algunos previews de conceptos que aparentemente estarán disponibles en Microsoft Visual Studio 2005 Team System (como una herramienta para automatizar el deployment de componentes), plantea el éxito de los webservices (luego de que CORBA y otras tecnologías similares fallaran).
También explica un interesante concepto que intentaré investigar: Variable Encapsulation, y lo muestra como una evolución de Aspect Oriented Programming (AOP) contrastandolo con sus beneficios y problemas.