archivo

Archivo de la etiqueta: proyecto de desarrollo de softaware

Uno de los grandes problemas del desarrollo de software en la Administración Pública lo tiene la utilización generalizada del ciclo de vida clásico o en cascada, no hago referencia directa a MÉTRICA v.3 ya que la misma no deja de ser un ordenación particular de dicho ciclo de vida que además es lo suficientemente abierta como para que una inmensa mayoría de los proyectos desarrollados en cascada sean compatibles con la misma.

¿Por qué es un problema? Porque está más que demostrado que el ciclo de vida en cascada no da buenos resultados. Y no es algo que yo haya leído, sino que lo he sufrido y estoy sufriendo en los proyectos que gestiono. Desarrollar en cascada es un error, yo le he estado cometiendo durante años y me ha servido para darme cuenta que la solución pasa por la aplicación de otras metodologías.

Sin embargo la Administración Pública apostó por MÉTRICA, como metodología oficial para el desarrollo de sistemas de información y las razones son varias:

– El ciclo de vida en cascada era (y lo sigue siendo) la metodología más utilizada y más implantada, en proyectos dentro y fuera de la Administración Pública.

– La Ley de Contratos, tiene una finalidad fundamental que no es otra que la de fiscalizar la actuación de la Administración y propiciar la concurrencia con igualdad de oportunidades de los licitadores a los concursos que se convoquen. Sin embargo tiene como inconveniente de que se trata de un procedimiento administrativo que lleva meses, desde que se elaboran los pliegos hasta que se realiza la adjudicación y posteriormente se formaliza (firma) el contrato.

¿Cuál es el inconveniente? Pues que en muchos casos se valora el sistema de información a desarrollar sin conocer en detalle los requisitos funcionales y los casos de uso o dicho de otra forma, sin conocer en profundidad qué es lo que quiere el área usuaria del proceso o procesos que se van a informatizar.

Para solucionar esto habría que realizar un preanálisis del proyecto, para conocer el alcance global que se persigue y entrar en un cierto grado de detalle a nivel de requisitos e interacción del sistema con los diferentes actores (usuarios y otros sistemas). A partir de ahí sí que es posible realizar una valoración más acorde con la realidad y tomar la decisión sobre qué metodología es más adecuada para realizar el proyecto, teniendo en cuenta las características de los usuarios y la divisibilidad del mismo en bloques funcionales que faciliten los desarrollos de manera iterativa e incremental.

Esto querría decir que el preanálisis habría que desarrollarlo con recursos internos o bien contratarlo, siendo la segunda opción la más común debido a que, por regla general, los Departamentos de Informática de la Administración Pública no están dimensionados acorde a las responsabilidades y funciones que tienen que acometer.

Si se contrata ese trabajo quiere decir que el desarrollo del sistema de información se tendría que contratar en otro procedimiento, por lo que como mínimo habría que esperar cuatro o cinco meses para poder empezar (cuando no un año o más, ya que dependerá del momento del año en el que se ha terminado el trabajo, la disponibilidad presupuestaria, etc…). Todos sabemos cómo son los usuarios y en un plazo de seis meses a un año donde ayer dije una cosa, hoy diré otra y salvo que esa dinámica adaptativa se haya tenido en cuenta en el presupuesto, el mismo partirá con un déficit que empezará a poner dificultades desde el principio.

– Otro aspecto es la propia dinámica de funcionamiento de la Administración. Lo que hoy puede ser prioritario mañana puede dejar de serlo, lo que implica que recursos inicialmente previstos para el proyecto desde el área usuaria, pueden desaparecer o ver mermada su participación. A lo anterior hay que sumarle el alto índice de rotación de persona que existe. Esta casuística es un arma de doble filo, ya que por un lado aconseja cerrar unos requisitos para intentar “blindar” un alcance de los trabajos y poder desarrollar el proyecto y por otro ese blindaje finalmente no sirve de nada porque si hay aspectos funcionales que no han sido bien recogidos o bien cambian con el nuevo personal que se asigne al proyecto se requerirán cambios en los requisitos ya definidos, los cuales se producirán incluso en etapas tardías del desarrollo.

El camino para desarrollar proyectos con una mayor probabilidad de éxito pasa por un desarrollo iterativo e incremental, plásmándose este en la metodología que se considere mas adecuada a las circunstancias del proyecto. Es necesario hacer ese análisis ya que existen ciertas metodologías ágiles que por el alto grado de participación del usuario que requieren no son realistas de aplicar en muchos casos, por la dinámica de funcionamiento de al Administración que expliqué antes (lo cual no quiere decir que haya situaciones concretas donde sean posibles).

Es totalmente posible desarrollar este tipo de proyectos, pero es fundamental para ello cambiar la forma de enfocarlos, es necesario conocer qué se quiere obtener, pero plantearlo como una carrera por etapas. Si un ciclista trata de hacer todo el recorrido del Tour de Francia del tirón no podrá, si lo hace por etapas le costará trabajo llegar hasta el final pero por lo menos tendrá una oportunidad de conseguirlo. Y esto es válido tanto si se contrata todo el desarrollo de una vez como si se contrata primero el análisis o preanálisis y después a construcción (teniendo en cuenta que al coste calculado hay que añadirle un porcentaje por el proceso adaptativo del sistema de información a las necesidade del usuario en cada iteración).