Qué es un modelo?

Llamamos modelo a toda representación simplificada de la realidad, donde se han conservado aquellos elementos considerados importantes y se han descartado todo lo demás.

Los modelos son importantes dentro de la industria del software, y son utilizados para toda suerte de fines. Es posible apoyarse en el uso de modelos para entender y comunicar una enorme variedad de aspectos de nuestros productos de software e incluso, de los proyectos en si mismos.

En general, ya sea dentro de la industria del software o no, los modelos vienen a ayudar la comprensión de la realidad, al presentarnos solo aquellos aspectos o características de la situación que sean relevantes en un momento dado.

Pongamos un ejemplo. El New Beetle es un producto muy conocido de la compañía alemana Volkswagen y es el automóvil que podemos ver en la primera imagen. En este caso, es un automóvil de color negro.

Fig 1. Volkswagen New Beetle.

Es posible decir mucho de este automóvil. Podemos indicar cualidades obvias, como que tiene cuatro ruedas, dos puertas, un volante, que su techo es curvo o cualquier otra que se nos pueda ocurrir. Aunque también es posible indicar cualidades más sutiles, como el hecho que el automóvil de la foto no tiene placa. Hemos de recordar que después de todo, el producto no es solo muy conocido, sino que lo que tenemos ante nosotros es una foto y por lo tanto, tenemos muchos detalles a la vista.

Es posible sin embargo, que en un momento dado lo que nos interese decir sobre el automóvil sean sus medidas. Si este el caso hemos de construir un modelo en el cual se eliminen todas estas cualidades observadas y se queden solo aquellas que permitan ver con claridad las medidas del automóvil.

Naturalmente siempre podremos comunicar nuestra versión simplificada del automóvil por medio de una imagen, quizás una imagen como la siguiente.

Fig 2. Esquema del Volkswagen New Beetle.

Nuestra segunda imagen resalta el aspecto de interés: las medidas del automóvil. Al hacerlo nos presenta una vista inusual del producto real, quizás una que no tendremos ocasión de ver jamás en el mundo físico, pero que comunica en forma muy directa lo que necesitamos.

Un modelo es pues, definido como para el glosario:

Modelo: toda construcción hecha con información de una situación, idea o fenómeno real, en la cual hayamos resaltado ciertos aspectos de interés al tiempo que hemos ocultado todo lo demás.

Para construir modelos no hace falta necesariamente recurrir a diagramas e imágenes, pero es definitivamente una forma popular de hacerlo. Además de los planos o diagramas como los que se ilustran en el ejemplo del Volkswagen, contamos con herramientas más propias de nuestra profesión, como el lenguaje de construcción de modelos UML.

De esta forma, cuando se trate de aplicaciones de software, lo más común será encontrar modelos construidos y presentados por medio del uso del UML, actividad para la cual contamos con una gran variedad de herramientas útiles disponibles hoy en día, tanto comerciales como libres.

Requisitos legales

Se le llama requisitos legales a aquellas condiciones, impuestas por ley, que deban ser cumplidas por el proyecto, ya sea en la ejecución del proyecto como tal o en la funcionalidad provista por el sistema terminado. Los requisitos legales nacen de las leyes vigentes y que apliquen a nuestro proyecto de desarrollado ya sea por su naturaleza o por la jurisdicción bajo la cual se encuentra nuestra empresa.

Los requisitos legales surgidos por la naturaleza de nuestro proyecto, son aquellas obligaciones legales que puedan existir para ciertos tipos de aplicaciones. Son ejemplos comunes: las aplicaciones bancarias, los sistemas electorales y aquellos sistemas que manejen información privada del publico.

Las aplicaciones bancarias se encuentran sometidas a una amplia gama de requisitos legales. Tanto de confidencialidad como de confiabilidad en las transacciones. Se suele incluir en la legislación de muchos países aspectos tales como los registros de las operaciones, la interoperatividad de los sistemas, la criptografía a utilizar y las garantías de correcto funcionamiento.

Un poco más recientes, son las aplicaciones para sistemas electorales. En algunos países de la región así como en algunas jurisdicciones locales en los Estados Unidos, se han comenzado a utilizar sistemas de voto electrónico, ya sea en sustitución de las votaciones manuales o como complemento de estas en casos específicos. Como es natural esperar, los procesos de votación electrónica han de contar con gran cantidad de partes interesadas o stakeholders, razón esta por la cual hay grandes requerimientos de transparencia, confiabilidad y exactitud exigidos a estos sistemas por la ley y los reglamentos respectivos.

Incluso en aplicaciones más comunes pueden existir requisitos legales a considerar. Aquellos sistemas que recojan información de sus usuarios y que a la vez, permitan el registro del publico general como usuarios de las mismas, suelen estar sometidas a regulaciones sobre la seguridad de los datos.

Una variación también muy común es la de restringir el registro de menores de edad, por así requirlo las leyes de defensa de los niños u otros grupos protegidos.

Los requisitos legales surgidos por la jurisdicción son una matería de amplia discusión en estos días de Internet. En los viejos días era fácil identificar la jurisdicción competente, pues esta coincidia con el área geografica en que se ubicaba nuestra empresa. Hoy en día en cambio, es necesario considerar jurisdicciones adicionales, ya que nuestros productos pueden ser utilizados en otros países con más facilidad que nunca antes, y el incumplir con los eventuales requisitos legales de otras jurisdicciones pueden causar problemas con la comercialización de nuestras aplicaciones.

Todo esto significa que en aplicaciones de gran escala es conveniente obtener asesoría legal de parte de un escritorio juridico o abogado, tomando lo que este nos indique como requisitos funcionales o no funcionales, según sea el caso.

Líneas Base

Una línea base es el compromiso, negociado y aceptado, que se alcanza con el cliente para que este comprenda que hemos de poner un alto en la captación de necesidades con miras a enfocarnos por unos días, en construir aquello nos ha pedido hasta el día de hoy.

Como estrategia de organización del proyecto, su principal virtud es la de permitir la gestión de requerimientos, al introducir pausas regulares en las exigencias del cliente, con miras a ver primero el logro de las primeras ideas, antes de introducir nuevas variaciones.

Al contar con las líneas base como estrategia de gestión de requisitos, es posible disminuir el riesgo que representan para los proyectos las especificaciones incompletas: simplemente no vamos a aspirar a tener todas las cartas en la mano, vamos a trabajar con lo que tenemos hasta un punto y luego, alcanzados los primeros objetivos, volver a recoger lo que se nos haya escapado la primera vez.

Por lo mismo, es posible también reducir el riesgo de desorden en los requisitos del proyecto. Hay una disciplina en el equipo del trabajo, que se le puede explicar al cliente. Dicho de otra forma, es una forma educada de pedirle paciencia.

Definimos Terminos de Referencia como…

De tanto en tanto nos vamos a encontrar con que la organización que requiere el desarrollo elabora para nosotros un documento de requisitos, en formato libre, al que llaman no sin cierto orgullo «Términos de Referencia». La práctica viene de otras áreas de la ingeniería donde una petición simple de parte del cliente puede ser analizada y convertida en un trabajo completo, con un razonable nivel de calidad.

Sin embargo, en Ingeniería del Software los términos de referencia no pueden ser utilizados con buenos resultados. Típicamente son documentos incompletos, que mezclan requisitos con análisis e incluso con diseño, cuya existencia es señal de acceso limitado a los stakeholders por parte de la organización de desarrollo. En otras palabras: si nos dan Términos de Referencia tendremos problemas más adelante.

El acto de especificar un sistema de software a demostrado repetidamente ser difícil. Es necesario indicar un gran número de aspectos distintos, mantener la diferencia entre requisito y solución, actuar primero a lo ancho, capturar valor de negocio, entre otros puntos que son propios de nuestra profesión y que resultan incompatibles con las premisas detrás de un documento de términos de referencia.

Veamos algunos de estos puntos en detalle. Comencemos por la definición:

Términos de Referencia: Documento elaborado por el cliente con indicaciones de las especificaciones requeridas al sistema de software por desarrollar.

En otras palabras: en un documento de Términos de Referencia el cliente ha querido ahorrarnos a nosotros el trabajo de especificación. Muy amable de su parte, pero si la organización de desarrollo no interviene en la especificación entonces nos enfrentamos a varios problemas:

• Se ha asumido un modelo de ciclo de vida en cascada. Los modelos actuales son iterativos, repitiendo múltiples veces el paso de especificación. Un esquema más rígido, como el cascada, suele incrementar el riesgo de fracaso del proyecto.
• Si el cliente siente que ya ha desarrollado los requisitos a satisfacción puede verse renuente a dedicar esfuerzos nuevos en este asunto. Tendríamos entonces problemas al presupuestar horas para actividades de elicitación de requisitos.
• El documento en si mismo es un problema. Su estructura es necesariamente ad-hoc, independiente de la metodología que se vaya a seguir en el desarrollo. Puede ser difícil de analizar y haber dejado puntos importantes por fuera.

Si solo fuera para tener una idea del proyecto, básicamente cualquier documento o carta es bueno. Sin embargo los términos de referencia vienen con intenciones más amplias: sustituir la especificación profesional por un único documento, valido para el desarrollo así como para el cálculo de la oferta económica. No importa como lo vea, los términos de referencia son un problema.

Sin embargo, los Términos de Referencia son también un hecho. En algunas situaciones incluso son lógicos: en las licitaciones se distribuyen especificaciones para acto seguido requerir ofertas de costo cerrado. Si esto funciona bien en tantos sectores distintos, el cliente puede pensar que ha de valer también para sus proyectos de software.

Por lo anterior será inevitable que nos topemos con estos documentos. Tendremos que desarrollar entonces alguna técnica para sacar el mayor provecho de los mismos, sin importar cuan diferentes sean de caso en caso y de cliente en cliente. A fin de cuentas ellos son el cliente, y uno no puede ser tan descortez de desachar los resultados de su trabajo.

Finalmente me gustaría recordar que todos sin excepción hemos luchado con los términos de referencia de nuestros profesores y preparadores. ¿Cuantas veces en nuestros estudios tuvimos que llevar a cabo un proyecto a partir de un breve enunciado carente de toda norma de calidad? Así como entonces fue difícil producir un programa autenticamente útil a partir de dichas especifiones, aquí nos va a costar mucho trabajo en conseguir satisfacer el cliente si nos atenemos unicamente a lo dicho en los malvados, digo, en los variables Términos de Referencia.

El flujo de eventos del día feliz

Un flujo de eventos consiste en enumerar los pasos que sucesivamente realizan los actores y el sistema en el contexto de un caso de uso. Es decir, que un flujo de eventos es en su forma más básica un simple listado de acciones, que corresponden con un caso de uso en concreto.

Si pensamos un poco en el tema nos podemos percatar que la funcionalidad promedio de un caso de uso ha de tener bifurcaciones e incluso bucles. Esto es natural pensarlo ya que hay una similitud muy fuerte entre la noción de algoritmo y la de flujo de eventos vistos estos como listado de pasos.

Sin embargo, a diferencia de las notaciones formales utilizadas para expresar algoritmos, los flujos de eventos se construyen en lenguaje natural, lo cual impone limitaciones sobre cuan precisamente podemos indicar condiciones y bifurcaciones sin comprometer la claridad.

La solución a este problema claro esta, es la de tener más de un flujo de eventos. Tendremos uno sencillo y claro, que exprese lo que ha de ocurrir en el caso más probable y a su vez, tendremos otros flujos alternativos que lidien con las condiciones de error o casos que requieran bifurcación.

Al flujo de eventos principal, ese que contiene el caso más probable, se le llama Flujo de Eventos del Día Feliz, como forma de hacer referencia a la ausencia de condiciones de error. En otras palabras, le llamamos día feliz ya que en este flujo de eventos principal vamos a asumir que todo ocurre de la mejor forma: el actor tiene disponible la información y la indica sin fallas, el sistema puede completar todas las operaciones y así sucesivamente para cada posible desviación. En el flujo del día feliz simplemente todo ocurre correctamente.

Definimos retrabajo como…

La elaboración de un diseño o producto, conforme a unas especificaciones conocidas, da lugar a la posibilidad de fallar en el cumplimiento de lo requerido. Toda diferencia entre lo que se nos pidió y lo que estamos entregando como resultado de nuestro trabajo es considerado un fallo de calidad y se le suele llamar inconformidad.

Si la inconformidad es muy grave y compromete la aceptación del producto por parte del cliente, es necesario dedicar esfuerzos adicionales en lograr que el producto sea conforme a lo especificado. A este esfuerzo adicional es a lo que llamamos retrabajo.

Técnicamente como para el glosario:

Inconformidad. Fallo de calidad definido como la desviación del producto de su especificación.

Y también:

Retrabajo. Esfuerzo adicional necesario para la corrección de una inconformidad en algún producto.

El problema que surge con el retrabajo es obvio: es un esfuerzo adicional que no puede en buena lid ser cobrado al cliente, pero que es necesario para que este quede conforme con lo que hemos hecho para él. La idea es entonces minimizar la cantidad de retrabajo en el que incurramos, objetivo deseado pero dificil de lograr sin un adecuado sistema de gestión de calidad.

¿Qué son las llamadas Mejores Prácticas?

Las mejores prácticas son características reconocibles de los procesos de las organizaciones de éxito. Suelen ser conductas observables, llenas de sentido común; que al estar presentes en las mejores empresas de cada sector, se piensa que son parte del éxito de dichas empresas. Por supuesto, se piensa también que de asumirse, toda empresa se puede beneficiar, por lo que la predica en pos de las mejores prácticas es parte importante de la planificación a largo plazo de las organizaciones que desean mejorar y crecer.

A nivel personal, podemos establecer un símil con los consejos más comunes sobre como llevar una vida sana y exitosa. Consejos tales como «pensar antes de actual» o bien el elemental «dormir lo suficiente cada noche» son el equivalente de las mejores prácticas, aplicadas a como conducir la propia vida.

En el caso de las empresas, se confía en los institutos de investigación de cada sector, quienes identifican sistemáticamente las prácticas en uso, con el objetivo de publicar catálogos de mejores prácticas, que sean apropiadas para el sector industrial que se este considerando. Dichos catálogos suelen ser de acceso libre y son conocidos bajo diferentes denominaciones, como si se estuviera hablando de cosas diferentes en cada sector. Pero no hay confusión que valga: para todo sector valen distintas mejores prácticas, pero llámense como se quieran llamar, todas son mejores prácticas y poco más.

Cuando se esta diseñando un proceso empresarial, es útil considerar las mejores prácticas conocidas del sector o actividad en la que el proceso vive. Dado que existen gran cantidad de sectores, el analista de procesos puede beneficiarse de conocer que se considera como una buena idea, dando entonces una base sistemática para identificar objetivos de diseño para los procesos, más allá de cubrir las necesidades inmediatas demandadas por los clientes.

He de hacer notar también, que muchas de las mejores prácticas pueden ser apoyadas por sistemas de información apropiados; o dicho de otra forma, que hoy en día existen gran cantidad de sistemas de información, muchos de ellos construidos para dar cumplimiento a una o más de las mejores prácticas de sector destino del sistema.

Así que el asunto de las prácticas conviene tenerlo en mente.

Tipos de Datos Primitivos de UML

En parte de la especificación de UML se detalla los llamados tipos de datos primitivos, que son los tipos mínimos que conocemos aún antes de comenzar a definir clases en nuestros modelos. La especificación nos habla de cuatro tipos primitivos:

• Integer: números enteros tal como los conocemos. Incluyen tanto los positivos como los enteros así como el cero.
• Boolean: tipo de dato lógico, acepta los valores true y false; representado los valores de una expresión verdadero/falso.
• String: tipo de dato de texto o de cadena de caracteres. El nombre viene de la palabra inglesa cadena.
• UnlimitedNatural: Son enteros igual o mayores a cero, el valor de infinito se denota con un asterisco: *.

El siguiente diagrama de clases es tomado de la especificación de UML (conocida como meta-modelo de UML) y presenta los tipos de datos primitivos como parte del paquete respectivo: UML::AuxilliaryConstructs::PrimitiveTypes:

Fig. 1 – Diagrama del paquete PrimitiveTypes del Meta-modelo de UML

Estos tipos de datos primitivos son los únicos que legitimamente vamos a utilizar en la sección de atributos de nuestras clases; para todos los restantes elementos de datos se debe preferir por presentar una relación entre clases. Es decir, que las variables que colocamos en la sección de atributos de las clases van a ser casi sin excepción, de uno de los tipos primitivos: Integer, Boolean, String, UnlimitedNatural.

Definimos Actor como…

En teatro, un actor representa un papel según las indicaciones de un guión. Nosotros tomamos esa metáfora para indicar que un agente externo realiza una acción sobre el sistema, acción esta que puede ser capturada como un guión que sea parte de un caso de uso.

Es interesante observar que llamamos actor a toda entidad externa que demanda funcionalidad del sistema, ya sea un ser humano o un sistema de software; por lo cual el término usuario puede ser un poco limitado.

Normalmente representamos a los actores de nuestro sistema por medio de la simple imagen de una figura humana de rayas. pero dada la flexibilidad del UML es posible representarlo también como una clase estereotipada o bien, con una imagen provista por nosotros según algún criterio artístico.

La siguiente imagen ilustra las tres formas que he mencionado:

Fig. 1 – Tres formas de representar un Actor en un diagrama de UML

La especificación UML lidía con el lenguaje visual pero como en otras ocasiones esta no es más que una fracción de lo que queremos decir sobre nuestros modelos, en este caso, es de interes capturar información adicional de nuestros actores, para lo cual podemos pensar en tener una tabla como la siguiente para cada uno de ellos:

Nombre: Actor
Representado por: Nombre y datos de contacto del stakeholder que puede responder preguntas sobre este actor
Facilidades de comunicación: Protocolos o estilos de comunicación que el actor entiende.
Relación con otros actores: Relaciones de herencia o dependencia entre actores

Tabla 1 – Definición de un Actor

La definición anterior la podemos llevar en el cuerpo de comentarios de nuestro modelador UML y exportarlo a un documento de texto cada vez que sea necesario.

Los actores nos sirven para capturar a los usuarios del sistema pero también, son la forma en la que podemos expresar el contexto del mismo. Es decir, que los actores toman el lugar de cualquier entidad de interes con la que nuestro sistema interactua.

Pese a lo anterior, ciertas cosas generalmente vistas como externas al sistema no son considerados buenos actores. Los sistemas de persistencia como las bases de datos o los archivos, si bien externos, no son actores. Entre otras cosas, debido a que estos no demandan funcionalidad del sistema (son pasivos respecto a él) además, es de interes que estos elementos estén bajo la definición del diseño de nuestro sistema, por lo que puede resultar de más provecho considerarlos parte del mismo.

Capacidades y Competencias

Cualquier organización, sin importar su área de trabajo, puede ser modelada como un conjunto de procesos, que buscan elaborar uno o más productos que estén de acuerdo con las especificaciones dadas. Esta definición abarca no solo a las empresas de software dedicadas al desarrollo, sino también a las dedicadas al servicio, a la adquisición o a la consultoría.

Incluso es posible pensar que la definición dada abarca a todas las organizaciones, sin importar si de dedican al software o no, sin importar si se dedican a la manufactura o al sector servicios e incluso, sin importar si se dedican a la búsqueda de un beneficio económico o por el contrario son una entidad estatal o de beneficencia. Todas las organizaciones persiguen objetivos, los cuales pueden ser caracterizados como productos de procesos realizados en conformidad con las metas y especificaciones dadas.

Entonces, podemos definir sobre esta búsqueda de la calidad, los siguientes dos conceptos:

Capacidad: habilidad de la organización, sistema o proceso, para realizar un producto que cumpla con sus requisitos. (ISO 3534-2)

Y también

Competencia: capacidad demostrada de aplicar conocimiento y habilidades. (ISO 19011)

Nuestras organizaciones deben contar con competencias suficientes para competir en el mercado, de lo contrario quedarán fuera de este. De ahí entonces, que el desarrollo de dichas competencias sea un interés constante en la dirección estratégica de toda organización, en particular de aquellas dedicadas al desarrollo de software.

Lo que llamamos mejores prácticas o simplemente prácticas, son referencias a las distintas capacidades que se han identificado como presentes en las organizaciones con éxito; complementadas cada una con la descripción de sus objetivos y productos típicos.

Existen gran variedad de mejores prácticas, por lo que en la industria han surgido varios esfuerzos por organizar estas en paquetes que faciliten su estudio y de ser posible, su asimilación por nuestras organizaciones. El objetivo de dichos paquetes de mejores prácticas, es la de establecer una ruta de mejora de los procesos, que vaya desde lo simple a lo más complejo, dando así una guía para los esfuerzos de mejorar que iniciemos.