Reflexiones sobre Modelado

Decidí escribir este artículo ya que en repetidas veces debo exponer nociones de modelado, caer es discusiones poco productivas, participar en encuentros en donde el tópico de exposición es "debemos crear código, ¿porque análisis?, ¿porque diseño?" desde el ambiente laboral hasta el entorno universitario, por este motivo estas son mis reflexiones y óptica en cuanto al modelado de software.

Una empresa de software exitosa es aquella que produce de una manera consistente software de calidad que satisface las necesidades de sus usuarios, ahora la discusión no se centra principalmente en esta última frase sino en "¿Cuando una empresa tiene un negocio sostenible?".

Para responde este interrogante la reflexión es: "Una empresa que puede desarrollar el software de forma predecible y puntual, con un uso eficiente y efectivo de recursos, tanto humanos como materiales"

Ahora bien, el producto principal de un equipo de desarrolla no son bonitos documentos, reuniones muy importantes, grandes lemas o código fuente merecedoras del premio Imagine Cup (para el caso de Microsoft), la idea es un buen software que satisfaga las necesidades cambiantes de sus usuarios y la empresa, el resto es secundario.

Muchas organizaciones confunden secundario con irrelevante y esto conlleva el efecto caótico que he desarrollado en entregas anteriores (en el blog "conceptos y opiniones").

Para producir software que cumpla su propósito, hay que conocer e involucrar a los usuarios de forma disciplinada con el fin de extraer los requisitos reales del sistema. Para desarrollar software de calidad duradera, hay que idear una sólida base arquitectónica que sea flexible al cambio. Para desarrollar software rápido, eficiente y efectivamente, con el mínimo de desechos software y de trabajo repetido, hay que tener la gente apropiada, las herramientas apropiadas y el enfoque apropiado.

Todo lo expuesto anteriormente es válido solo si disponemos de un proceso de desarrollo sólido que pueda adaptarse a las necesidades cambiantes del problema en cuestión y de la tecnología a utilizar.

El interrogante que llega en este punto es: ¿Para que construimos modelos?

Construimos modelos para visualizar y controlar la arquitectura de un sistema, construimos modelos para comprender mejor el sistema que estamos construyendo y muchas veces descubriendo oportunidades para la simplificación y la reutilización, construimos modelos para controlar el riesgo.

¿Es importante modelar?

Para describir de forma introductoria este punto voy a realizar una síntesis expuesta por (Booch, Rumbaugh y Jacobson) en donde comienzan detallando un objetivo de construcción de una casita para nuestra mascota en este caso un perro, realizaríamos un compra de materiales rudimentarios (madera, clavos, serrucho, cinta magnética, martillo), en unas pocas horas posiblemente podamos tener la casa sin ayuda, mientras sea lo suficientemente grande y no tenga goteras el perro, nuestra mascota estará contento, si no sale bien siempre hay tiempo de volver a construir o buscar un perro menos exigente jeje.

Ahora avancemos con el ejemplo y la idea es construir una casa de familia (reunimos madera, clavos, herramientas básicas de construcción) esto va a llevar más tiempo y seguramente una familia será más exigente. En este caso se obtendrán mejores resultados con una planificación detallada antes de golpear por primera vez un clavo o realizar los cimientos. Se realizarán bocetos preliminares del aspecto de la casa y además si se requiere una casa de calidad que cumpla las necesidades de la familia y que respete las leyes de construcción local, será necesario dibujar planos, habitaciones, despliegue eléctrico, calefacción, agua, etc. Con estos planos podemos estimar mejor el esquema de materiales y sin duda vamos a tener que subcontratar, entonces el entendimiento para la delegación de actividades es fundamental. Si se cumplen los planes elaborados y todo permanece dentro de las limitaciones de tiempo y dinero, la familia estará satisfecha.

Avancemos nuevamente en el ejemplo para ahora construir un bloque de oficinas, ya en este punto sería fuera de lugar y tonto empezar con un conjunto de maderas, clavos y herramientas rudimentarias. Es probable que se use dinero de oras personas y ellas querrán influir en el tamaño y forma, además del estilo de construcción. Esto se va desarrollar en un entorno cambiante de opiniones. Para este escenario será deseable planificar de forma extensiva, porque el costo de fallar es alto.

Mientras se consiga la gente y las herramientas apropiadas y se controle de forma activa el proceso de trasformar un concepto arquitectónico en realidad, es probable que se llegue a obtener un edificio que satisfaga a sus inquilinos.

Curiosamente, un montón de empresas de desarrollo de software comienzan queriendo construir rascacielos, pero enfocan el problema como si estuvieran enfrentándose a la casita de un perro.

A veces se tiene suerte. Si uno tiene la gente apropiada en el momento oportuno y si todos los planetas están en conjunción entonces se podría. (¿Dejaría al azar la construcción del producto de software?)

Normalmente no se puede conseguir la gente apropiada (los buenos están muy solicitados), nunca es el momento oportuno (ayer hubiera sido mejor), y los planetas no parecen alinderarse (siguen fuera de control).

Entonces ¿Cual es el efecto de esta problemática?

Dada la creciente demanda de desarrollo rápido de software, los equipos de desarrollo muy frecuentemente recurren a la única cosa que realmente saben hacer bien, Triturar más y más líneas de código.

Realmente me canso de escuchar en organizaciones los esfuerzos heroicos que ya son leyenda en el rubro, y la sensación que deja es que la reacción apropiada para cualquier crisis en el desarrollo es trabajar más duro.

Si realmente queremos construir el software equivalente a una casa o un rascacielos, el problema es algo más que una cuestión de escribir grandes cantidades de software, el truco está en crear el software apropiado y en imaginar cómo escribir menos software. Esto convierte al desarrollo de software de calidad en una cuestión de arquitectura, procesos y herramientas.

Hay muchos elementos que contribuyen a una empresa de software con éxito: uno en común es el uso de modelos. El modelado es un técnica de ingenieria probada y aceptada no hace ni falta que lo mencione. Se construyen modelos arquitectónicos de casas, rascacielos para ayudar a los usuarios a visualizar el producto final, ni hablar de modelos matemáticos para analizar por ejemplo efectos de terremotos, vientos etc.

Pero hablamos mucho de modelos,

¿Qué es un modelo?

Un modelo es una simplificación de la realidad

¿Porque modelamos?

Construimos modelos para comprender mejor el sistema que estamos desarrollando

¿Qué objetivos conseguimos con el modelado?

1. Ayudan a visualizar como es, o queremos que sea un sistema
   


2. Permiten especificar la estructura o el comportamiento de un sistema
   


3. Proporcionan plantillas que nos guían en la construcción de un sistema.
   


4. Documentan decisiones que hemos adoptado.
   

Si quiero aclarar algo: " El modelado no es solo para los grandes sistemas"

Una reflexión interesante es: "Construimos modelos de sistemas complejos porque no podemos comprender el sistema en su totalidad"

Nada más por este articulo ya en los próximos días voy a publicar un esquema con los principios del modelado y como enlazar los conceptos expuestos para un desarrollo consistente de proyectos de software.

Espero les sea de utilidad.

Bibliografía utilizada para algunas citas y conceptos (UML2.0 Booch, Rumbaugh, Jacaobson)