archivo

Archivo de la etiqueta: Métrica v.3

Una de las claves para sacar adelante cualquier trabajo (y un proyecto no es más que un tipo de trabajo más), con su complejidad y sus características inherentes, es dividirlo en una serie de tareas que sean manejables: divide y vencerás.

El enfoque clásico o predictivo supuso el primer avance en ese sentido, si bien lo que hizo fue darle formalidad a lo que carecía de ella porque la división en tareas más simples en el desarrollo de software existe desde sus mismos inicios.

Esa división en procesos, actividades y tareas la podemos ver en Métrica v3, en versiones anteriores, en cualquier otra metodología basada en enfoques clásicos o en las propias definiciones genéricas de esa estrategia.

El inconveniente que se plantea es que divide en partes las actividades pero no el producto. Sobre esa aproximación inicial surgieron nuevas estrategias que tenían como objetivo descomponer el producto en partes y sobre cada una de ellas realizar una división de las actividades. Esto dio lugar a enfoques de tipo teórico como los desarrollos en espiral o más tangibles como los desarrollos iterativos incrementales.

Con este tipo de estrategias se puso en primer plano los conceptos de feedback y retrospectiva: conocimiento adquirido como consecuencia de la experiencia sobre versiones reales del producto (ya sea en producción o no) y la mejora continua de las prácticas y enfoque del proyecto.

El siguiente paso fue hacer que la descomposición del producto fuera en trozos más pequeños definiéndose para ello sprints de duración fija o variable pero que en cualquier caso iban a ser de corta duración. En este contexto el feedback y la retrospectiva ganan en intensidad, se realizan cada poco tiempo y el producto está preparado para adaptarse al cambio.

En esta evolución se ha pasado de la especificación del producto a su visión: se tiene una colección de tareas a realizar que se va modificando conforme avanza el proyecto y solo se estudian en detalle cuando se está preparando la siguiente iteración.

Uno de los grandes problemas del desarrollo de software en la Administración Pública lo tiene la utilización generalizada del ciclo de vida clásico o en cascada, no hago referencia directa a MÉTRICA v.3 ya que la misma no deja de ser un ordenación particular de dicho ciclo de vida que además es lo suficientemente abierta como para que una inmensa mayoría de los proyectos desarrollados en cascada sean compatibles con la misma.

¿Por qué es un problema? Porque está más que demostrado que el ciclo de vida en cascada no da buenos resultados. Y no es algo que yo haya leído, sino que lo he sufrido y estoy sufriendo en los proyectos que gestiono. Desarrollar en cascada es un error, yo le he estado cometiendo durante años y me ha servido para darme cuenta que la solución pasa por la aplicación de otras metodologías.

Sin embargo la Administración Pública apostó por MÉTRICA, como metodología oficial para el desarrollo de sistemas de información y las razones son varias:

– El ciclo de vida en cascada era (y lo sigue siendo) la metodología más utilizada y más implantada, en proyectos dentro y fuera de la Administración Pública.

– La Ley de Contratos, tiene una finalidad fundamental que no es otra que la de fiscalizar la actuación de la Administración y propiciar la concurrencia con igualdad de oportunidades de los licitadores a los concursos que se convoquen. Sin embargo tiene como inconveniente de que se trata de un procedimiento administrativo que lleva meses, desde que se elaboran los pliegos hasta que se realiza la adjudicación y posteriormente se formaliza (firma) el contrato.

¿Cuál es el inconveniente? Pues que en muchos casos se valora el sistema de información a desarrollar sin conocer en detalle los requisitos funcionales y los casos de uso o dicho de otra forma, sin conocer en profundidad qué es lo que quiere el área usuaria del proceso o procesos que se van a informatizar.

Para solucionar esto habría que realizar un preanálisis del proyecto, para conocer el alcance global que se persigue y entrar en un cierto grado de detalle a nivel de requisitos e interacción del sistema con los diferentes actores (usuarios y otros sistemas). A partir de ahí sí que es posible realizar una valoración más acorde con la realidad y tomar la decisión sobre qué metodología es más adecuada para realizar el proyecto, teniendo en cuenta las características de los usuarios y la divisibilidad del mismo en bloques funcionales que faciliten los desarrollos de manera iterativa e incremental.

Esto querría decir que el preanálisis habría que desarrollarlo con recursos internos o bien contratarlo, siendo la segunda opción la más común debido a que, por regla general, los Departamentos de Informática de la Administración Pública no están dimensionados acorde a las responsabilidades y funciones que tienen que acometer.

Si se contrata ese trabajo quiere decir que el desarrollo del sistema de información se tendría que contratar en otro procedimiento, por lo que como mínimo habría que esperar cuatro o cinco meses para poder empezar (cuando no un año o más, ya que dependerá del momento del año en el que se ha terminado el trabajo, la disponibilidad presupuestaria, etc…). Todos sabemos cómo son los usuarios y en un plazo de seis meses a un año donde ayer dije una cosa, hoy diré otra y salvo que esa dinámica adaptativa se haya tenido en cuenta en el presupuesto, el mismo partirá con un déficit que empezará a poner dificultades desde el principio.

– Otro aspecto es la propia dinámica de funcionamiento de la Administración. Lo que hoy puede ser prioritario mañana puede dejar de serlo, lo que implica que recursos inicialmente previstos para el proyecto desde el área usuaria, pueden desaparecer o ver mermada su participación. A lo anterior hay que sumarle el alto índice de rotación de persona que existe. Esta casuística es un arma de doble filo, ya que por un lado aconseja cerrar unos requisitos para intentar “blindar” un alcance de los trabajos y poder desarrollar el proyecto y por otro ese blindaje finalmente no sirve de nada porque si hay aspectos funcionales que no han sido bien recogidos o bien cambian con el nuevo personal que se asigne al proyecto se requerirán cambios en los requisitos ya definidos, los cuales se producirán incluso en etapas tardías del desarrollo.

El camino para desarrollar proyectos con una mayor probabilidad de éxito pasa por un desarrollo iterativo e incremental, plásmándose este en la metodología que se considere mas adecuada a las circunstancias del proyecto. Es necesario hacer ese análisis ya que existen ciertas metodologías ágiles que por el alto grado de participación del usuario que requieren no son realistas de aplicar en muchos casos, por la dinámica de funcionamiento de al Administración que expliqué antes (lo cual no quiere decir que haya situaciones concretas donde sean posibles).

Es totalmente posible desarrollar este tipo de proyectos, pero es fundamental para ello cambiar la forma de enfocarlos, es necesario conocer qué se quiere obtener, pero plantearlo como una carrera por etapas. Si un ciclista trata de hacer todo el recorrido del Tour de Francia del tirón no podrá, si lo hace por etapas le costará trabajo llegar hasta el final pero por lo menos tendrá una oportunidad de conseguirlo. Y esto es válido tanto si se contrata todo el desarrollo de una vez como si se contrata primero el análisis o preanálisis y después a construcción (teniendo en cuenta que al coste calculado hay que añadirle un porcentaje por el proceso adaptativo del sistema de información a las necesidade del usuario en cada iteración).

Este enfoque del desarrollo de software ha sido el más utilizado y en la actualidad, pese a la aparición de metodologías ágiles, sigue siendo la solución predominante, si bien, en cada organización o en cada de proyecto se puede llevar a cabo con ciertas variantes.

Además, en función del autor, las fases en que se divide el ciclo de vida clásico, pueden ser diferentes. Para este artículo voy a utilizar las que estableció Roger Pressman (no obstante para la descripción del alcance de las mismas voy a basarme principalmente en Métrica V.3, pero adaptándome a esta clasificación), si bien otras muchas alternativas podrían ser válidas:

– Análisis: Esta fase comprendería desde la posible obtención de unos objetivos o requisitos iniciales para determinar la viabilidad del sistema y escrutar las distintas alternativas de solución, pasando por la elaboración del catálogo de requisitos, hasta la realización de casos de uso, prototipado de pantallas e informes, como una primera especificación del plan de pruebas.

– Diseño: El análisis describe el sistema sin entrar en características propias de la implementación, es en esta fase donde se adapta ese análisis generalista a la solución concreta que se quiere llevar a cabo, definiéndose la arquitectura general del sistema de información, su división en subsistemas de diseño, el modelo de datos lógico, el modelo de clases (en el caso de un diseño orientado a objetos), la especificación detallada del plan de pruebas, etc…

– Codificación: En esta fase se realiza la construcción del sistema de información y las pruebas relacionadas con dicho proceso, como son las unitarias, integración y de sistema, así como otras actividades propias de las etapas finales de un desarrollo como es la realización de la carga inicial de datos (si bien en muchos casos se deja esto para cuando el producto está en producción) y/o la construcción del procedimiento de migración.

– Pruebas: En esta etapa se realizaría la instalación del sistema en un entorno de pruebas lo más parecido posible al de producción (entorno de preproducción) donde se realizarían las pruebas de implantación (que verifican principalmente aspectos no funcionales) y las de aceptación, donde los usuarios validan que el sistema hace lo que realmente esperaban (sin que se deba olvidar que los límites los establecen los modelos realizados previamente y que han debido ser validados). Por último se realizaría la implantación del sistema en el entorno de producción.

– Mantenimiento: Una vez que el sistema se encuentra en producción, se realizarán sobre el mismo diversas tareas de mantenimiento, que en función de su naturaleza se clasifican en correctivos, evolutivos, adaptativos y perfectivos. Estas tareas de mantenimiento serán consecuencia de incidencias y peticiones reportadas por los usuarios y los directores usuarios.

En el ciclo de vida clásico en función de las modificaciones y/o correcciones que se realizan en una etapa será necesario la vuelta a fases previas para hacer coherente el proceso de desarrollo y los modelos.

El principal inconveniente que se le ha achacado siempre a este tipo de ciclo de vida es que los usuarios tardan demasiado en ver los resultados, lo que hace que el tiempo transcurrido desde que se define el sistema hasta que está disponible sea lo suficientemente amplio como para que hayan ocurrido muchas cosas: desde que no estén la mayoría de las personas que participaron en la especificación, como cambios en los procesos, cambios de criterio, etc…, lo que provoca a hacer replantemiento de los requisitos en etapas más tardías del desarrollo con el coste que eso conlleva (un refinamiento de los requisitos es razonable siempre y cuando no se superen unos límites) y a que muy probablemente el sistema finalmente disponible esté alejado de lo que realmente quiere el conjunto de usuarios en estos momentos que es distinto a lo que querían hace meses y a lo que querrán dentro de otros tantos.

Otro inconveniente ligado con el anterior es que al tratarse el sistema como un todo, los modelos generados (catálogo de requisitos, casos de uso, etc…) serán lo suficientemente grandes como para no poder ser revisados y comprendidos en toda su magnitud, sobre todo por personal no informático. Esto crea una incertidumbre sobre los requisitos del sistema que más adelante traerá problemas.

No todo es malo en este modelo, ya que describe un procedimiento racional y ordenado de desarrollo de software, la clave para su éxito o su fracaso es como se gobierne el mismo y las circunstancias que rodeen al proyecto en el momento de su ejecución. Además, existen variantes que ofrecen una mayor flexibilidad al mismo y que permite reducir sus riesgos.

¿Sirven para algo los casos de uso? En una charla con un grupo de amigos, uno de ellos hizo esa pregunta y se hicieron unos cuantos segundos de silencio.

Supongo que cada uno tendrá su experiencia y por tanto los casos de uso tendrán sus detractores y defensores. No es el objeto de este artículo analizar quién puede tener razón sino tan solo ofrecer mi punto de vista, acertado o equivocado.

Los casos de uso según Métrica versión 3, tendrían un doble propósito:

– Servir de herramienta para la especificación de requisitos ya que ayuda a los usuarios a reducir la complejidad de abstraer la aplicación que quieren que se desarrolle (o se mantenga).
– Guiar el proceso de desarrollo.

Tal vez no haya tenido suerte, pero en todo el tiempo que llevo en este negocio, no he tenido la oportunidad de estar en proyectos donde los casos de uso hayan resultado decisivos para la especificación de requisitos (es más, en la mayoría de las situaciones ha sido un producto que ha derivado de los requisitos o que se ha obtenido posteriormente) o para el proceso de desarrollo.

En lo que a la especificación de requisitos se refiere, los usuarios prefieren la especificación de requisitos en lenguaje natural (y ellos poder discutirlos) y trabajar con posibles interfaces de usuario. Los diagramas de casos de uso siguen siendo de otra galaxia y hay que explicárselos muy bien para que lo entiendan.

En mi opinión, para que los casos de uso tengan utilidad real hay que trabajar bien los diagramas y sobre todo realizar la especificación de cada caso de uso y eso requiere un gran esfuerzo importante en el momento en que la aplicación tiene una cierta complejidad y si se quiere que realmente el usuario entienda paso a paso las distintas funcionalidades que el desarrollador ha ido detectando en las distintas sesiones de recopilación de requisitos. Por supuesto, en todo lo anterior, es conveniente que el usuario esté asistido si así lo requiere, ya que es posible que tenga alguna duda en la interpretación de lo que está viendo y leyendo.

El término ingeniería del software resulta muy controvertido debido a la existencia de muchos detractores que ven más adecuados otros términos como por ejemplo el término desarrollo de software.

De hecho pese a que creo en el concepto uso con más frecuencia el de desarrollo de software.

La ingeniería del software es una disciplina que tiene como objetivo que el software que se desarrolla seaa de calidad (en todos los sentidos, no solo que verifique los requisitos funcionales) a través de un proceso que sea productivo para el que lo implementa.

Hay muchas definiciones académicas o de autores conocidos de este término. Me gusta mucho la de Bauer (1972) “Ingeniería del software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales”.

Detrás de la ingeniería del software hay procesos, estrategias, tácticas, metodologías, actitudes, prácticas y herramientas que lleven desde la idea inicial de un programa a un producto instalable, que funcione y sea mantenible. La ingeniería del software es la suma de todo eso adaptada con intención al contexto real de un proyecto de desarrollo de software.

Tengas una visión ágil o no, al final aplicas un enfoque, un forma de trabajar, precisamente la ausencia de ese enfoque y la falta de disciplina a la hora de orientar los trabajos hacia el contexto concreto que rodea al desarrollo ha dado lugar a la crisis del software o lo que es lo mismo, productos de baja calidad, costosos y fuera de plazo. Estas características están presentes en gran parte de los sistemas con los que trabajamos, se puede mirar para otro lado, pero la realidad es esta por lo que la crisis del software no es un concepto del pasado sino algo muy presente y desgraciadamente y, si no cambian las cosas, con bastante futuro.

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos.

Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos:

– Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambios en las necesidades del usuario.”

– Mantenimiento adaptativo: “Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios en la configuración del hardware, software de base, gestores de bases de datos, comunicaciones, etc…”.

Con las definiciones por delante resulta bastante sencillo discernir un tipo de mantenimiento de otro, ya que el primero está centrado en un cambio en las necesidades del usuario o lo que es lo mismo, en una modificación de los requisitos funcionales de la aplicación (por muy pequeños o grandes que sean) y el segundo se basa en los cambios en cualquiera de los elementos que conforman el entorno sobre el que funciona el programa, a los ejemplos que indica Métrica V.3, yo añadiría los servidores de aplicaciones, servidores web e incluso las interfaces con terceros sistemas, es decir, si una aplicación se comunica con otra por servicios web y ésta modifica la interfaz el cambio a realizar en la aplicación es de carácter adaptativo ya que el requisito funcional (que es comunicarse con ese tercer sistema) no ha variado.

Ya lo dice MÉTRICA v.3. Para que el Plan de sistemas de información tenga éxito es necesario contar con el apoyo de los niveles más altos de la organización.

Eso dice MÉTRICA v.3 y mi experiencia dice que si durante y después del proyecto no se prevé apoyo por parte de la alta dirección de la organización, ni se planteéis la realización del Plan de Sistemas de Información.

La alta dirección, además de ser entrevistada en el proyecto para obtener sus necesidades, debe proporcionar los medios oportunos para que todas las personas clave de la organización sean entrevistadas y se impliquen en el proyecto y, además, una vez finalizado el proyecto, proporcionar los recursos económicos y humanos necesarios para realizar el plan de acción.