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.

Anuncios

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