archivo

Archivos diarios: noviembre 23, 2011

Una prueba de concepto en el contexto del desarrollo de software viene a ser la validación de un aspecto funcional o no funcional de un sistema de información o de parte de él, ya sea por el área técnica o por el área usuaria.

Podríamos decir, por ejemplo, que las pruebas de aceptación son un tipo concreto de prueba de concepto.

Por tanto, se puede considerar como una herramienta de utilidad en el proceso de desarrollo, sin embargo es conveniente gestionar de manera adecuada sus expectativas y objetivos en el contexto actual del proyecto y/o del sistema de información, es decir, ¿qué se pretende validar?, ¿cuáles son los umbrales mínimos exigidos?, ¿la validación atiende a criterios cualitativos, cuantitativos o ambos?, ¿qué consecuencias tiene la no superación de las mismas?, ¿están bien calibrados los umbrales con respecto a las consecuencias en el estado actual del proyecto y en la fase actual de su ciclo de vida?, ¿quién va a participar en las pruebas de concepto conoce de antemano qué aspectos no van a tener el comportamiento esperado?, etc…

Algo que no termina nunca, dirán algunos.

Y no es así, más bien, no debería ser así. Vamos a analizarlo.

Un proyecto es un conjunto de actividades que se realizan en el tiempo (su realización, por tanto, es gradual) que tienen como objetivo producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó.

Definiciones, hay muchas, la anterior puede ser una de ellas.

¿Qué se realizan en el tiempo quiere decir planificadas? En algún momento, y eso es independiente de la metodología utilizada, hay que decidir cuándo se realiza la actividad. Personalmente me gusta más la expresión “se realizan en el tiempo” que “planificadas” porque lo segundo parece que se remonta a un horizonte temporal más amplio y no necesariamente tiene que ser así.

Un proyecto, por tanto y por definición, debe ser finito. Sin embargo, cuando hablamos de enfoques iterativos incrementales en el desarrollo parece que siempre lo hacemos pensando en una continuidad, como si el sistema siempre estuviera en continua evolución.

Ese enfoque es lógico y no solo sucede en ese tipo de ciclo de vida, también nos lo encontramos en el < href="clásico ya que un software siempre es susceptible de ser mantenido en sus diferentes vertientes (evolutivo, correctivo, adaptativo y perfectivo), lo cual no quita que planteemos horizontes temporales para conseguir determinados objetivos.

La vinculación que se tiene respecto a un sistema de información hace que, independientemente de que el proyecto sea el mismo para el cliente que para el proveedor, y por tanto, finalice a la vez, se tengan diferentes visiones, de cuándo realmente termina para uno y para otro.

Si tu rol es el de proveedor, el proyecto termina cuando se alcanzan los objetivos por lo que te han pagado y una vez finalizada la garantía establecida (esto puede ser más o menos tormentoso, llevar más o menos tiempo, pero los proyectos, terminan).

Si tu rol es el de responsable técnico del cliente no está tan claro cuándo terminas, si es que terminas, ya que existe una frontera poco definida entre lo que es la explotación y mantenimiento de un sistema de información (generalmente por una mala definición de las funciones y procesos de los departamentos TIC), por lo que no se termina de pasar página y esto sucede, tanto si se encadenan proyectos como si no. Eres responsable técnico del sistema y lo serás hasta que el ciclo de vida del mismo se cumpla.

El problema de que la vinculación al sistema de información sea esa es que, conforme vaya pasando el tiempo, cada vez serán más proyectos y sistemas con los que trabajes y la montaña se hace cada vez más grande, tanto que la gestión termina siendo insoportable porque habrá sistemas de información que durante un tiempo no den problemas, pero al final siempre aparecerá algo que origina un trabajo.

Cuando se gestionan muchos sistemas, la suma de elementos aislados forman una sucesión interminable de tareas, que afectan a los proyectos reales en los que estás trabajando en ese momento, mermando la calidad de las actividades que realizas en el mismo.

No hace mucho, la responsable de uno de los departamentos de mi organización me comentó que uno de los principales problemas que tenemos los desarrolladores es que la aceptación de cambios en los sistemas de información, vengan o no de responsables funcionales, es demasiado poco formal y que eso provoca que quienes solicitan los cambios no se sientan realmente implicados con las decisiones que están tomando y que la consecuencia de eso es que después no asumen todo ese esfuerzo y coste económico que ha tenido realizar las modificaciones que han pedido.

Para aspectos importantes, la responsable del departamento comenta que solo actúa por orden directa de su superior o bien tras escrito firmado por otro responsable, ya que tenía malas experiencias tras haber realizado trabajos que no tenían por detrás una solicitud formal.

Y es que los usuarios, los responsables funcionales, vienen y van y el sistema de información permanece. Cuando se designa gente nueva al proyecto vienen con sus propias ideas y probablemente empezarán a solicitar cambios, pues bien, todo lo que pidan debe quedar registrado que lo han pedido, pero no solo eso, la petición debe hacerse en unos términos formales, otra cosa es que después a la hora de afrontar la tarea se apliquen principios ágiles para llevarla a cabo.

Si no aplicamos esta estrategia, estamos vendidos porque cuando las cosas empiezan a ir mal todas las miradas van al equipo de desarrollo y nadie se responsabiliza de nada.