Bernie Najlis

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!