archivo

Archivo de la etiqueta: ingeniería del software

Alan Curtis Kay lleva más de cuarenta años en el negocio. Ha trabajado en el sector privado en empresas como Xerox, Atari, Apple, Walt Disney y HP y ha sido profesor universitario (UCLA, MIT, etc…). Es considerado como uno de los pioneros de la programación orientada a objetos y uno de los padres de las arquitecturas modernas de interfaces gráficas de usuario.

Que una persona con ese Currículum realice la siguiente reflexión es para tenerlo muy en cuenta: “La mayoría del software actual se parece mucho a las pirámides egipcias con millones de ladrillos apilados uno encima de otro, sin integridad estructura y realizados mediante fuerza bruta y miles de esclavos”.

Es una crítica dura a gran parte del software que se realizaba hace unos años y que todavía se realiza. La crisis del software es un término totalmente vigente como también lo es que la ingeniería del software es parte del antídoto para combatirlas.

Antes de desarrollar un software hay que tener una estrategia y unos procesos que apoyándose en una metodología adecuada, en la experiencia y habilidades del equipo de proyecto y en unas relaciones adecuadas con el área usuaria permitan desarrollar un producto de calidad (y por tanto mantenible) y con un esfuerzo adecuado a la naturaleza del trabajo a realizar.

En el nivel 3 de CMMI estamos analizando diferentes áreas de proceso que lo que hacen es especificar un marco de trabajo para la realización de determinadas tareas dentro del proceso de desarrollo de software.

Esta estrategia a nivel organizativo para la obtención de productos software requiere de procesos que se encarguen de verificar la calidad y adecuación a su finalidad de los diferentes artefactos intermedios que se vayan obteniendo así como el resultado final, es decir, no se trata solo de definir los caminos que se pueden elegir a la hora realizar el desarrollo, sino también de determinar los controles a realizar para comprobar si las diferentes piezas utilizadas en el proceso de ingeniería del software y de construcción (al fin y al cabo una parte más del mismo proceso de ingeniería) cumplen su propósito y los requisitos establecidos.

Los citados en el anterior párrafo, son los objetivos fundamentales de este área de proceso. La diferencia respecto al área de proceso de validación, que trataremos más adelante, es que en la verificación comprobamos si el estamos desarrollando (construyendo) el producto de manera adecuada (es decir, este artefacto, ¿está construido cómo debe?) y en la validación se comprueba si se está desarrollando el producto correcto (que no es lo mismo). Ambas áreas de proceso van de la mano, aunque tengan finalidades distintas.

Una organización es madura si es capaz de detectar desviaciones lo más cerca posible de la causa o causas que lo provocan, ya que cuanto más nos alejemos del foco y/o más tardemos en realizar acciones correctoras, más esfuerzo se requerirá para invertir esta tendencia.

En este área de proceso se debe establecer:

– Los artefactos que se deben verificar, pudiendo llegar a definirse (como en las otras areas de proceso) diferentes escenarios en función del tipo de proyecto o incluso establecer las condiciones que debe cumplir un artefacto para ser verificado.

– El entorno de verificación, es decir, dónde y qué medios se van a aplicar para realizar las diferentes verificaciones.

– Los procedimientos de verificación, es decir, cómo y que criterios se van a seguir para determinar si un artefacto cumple con su finalidad. La metodología determina que el procedimiento debe basarse en un mecanismo de revisión por pares en cual se suele incluir el análisis de los resultados de la verificación y la determinación de las acciones correctoras.

Lo ideal es que responsables técnicos del cliente, usuarios y equipo de desarrollo formen un equipo, cada uno con sus roles, pero un equipo, sin embargo en la mayoría de las ocasiones no se dan las circunstancias para hacer eso posible, de manera que por lo menos hay que intentar conseguir que cada grupo funcione como un equipo, que persigan un objetivo general común (obtener un sistema de información que satisfaga las expectativas del usuario, pero no a cualquier coste, sino al presupuestado y con los plazos fijados, siempre y cuando, claro está, ambos estén adecuadamente dimensionados a la naturaleza del proyecto) y existir unos mecanismos adecuados de comunicación y colaboración entre los mismos.

En el momento en que los objetivos individuales de las personas o de estos equipos se impone al objetivo general se produce la ruptura de la unidad, afectando primero a la comunicación y más adelante a la confianza.

Cada grupo puede tener sus propios intereses, pero se tiene que intentar que los mismos estén siempre detrás de los objetivos generales. Si hay problemas se deben exponer al grupo por si fuera necesario hacer algún ajuste en esos objetivos generales.

Lo cierto es que por regla general, cada uno de los grupos de personas de un proyecto de desarrollo de software suelen funcionar poniendo sus objetivos individuales a la altura de los objetivos generales (o por encima) y esa es una de las causas que provoca un incremento de la complejidad en los proyectos.

Lo peor de todo es que se sabe que ese funcionamiento es nocivo para los intereses generales del trabajo a ejecutar pero se prefiere que cada uno desempeñe su rol en el proyecto y que la comunicación solo se realice en momentos puntuales (sobre todo en fase de análisis en proyectos con ciclo de vida clásico o en cascada o cuando en modelos iterativos e incrementales se definen entregas con un tiempo de desarrollo amplio).

Los requisitos funcionales y no funcionales de un sistema de información determinan el mapa inicial de lo que los usuarios esperan del sistema. Se trata de una predicción sobre lo que que quieren y que después tendrán que constrastar con el producto final.

Lo normal es que exista una diferencia entre una versión de un producto y lo que se esperaba de ella, por lo que después son necesarios mecanismos de ajustes que disminuyan esa distancia a unos umbrales razonables o que la eliminen. Lo ideal es que esa diferencia sea la menor posible y los analistas funcionales y orgánicos y los responsables de codificar el proyecto intenten que así sea, sin embargo los proyectos de desarrollo de software están sometidos a muchos factores que afectan negativamente a ese objetivo.

En cualquier caso, los requisitos representan necesidades y expectativas de los usuarios y es necesario, por tanto, conocerlos y tenerlos en cuenta como referencia en el desarrollo del producto software.

Por tanto, este área de proceso requiere que los requisitos estén perfectamente identificados y, además, sean conocidos y entendidos por todos los implicados en el proyecto (equipo de proyecto, usuarios, responsable técnicos del cliente, etc…).

Otro de los requerimientos de este área es que se tenga control sobre el cambio en los requisitos, para ello es necesario que solo un grupo reducido de personas tengan la capacidad de decidir en ese sentido.

Esto no quiere decir que cualquier usuario no pueda proponer cambios, antes al contrario, cualquier aportación debe ser acogida de forma positiva, el matiz en este caso, es que esas propuestas deben ser analizadas por unos pocos (que se entienden que son designados como expertos del proceso o procesos que se informatizan) y que con el asesoramiento de los técnicos software (sería lo más recomendable) toman la decisión sobre qué cambios realizar, cuáles no y en definitiva, cuáles son las prioridades.

Ante una decisión de cambio en los requisitos, este área de proceso tiene el requerimiento de que el resto de artefactos/entregables del proyecto se mantengan consistentes.

Por este motivo hay que tener mucho cuidado a la hora de definir los entregables documentales de un proyecto, ya que cuántos más y más complejos sean, mayor será el esfuerzo necesario para ponerlos consistentes. Es importante apoyarse en herramientas CASE para facilitar la consecución de este objetivo.

Otro requerimiento es la trazabilidad bidireccional y sobre esto habría mucho que hablar. Si se toma al pie de la letra quiere decir que debería poder conocer todos los componentes de ingeniería del software y del producto software (a nivel de clase) asociados a un requisito y también en el sentido contrario, es decir, que partir de una clase se sepa a qué requisito o requisitos puede afectar un cambio en la misma. El objetivo de esto es poder realizar un análisis de impacto y servir también de soporte para la detección de inconsistencias entre los requisitos y los productos derivados del proyecto (incluido el propio sistema de información).

Sin embargo, esta trazabilidad bidireccional resulta costosa de conseguir y no resultaría aconsejable su aplicación en determinados tipos de proyectos (se estaría matando moscas a cañonazos) y en otros, llegar a nivel de clase en el código no aportaría mucho ya que la organización en capas, de las clases, etc… viene condicionada por el generador de código utilizado y el framework.

Para poder respectar en lo posible este objetivo, es importante definir un nivel de entregables documentales acordes a la naturaleza del proyecto (maś entregables, más complejidad, así que hay que tener cuidado con esto) y tener un conocimiento del framework de desarrollo y de la arquitectura de la aplicación, de manera que se sepa de manera rápida donde hay que mirar para conocer el impacto de la modificación de determinados requisitos (lo que se hace es mirar de más arriba la codificación de la aplicación y no entrar a un detalle a nivel de clase). También resulta fundamental un código lo más claro y limpio posible.

Sobre la trazabilidad lo importante, entiendo que debe ser quedarse con el espíritu de la misma y tener unos procedimientos en el proyecto que permitan hacer un análisis de impacto y análisis de consistencia en un tiempo razonable. Hay que recordar que CMMI establece un modelo de referencia, determina el qué pero no el cómo.

Existe una diferencia entre la percepción del desarrollador, la percepción de los usuarios y el universo de discurso. Hay que tener en cuenta que los usuarios son expertos en los procesos que manejan y aunque el desarrollador conozca bien el negocio, cada organización es diferente y lo que en una funciona, en otra no necesariamente tiene que dar los mismos resultados.

También hay que tener en cuenta que el desarrollador es el que conoce las limitaciones de la tecnología que va a utilizar, en el sentido sobre todo de la dificultad y coste de los que se pide (más que en el sentido de si se puede hacer o no), por lo que su percepción también es valiosa.

Habrá proyectos donde diferentes desarrolladores participen en las etapas de análisis y cada uno de ellos puede entender el problema de una manera, no necesariamente diferentes, pero tampoco idénticas.

Visiones diferentes requieren del consenso y comunicación entre usuarios y desarrolladores para que se pueda reducir esa diferencia entre lo que se cree que se quiere y lo que se quiere realmente, objetivo que necesitará también saber elegir en cada proyecto de forma adecuada la proporción de la visión de los usuarios y desarrolladores que llevará la fórmula (además de seleccionar los ingredientes que aporta cada uno).

Richard (Dick) E. Fairley es una profesor universitario y autor americano especialista en ingeniería del software y sobre tema comenta lo siguiente (traducción libre): “En el sentido más real, el ingeniero de software convierte modelos de situaciones físicas en software. El mapeo entre el modelo y la realidad que ha sido modelada se conoce con el nombre de distancia intelectual entre el problema y la solución computerizada del problema.

Uno de los objetivos principales de la ingeniería del software consiste en diseñar productos software que minimicen la distancia intelectual entre el problema y la solución; sin embargo, la variedad de posibles soluciones en el desarrollo de software solo está limitada por la creatividad e ingenuidad del programador. En muchos casos no está claro cuál de las soluciones es la que minimizará la distancia intelectual y a menudo diferentes soluciones podrán minimizar diferentes dimensiones de la distancia intelectual”

La mejora de la eficiencia en el proceso de desarrollo de software busca la obtención de una base para la consecución de productos software de calidad (es importante que se tenga en cuenta que ninguna metodología o modelo o garantiza nada, lo único que hace es proporcionar un camino del que si no te sales y ejecutas las tareas de manera adecuada te permite alcanzar como mínimo unos umbrales objetivo para la misma), que se realizan en un entorno controlado (entendiéndose el control como el hecho de que tu influencia sobre el proyecto y sobre todo el entorno sea mayor que la que el proyecto ejerce sobre ti) y que trata de cumplir presupuestos y plazos (siempre y cuando estos sean acordes con la naturaleza del proyecto).

Visto de esta forma a nadie se le escapa que una organización que proporciona servicios de desarrollo de software tenga como objetivo una mejora continua de sus procesos, es decir, de cómo hace las cosas. Esto resulta lógico y razonable ya que un mercado con tanta competencia y en donde actualmente existe crisis económica, si no evolucionas, si no mejoras, si no te adaptas, estás condenado a sufrir mucho, salvo que tengas una posición dominante en algún segmento de mercado que permita tomarte cierto tipo de licencias.

CMMI no es más que la conjunción de una serie de modelos (integración de buenas prácticas, estándares, etc..) orientados a la mejora de determinados servicios (a través de la mejora los procesos a través de los cuales se gestionan/controlan/implementan los mismos): desarrollo de productos y servicios, adquisición de productos y servicios y la gestión y entrega de servicios (cada uno de estos servicios tiene su propia constelación de procesos, en este artículo y los que voy a ir escribiendo sobre esta temática me voy a centrar en los relacionados con el desarrollo de software).

Surgió en los Estados Unidos como medio para combatir la crisis del software que se producía de manera crónica en los proyectos software relacionados con el Departamento de Defensa de los Estados Unidos para lo que se convocó un concurso que ganó la Carnegie Mellon University.

CMMI plantea un modelo en base a qué es lo que hay que hacer y no entra en cómo hay que hacerlo, esto puede suponer una ventaja en cuanto a que proporciona flexibilidad y un inconveniente en el sentido de que no proporciona fórmulas exactas (es como si tienes un mapa, pero tú te las tienes que averiguar para llegar de manera adecuada al destino).

Un aspecto importante de CMMI es que contempla diferentes niveles de madurez en cuanto a la implantación de los procesos, lo que permite que cada organización pueda plantear una estrategia de mejora continua (implanto un proceso, lo consolido, observo ventajas e inconvenientes y tomo la decisión de si me quedo como estoy o intento acceder al siguiente escalón) hasta llegar al nivel de madurez adecuado a las expectativas de la organización y a lo que ésta puede dar de sí.

No se certifica a las organizaciones en CMMI aunque esto es un tema sobre todo más formal que real, ya que lo que se hace es evaluar el nivel de madurez de una organización y otorgándole su pertenencia a uno de los niveles de madurez definidos en el modelo (se empezaría por el nivel 2 de los 5 niveles existentes). No obstante, también es posible realizar una evaluación por áreas de proceso (cada nivel del modelo tiene como objetivo satisfacer los objetivos de todas las áreas de proceso que lo conforman) y determinar el nivel de capacidad de las mismas (permitiendo de esta que se puedan tener procesos más evolucionados que otros, ya sea porque sean más importantes para la organización y/o les resulta más sencillos de conseguir por las características de los procesos ya implantados, su madurez, las características del personal, la cultura de empresa, etc…).

En los próximos artículos sobre la materia pasaré a tratar brevemente los cinco niveles de madurez definidos.

Michael Anthony Jackson es otro de los padres de la programación estructurada y ha sido un especialista en el campo de la ingeniería del software y de las metodologías de desarrollo (hasta un total de tres llevan su firma). Profesor universitario, autor de libros y artículos e investigador en AT&T, han sido sus principales ocupaciones.

Esta reflexión, es en mi opinión una de las que mejor representa la problemática del desarrollo de software: “El software es solo una interpretación de la realidad del problema que se está resolviendo”.

Precisamente ahí es donde estriba la complejidad del desarrollo de software, en alinear la percepción de los usuarios con la de los desarrolladores, teniendo en cuenta que cada usuario tiene su propia percepción y que cada desarrollador también la tiene. Y todo ello con un producto software que hay que desarrollar, por lo que la ejecución también es importante, en unos plazos y en un presupuesto dado.

Esta visión del desarrollo de software nos lleva inevitablemente a las metodologías ágiles y a los desarrollos de carácter iterativo e incremental ya que es la estrategia que más se aproxima a esta realidad, ya que resulta muy complicado en un proceso de análisis acertar con las percepciones del usuario y todavía resulta más complejo si el posterior proceso de construcción se extiende mucho en el tiempo y empiezan a aparecer contingencias que provocan desviaciones respecto a esa interpretación realizada de lo que quiere el usuario (por mucho que la haya aprobado).