archivo

Archivo de la etiqueta: CSI

La incertidumbre en el desarrollo de software existe, es evidente, que los requisitos, contexto, usuarios, etc… cambian, y de la noche a la mañana (cuando no en la misma mañana). Que ante el cambio la respuesta debe ser adaptarnos a él, para lo cual la metodología con que se está trabajando debe tener en cuenta este detalle y en donde los stakeholders deben entender ese hecho como natural y que tiene un coste económico y que también afecta a los plazos.

Pero hay más y es el que la arquitectura y codificación del software deben facilitar el cambio. El parámetro velocity, qué determina la cantidad de trabajo que se puede abordar en una iteración depende de las buenas prácticas y de la deuda técnica que acumule el software durante el proceso de programación. No es el único factor, ya que también influye de manera importante la cualificación del equipo que está trabajando y de su experiencia en el desarrollo de este producto concreto, de la arquitectura y framework elegido, etc…

Por ese motivo las metodologías ágiles, como por ejemplo la programación extrema hacen tanto hincapié en la necesidad de que el código sea de la mayor calidad posible, lo que obliga a ir realizando periódicamente actividades de refactorización.

Es la evolución natural de los desarrolladores que han trabajado con el ciclo de vida clásico o en cascada y de las organizaciones que han venido utilizando esa metodología.

Está comprobado que la cascada no produce buenos resultados ya que se ajusta a un modelo ideal de desarrollo de software en el cual las especificaciones de los usuarios son las adecuadas (para lo cual el usuario tiene que tener perfectamente claro qué es lo que quiere y cómo lo quiere ver plasmado en un sistema de información y, por otro, que el equipo de proyecto capte de la mejor manera posible esas expectativas) y que no cambian durante el proceso de diseño y construcción.

El desarrollo de software tiene una naturaleza adaptativa, evolutiva, no predictiva y por tanto el ciclo de vida en cascada no se ajusta a ese patrón.

Por ese motivo, el primer paso que suelen dar los desarrolladores y organizaciones habituados a ese esquema de desarrollo es dividirlo en fases y convertirlos en desarrollos incrementales. El siguiente paso que se suele dar es revisar al final de cada fase las desviaciones respecto a las expectativas, de manera que se tenga en cuenta para la siguiente fase la cual además de funcionalidades nuevas tendrá los desarrollos necesarios para realizar los ajustes de la fase anterior, pasándose de esta forma a un ciclo de vida iterativo incremental.

Una vez llegado a ese punto el salto a una metodología ágil es cuestión de tiempo.

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.

He insistido en diferentes artículos que gran parte de la suerte del proyecto se juega antes de que comience. Una mala negociación, una mala venta condiciona todo lo demás (pudiéndose partir de una situación de Death March Project) y solo produciéndose determinadas circunstancias ideales: un equipo de proyecto motivado y de calidad y un cliente y unos usuarios que facilitan las tareas, pueden paliar las pérdidas del proyecto, tangibles (en dinero), como intangibles (de pérdida de imagen con el cliente ante un proyecto de ejecución deficiente).

Sin embargo, la venta inicial del producto es solo una de las variables que condicionan el posterior desarrollo del proyecto, la elección de una mala metodología ya sea por parte del proveedor o impuesta por el cliente puede hacer estragos en el trabajo realizado, en el coste y en los resultados.

Lo mismo si no se delimita de manera adecuada el alcance (ya sea antes de la venta o antes incluso de empezar a recoger requisitos).

Y después toca el análisis. Si la metodología condiciona un desarrollo en cascada la realización de un análisis excelente es esencial, si bien, todo se puede ir al traste en el momento en que cambia algunas de las variables del proyecto (interlocutores, procesos, etc…) y es que los modelos predictivos tienen ese problema.

Si la metodología es ágil o al menos iterativa incremental (como RUP), las tareas de análisis también son de gran importancia, aunque desarrollos iterativos y evolutivos dan un mayor margen para la corrección de deficiencias en la captura e interpretación de los requisitos y en el modelado de la solución.

Por tanto, independientemente de que en función de la metodología aplicada la realización de un buen análisis tenga una mayor importancia, en todas condiciona el resto del proyecto y muchísimo.

Un mal análisis, si se detecta en etapas tardías (en muchos casos, cuando el producto ha llegado a producción), provocará un más que probable fracaso de la puesta en marcha del sistema y un más que probable esfuerzo económico importante para resolver esta circunstancia, mediante mantenimientos correctivos y evolutivos, que podrían ser incluso no asumibles si la deuda técnica del desarrollo es elevada.

Pero es que un mal diseño también tiene consecuencias y muy importantes en el resultado final del software.

Por eso destaco siempre que, además de contar con buenos programadores, disponer de buenos analistas funcionales y orgánicos permite que el trabajo de los que codifican brille más y sobre todo, sea útil.

De ahí la importancia de realizar testing desde el principio, fundamento este que dió lugar, por ejemplo a las metodologías de testing en V o en W.

En resumen, aunque muchos piensen que el partido se juega en la construcción del software, si no se han realizado de manera adecuada las etapas anteriores, el partido se habrá perdido antes de que el árbitro de el pitido inicial.

La definición de smoke testing es sencilla ya que son pruebas rápidas que se realizan sobre aspectos funcionales del software para comprobar a alto nivel si el mismo tiene el comportamiento esperado. Ahora bien, la forma y el momento de aplicación puede variar.

Lo más normal es que se aplique durante el proceso de construcción como un paso más allá a la integración continua y a las pruebas unitarias y pueden ser automáticas, manuales o mixtas, ya que lo que se pretende comprobar es si determinadas funcionalidades tienen el comportamiento adecuado.

Hay que tener en cuenta que el smoke testing más que descubrir errores concretos lo que pretende es verificar que a nivel funcional no se están produciendo incidencias graves.

En otros contextos se aplica smoke testing con caracter previo a pruebas funcionales más exhaustivas con el objeto verificar si merece la pena ponerse con ellas, es decir, si se detectan errores graves (el sistema no funciona, sea cae a la más mínima operación, no abre una pantalla que permite acceder a una funcionalidad esencial, etc…), ¿para qué perder el tiempo haciendo un testing en mayor profundidad del sistema?

También es frecuente aplicar este tipo de testing con carácter previo a una entrega al cliente, de manera que se realice una última comprobación para verificar que a alto nivel todo está bien (antes como es lógico se debería haber realizado unas pruebas en profundidad del sistema de información a todos los niveles, no solo el funcional).

Si en el nivel 3 de CMMI se entra en el detalle de cómo obtener los requisitos resulta razonable que no ignore los procesos de diseño y construcción y de esto trata este área de proceso.

Es muy importante no caer en la trampa de definir procesos poco flexibles que no permitan una adaptación a la tipología de sistemas de información y circunstancias que pueden producirse en el desarrollo y mantenimiento de los mismos. Puede ser razonable hacerlo en entornos controlados, pero en entornos variantes (como son la mayoría) hay que establecer una serie de pautas que normalicen el proceso de diseño y construcción de manera que lo que se marque sea un camino con la suficiente anchura como para elegir dentro de él la trayectoria más adecuada al proyecto pero lo suficientemente estrecho como para tener un control de la manera en que se diseñan y construyen los sistemas.

Dentro de este área de proceso se determina en qué condiciones se deben ofrecer alternativas de solución y cuál es la información que se debe suministrar en cada caso, qué criterios utilizar para seleccionar una de ellas, qué criterios, técnicas, estrategias, precondiciones, etc… tener en cuenta a la hora de realizar el diseño del sistema, qué circunstancias se deben tener en cuenta a la hora de elegir la opción más ventajosa para obtener la solución que se demanda (comprar, reutilizar o construir), qué prácticas se deben seguir para realizar la construcción del sistema y para escribir la documentación de soporte.

¿Se basa este proceso en tener y seguir un libro blanco? Hay aspectos de este área de proceso que escapan de un libro blanco convencional, como aspectos de un libro blanco convencional que van más allá de este área de proceso, no obstante para imaginarnos qué contenido tendría un proceso como este es una buena aproximación, si bien equipararlos, tal y como acabo de comentar sería caer en el error.

Richard (Dick) Sites, en la década de los setenta realizó la siguiente reflexión: “Prefiero escribir programas que escriben programas, que escribir programas”.

Entre treinta y cuarenta años después, la generación de código sigue estando presente y resulta muy importante para reducir costes en los proyectos de desarrollo de software, por ese motivo la inversión en corregir sus incidencias, mejorar la calidad del código generado y la funcionalidad y alcance del mismo es algo a tener muy en cuenta en las empresas de desarrollo de software.

La generación de código, la reutilización de código, la delegación de funcionalidades entre componentes, una buena elección de la arquitectura y del framework, son elementos fundamentales para mejorar la productividad en los desarrollos.