archivo

Archivo de la etiqueta: ingeniería del software

Realmente hasta que no tienes software funcionando y preferentemente en el entorno de producción no tienes certeza de que el camino escogido ha sido el correcto.

¿Quiere decir esto que la ingeniería del software no sirve para nada?, ¿quiere decir esto que todo trabajo previo no es válido?

No, no quiero decir eso. Como he repetido en muchas ocasiones, el desarrollo de software debe hacerse con intención minimizando la especulación. La especulación da lugar a iteraciones de más y en consecuencia a trabajo de más que en función del presupuesto existente en el proyecto puede impactar en la calidad del producto final y en el cumplimiento de las expectativas del usuario. Por tanto, es serio desarrollar con intención.

La intención te la da el estudio y el conocimiento del problema, no solo a nivel técnico sino también a nivel funcional. Cada proyecto podría requerir soluciones particulares para la obtención de ese conocimiento.

Ese conocimiento sirve de ayuda para adaptarnos de manera más consciente al cambio, es ágil tener ese conocimiento y no es ágil lo contrario.

El enfoque de cómo se adquiere ese conocimiento y cómo se plasma, tal y como decía, depende del proyecto y también tiene mucho que ver, porque podrá haber diferentes opciones, nuestro conocimiento, nuestra experiencia y nuestra forma de trabajar (pero todos ellos deben ponerse a servicio del proyecto y no al revés). Aquí es donde pueden centrar el debate los más ortodoxos de la ingeniería del software de aquellos que aplican la ingeniería de otra manera (generalmente con otro estilo e instrumentos).

Tan malo es tirarse a la piscina sin agua (sin conocer qué es lo que vamos a hacer desde un nivel general) como esperar “eternamente” a tener todo “sobre plano”. Tal vez pueda bastar con tener solo ciertas partes “sobre plano” conservando una visión global de lo que se requiere. Lo primero porque hay que desarrollar con intención y lo segundo porque lo más probable es que el plan salte por los aires, teniendo en cuenta que el mismo ha sido desarrollado desde una imagen abstracta del sistema por parte del usuario que una serie de desarrolladores se han encargado de interpretar. A eso hay que sumar la incertidumbre inherente al desarrollo de software y a los cambios que se producirán a lo largo de todo el proceso de desarrollo.

Después, cuando tengamos el producto en producción, vendrán los ajustes. Mucho mejor tratarlos cuanto antes porque si la desviación de las expectativas es importante el coste siempre será mucho menor, todavía podría haber tiempo de revertir la situación.

Se ha hablado tanto, se ha escrito tanto, son tantos años aplicando ese esquema de trabajo, enseñando ese paradigma como el único camino para el desarrollo de software que desgraciadamente seguimos encontrando casos y casos en los que se sigue pensando que el ciclo de vida clásico o en cascada es el único camino para desarrollar software y que cualquier fisura sobre esa idea es provocada por personas que no creen que el software es un producto de ingeniería.

Me mantengo en lo que digo siempre, cada proyecto requiere su medicina y es posible que en algún caso, la estrategia más adecuada sea la cascada, si bien lo más normal es que lo más adecuado sea tender hacia un enfoque iterativo e incremental y a partir de ahí aplicar los enfoques, estrategias, actitudes, prácticas, instrumentos y herramientas más apropiadas. Pero como decía si crees que la cascada es lo mejor para el contexto del proyecto, aplícala.

Lo que no voy a compartir nunca es que la ingeniería del software está en el lado de las cascada y no existe fuera de él. No es así, es otra forma de entender el desarrollo de software más ajustada, a mi entender, a su propia naturaleza, a la propia naturaleza de los desarrollos, personas y organizaciones.

Querer capturar todos los requisitos a la primera y aceptar es muy complicado porque requiere por un lado que el usuario sea capaz de materializar en palabras una idea abstracta como la que es un producto software y por otro que el desarrollador sea capaz de captar la visión del usuario, todo ello prácticamente a la primera y que después no surjan cambios en los procesos, en la organización, en las personas o en las prioridades que echen parte o todo al traste.

Lo peor de lo que acabo de contar es que en muchas ocasiones pese a que se conoce que hay errores en las especificaciones o que es necesario realizar correcciones motivadas por cambios de contexto no se llevan a cabo las modificaciones necesarias porque ya existe un compromiso entre las partes basado en un catálogo de requisitos inicial. Generalmente no nos encontramos con situaciones de tanta inflexibilidad sino que se llegan a soluciones intermedias que no dejan de ser parches que impiden que el producto final satisfaga las expectativas que se tenían puestas en él.

Me parece muy interesante la reflexión que hace Mike Cohn sobre este tema (traducción libre): “Queremos animar al enfoque de proyectos en los que la inversión, planificación y decisión sobre las funcionalidades sean periódicamente revisados. Un proyecto que cumple con todas las especificaciones del plan inicial no tiene por qué ser necesariamente un éxito. Los usuarios y el cliente probablemente no se sentirán satisfechos cuando vean que nuevas ideas en las especificaciones han sido rechazadas en favor de otras mediocres por el simple hecho de que estaban en el plan inicial”.

Defiendo absolutamente la posibilidad de que en una organización se pueda progresar horizontalmente de manera que técnicos que disfruten con la programación y con la ingeniería del software puedan tener la oportunidad de conseguir mejores condiciones laborales si su desempeño, experiencia y conocimientos les hace merecedores de ello.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).

Watts Humphrey es considerado por muchos como el padre de la calidad del software y una de las figuras clave en el campo de la ingeniería del software. Me parece interesante que un personaje tan relevante de nuestro negocio resuma en la siguiente reflexión una buena parte de lo que es el proceso de desarrollo, la gestión de requisitos y el papel de los usuarios en todo esto (traducción libre):

“Cuando programamos, transformamos un problema que prácticamente no comprendemos en un conjunto preciso de instrucciones que pueden ser ejecutadas por un ordenador.

Cuando pensamos que comprendemos los requisitos del programa, estamos inevitablemente equivocados.

Cuando no entendemos completamente un problema, debemos estudiarlo hasta comprenderlo.

Solo cuando nosotros verdaderamente comprendemos un problema podremos desarrollar un producto superior que trate el problema.

Lo que los usuarios piensan lo querrán cambiar tan pronto como vean que estamos desarrollando”.

Requisitos, usuarios, la propia evolución del equipo de proyecto, son parte de la incertidumbre del proceso de desarrollo, de la incertidumbre de los proyectos de desarrollo de software.

Es importante tener buenos analistas que permitan extraer el mayor conocimiento posible del negocio y de las expectativas del usuario, ya que de esta manera ahorraremos esfuerzo, no obstante, el conocimiento real del negocio y de lo que quiere el usuario llega más tarde, cuando tenemos el producto o parte de él en producción y el usuario se da cuenta realmente de lo que quiere y cómo lo quiere.

Si lo más importante en el desarrollo de software son las personas (tal y como expone el manifiesto ágil) resulta totalmente coherente la siguiente reflexión de Barry Boehm en la que comenta que: “una buena ingeniería del software debe adaptarse a las preocupaciones humanas”.

Precisamente en los artículos:

Entorno de trabajo y la productividad
Desarrollo de software. Barry Boehm. La perspectiva del programador

Trato las dos partes en que divide Barry Boehm este concepto, la comprensión del equipo de personas que está desarrollando el proyecto y la comprensión de las personas que hacen uso o van a hacer uso del producto.

No hay ingeniería sin personas que la lleven a cabo y sin un destinatario de sus resultados, la ingeniería por sí misma no es un fin, es un medio. Por tanto no se puede supeditar todo al proceso, a las técnicas, a las herramientas, son importantes sí, pero solo si se hacen desde y para las personas.

Barry Boehm es una buena referencia a la hora de considerar como adecuados determinados indicadores obtenidos en sus investigaciones y proyectos, no en vano siempre ha sido considerado como una de las referencias en el campo de la ingeniería del software, metodologías de desarrollo, estimación de costes y obtención y determinación de métricas relacionadas con el proceso de desarrollo.

Independientemente del indicador que cita Boehm y que indicaré al final de artículo, la propia experiencia nos dice que el coste de corrección de un error se dispara conforme nos alejamos del momento en que se ha producido. Esto es así porque un error arrastra tras de sí otros trabajos que correctos o no, se verán alterados por la corrección del mismo. Por ejemplo, una mala especificación de un requisito que llega a producción tendrá repercusión en el producto final, pero también su corrección requerirá un esfuerzo considerable por los diferentes artefactos que se tienen que modificar o incluso rehacer.

La aparición de los modelos de testing en V o de testing en W son una respuesta posible ante esos problemas, como también lo son la aplicación de otras técnicas en el proceso de construcción, como por ejemplo pruebas unitarias, integración continua, etc…

No solo afectó esta circunstancia a la aparición de modelos o técnicas de testing, sino que las metodologías de una u otra manera quedan impregnadas por la necesidad de detectar y corregir cuanto antes los errores (de hecho el propio testing en V no es más que una variante del ciclo de vida clásico o en cascada) como por ejemplo podemos ver en RUP o por la propia dinámica de desarrollo siguiendo metodologías ágiles.

Sobre la detección tardía de errores y sus implicaciones en los costes de un proyecto, Barry Boehm comenta lo siguiente (en relación a errores en etapas muy tempranas en el desarrollo, como lo son la obtención de especificaciones o requisitos): “Corrige los errores de especificación cuanto antes. Corregirlos después, costará: un 500% más en la etapa de diseño, un 1000% en la etapa de codificación, un 2000% en la etapa de testing unitario y un 20000% más en la entrega”.

Barry Boehm comenzó en nuestro negocio hace cincuenta y seis años. Se especializó principalmente en sistemas orientados a la defensa y entre sus áreas de interés se encuentra la ingeniería del software (especialmente la ingeniería de requisitos), las metodologías de desarrollo, los métodos de estimación de costes, métricas de software.

El prestigio de Boehm está fuera de toda duda, por lo que cualquiera de sus reflexiones, estemos o no de acuerdo, proporcionan un enorme valor.

En bastantes artículos he comentado la repercusión que tiene una buena o una mala gestión en un proyecto de desarrollo de software, en tanto en cuanto, su suerte comienza desde que se está negociando las condiciones de su contratación o se concurre a una licitación con una determinada oferta y en unas determinadas condiciones y que son diferentes y decisivas otras tareas que se realizan antes de tener la reunión de arranque del proyecto (como por ejemplo la elección del equipo de trabajo, si es que este no se ha comprometido previamente, la selección de la metodología, etc…).

Y por supuesto también son importantes las tareas de gestión que se realizan durante todo el proceso de desarrollo y también lo son en el cierre del proyecto e incluso después.

Barry Boehm también valoraba el impacto que tiene la gestión en los costes de los proyectos cuando comentaba que: “Una pobre gestión puede incrementar los costes del software más rápidamente que cualquier otro factor”.

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).