El documento explora si la Ley de Contratos del Sector Público permite proyectos ágiles de desarrollo de software. Explica que las metodologías ágiles son ventajosas porque permiten iteraciones frecuentes y métricas para manejar la inconcreción inherente a los proyectos de software. Sin embargo, la ley parece restringir las modificaciones de contrato y requiere objetivos determinados, en contradicción con los métodos ágiles. Aun así, la ley permite medir los servicios por niveles de calidad y procesos

1. ¿Permite la Ley de Contratos del Sector Público Proyectos Ágiles de Software? 1
¿Permite la Ley de Contratos del Sector Público
Proyectos Ágiles de Software?
R. Saralegui, Amper Programas
Resumen—Las metodologías ágiles de desarrollo presentan
grandes ventajas para proyectos de desarrollo de software,
mediante unos métodos iterativos y métricas que permiten
manejar la inconcreción de qué estará disponible y cuándo. La
Ley 30/2007 de Contratos del Sector Público impone
restricciones a los contratos de la Administración que en
principio hacen difícil seguir estas metodologías. Sin embargo,
mediante una cuidadosa redacción de los pliegos de
condiciones, creando las métricas adecuadas e imponiendo que
se siga un proceso iterativo durante el desarrollo, se pueden
utilizar metodologías ágiles. Como consecuencia, las dos partes
salen beneficiadas.
Palabras clave—Proyectos, agile programming,
metodologías ágiles, Ley de Contratos del Sector Público,
LCSP, software, métricas de servicio
I. INTRODUCCIÓN
El software está siendo cada vez una parte más
importante de cualquier proyecto tecnológico y, con ello, de
los grandes programas contratados por la Administración
([1], pág 14). Sin embargo, la regulación actual no hace un
tratamiento muy diferenciado de los desarrollos de software,
y se limita a encuadrarlos dentro de los contratos de
servicios ([2], art. 9b) sin que ni siquiera tengan una
mención expresa en el Anexo II (“Servicios a los que se
refiere el artículo 10”).
Por todo ello, nos preguntamos si al redactar esta ley se
tuvo en cuenta un campo tan importante como el desarrollo
de software, o al menos, si su espíritu permite emprender
desarrollos que sean tan beneficiosos y eficientes para la
Administración como los que podría encargar una empresa
privada mediante la legislación mercantil.
En este estudio, expondremos unas ideas básicas (y
contraintuitivas) sobre la complejidad de los problemas.
Pasaremos a resumir las ideas fundamentales de las
metodologías ágiles de desarrollo. A continuación,
estudiaremos cuáles son los artículos de la ley más afectados
y haremos una propuesta que sea compatible con las
prescripciones de la ley y las metodologías ágiles.
II. NO ES FÁCIL FORMULAR UN PROBLEMA
A. Un Ejemplo
Muchas veces el conseguir formular con precisión un
problema es sinónimo de alcanzar la solución. El ejemplo
por antonomasia son los bugs de software. Se comienza con
una manifestación del problema (“el dispositivo no se
comporta como yo quiero”); se investiga y, tras un complejo
proceso de búsqueda, se formula el problema con precisión
(“cuando el dispositivo parte del estado A y recibe una serie
de datos en el orden D y de longitud L, se produce un error
porque el módulo M no está preparado para ello en este
estado A”). En el momento que se ha identificado con
precisión en qué lugar del módulo M se manejan los datos
de longitud L, se puede solucionar actuando sobre ese
módulo M.
Trabajo del curso de Eficiencia en la Gestión de Recursos, Proyectos y
Contratos de la Administración Pública: Especial Referencia al Ámbito de
la Defensa. Instituto Universitario “General Gutiérrez Mellado”. UNED.
Junio de 2010
B. La Intuición No Vale
Encontrar una solución puede ser mucho más difícil que
lo que nos parece por intuición. Hay problemas con una
formulación sencilla, como el problema del viajante: “dado
un número N de ciudades, conociendo cuáles están
interconectadas por carretera y a qué distancia están unas de
otras ¿qué ruta debe seguir un viajante para visitarlas todas
recorriendo la mínima distancia total?” [3]. Pero su solución
se va haciendo más complicada conforme crece el número
de ciudades N, de tal modo no hay un algoritmo que nos
permita realizar los cálculos en un tiempo razonable más
que para un pequeño número de ciudades.
Por tanto, la intuición no nos sirve para estimar la
complejidad de un problema. Necesitamos un proceso
racional como el diálogo competitivo o similar para alcanzar
una buena comprensión de esa complejidad.
C. El Diálogo Competitivo
El legislador parece ser consciente de que formular con
precisión un problema es ya parte de la solución: el proceso
de diálogo competitivo (arts. 163 a 167 LCSP) se crea para
poder llegar a definir con precisión lo que necesita la
Administración antes de solicitar una oferta. Comprador y
vendedor siguen un proceso iterativo, con el que van
investigando el problema, y al final obtienen una
formulación precisa de qué se quiere resolver. Se sigue un
proceso racional para evitar engaños de la intuición.
D. Después del Diálogo Competitivo
Pero ¿qué ocurre una vez adjudicado un contrato? ¿Hay
métodos racionales para controlar un proyecto de desarrollo
de software de gran complejidad?
Una primera respuesta sería que se deben tener muy
claramente especificados todos los requisitos,
especificaciones, pruebas de validación y aceptación final.
También los protocolos de interconexión con otros sistemas
externos. Incluso se debería realizar un trabajo previo de
caracterización detallada del software para tener un estudio
de todos los casos y detallar con precisión absoluta lo que se

2. ¿Permite la Ley de Contratos del Sector Público Proyectos Ágiles de Software? 2
debe hacer, los posibles problemas que se van a encontrar y
la manera de solucionarlos. Posiblemente esto constituiría
un contrato previo al de desarrollo de software. Y además,
sería sólo factible para proyectos sencillos [4]. Para
cualquier otro caso, llegar a hacer una caracterización
detallada sería equivalente a emprender el desarrollo, pues
sólo desarrollando y probando el software se puede saber
qué problemas surgen y la manera de solucionarlos.
III. MODELO ÁGIL DE DESARROLLO
El modelo ágil de desarrollo de software da una respuesta
a lo anterior mediante una metodología de desarrollo
llamada “ágil” (agile development). En el modelo clásico de
desarrollo en cascada [4] hay fases diferenciadas y estancas
de análisis, diseño, desarrollo, pruebas y entrega al cliente
(Fig. 1). Cada una se inicia sólo cuando está completamente
terminada y definida la anterior, y sólo se da una vez. En
cambio, en el modelo ágil [5] se produce un gran número de
esas iteraciones durante el proyecto, en un ciclo que suele
repetirse cada cuatro semanas (Fig. 2). El cliente debe estar
presente en la fase inicial y final de cada ciclo, viendo el
estado del desarrollo de lo que ha pedido, y tiene poder de
decisión sobre qué se va a implementar en esa iteración. En
contrapartida a esta implicación extra, tiene siempre una
visión real del avance del proyecto, con lo que evita un
“esto no es lo que yo quería” en el momento de la entrega
final y tiene una mejor comprensión de los problemas a los
que se enfrentan los desarrolladores. Esto permite una
información constante del avance del proyecto y poder
reaccionar con agilidad a cambios tecnológicos o frente a
posibles incoherencias en las prestaciones solicitadas.
Análisis
Diseño
Desarrollo
Pruebas
Entrega
Análisis
Diseño
Desarrollo
Pruebas
Entrega
Análisis
Diseño
Desarrollo
Pruebas
Entrega
FIG. 1. MODELO CLÁSICO DE DESARROLLO
A. La virtud y el defecto de este modelo: inconcreción
Debido a cómo se hace la división en tareas y su
planificación, en cada momento se puede tener una
estimación de qué estará disponible en las próximas
iteraciones, en qué estado y cuándo estará listo (Fig. 3). Esta
estimación es aproximada, pero va ganando en precisión
conforme avanza el proyecto y también en función de la
experiencia del equipo de desarrollo en utilizar esta
metodología.
Análisis
Diseño
Desarrollo
Pruebas
Entrega
Análisis
Diseño
Desarrollo
Pruebas
Entrega
Análisis
Diseño
Desarrollo
Pruebas
Entrega
Análisis
Diseño
Desarrollo
Pruebas
Entrega
FIG. 2. UNA ITERACIÓN EN LA METODOLOGÍA ÁGIL
Puede aducirse que no parece muy profesional el
formular grados de cumplimiento de requisitos o plazos de
disponibilidad de manera aproximada, pues un proyecto de
desarrollo de software debería constar de unas prestaciones
concretas que se suministren en un plazo concreto. Sin
embargo, la metodología ágil lo que hace es poner de
manifiesto de una manera honesta algo conocido por
cuantos han estado implicados en proyectos de software
complejos: conforme se va trabajando en solucionar un
problema, se formula de una manera más precisa en cada
iteración de manera similar a como explicábamos en el
capítulo II y se va perfeccionando la solución a medida que
se hace el desarrollo.
La alternativa que tiene un equipo desarrollador de
software obligado a comunicar plazos fijos es poner
“márgenes de seguridad” en todos los componentes que se
desarrollan. Unos márgenes de seguridad tan amplios como
para absorber cualquier retraso por reelaboración de
trabajos, pruebas adicionales, correcciones de errores, etc.
que pudiera darse. Evidentemente, el desarrollo de software
se hará en el plazo acordado, pero no se habrá trabajado con
la máxima eficiencia durante todo el proceso. Por desgracia,
esta es la práctica más común en proyectos de desarrollo de
software gestionados con las metodologías clásicas.
La metodología ágil pone de relieve todos los pequeños
detalles y contratiempos que pueden darse durante el
proyecto, de modo que se pueda actuar cuanto antes y en
conjunto el desarrollo se haga con la máxima eficiencia.
Gracias a ello, el equipo de desarrollo puede afrontar su
trabajo de un modo más realista. Con las frecuentes
iteraciones, en cada momento se tiene un software
funcional, con las funciones que son más importantes para
el cliente, y la incertidumbre de saber cuánto queda y en
cuánto tiempo se acabará va disminuyendo
progresivamente, gracias a que las mediciones hechas hasta
el momento sirven para predecir la evolución del trabajo
que queda por hacer.
También gracias a las revisiones continuas, se puede
reaccionar con rapidez y, siempre con el acuerdo entre
contratista y cliente:
• añadir elementos que no se tuvieron en cuenta en el
momento de concepción del proyecto pero que después
se ha decidido que son importantes, o
• eliminar aquellos que pueden ser superfluos o en los
que la relación entre coste-plazo y la funcionalidad
aportada no es satisfactoria.
Es importante la transparencia que se obtiene para el

3. ¿Permite la Ley de Contratos del Sector Público Proyectos Ágiles de Software? 3
cliente, pues al estar presente en el proceso de desarrollo,
conoce todos los problemas y virtudes de lo que se
desarrolla, lo que evita sorpresas en el momento de la
entrega final y la tranquilidad de saber que lo recibido no
tiene fallos que el contratista le está ocultando.
B. Conflicto con la Ley de Contratos del Sector Público
Parece claro que utilizar una metodología ágil de
desarrollo para un proyecto complejo de software es
ventajoso para ambas partes. Pero en un primer análisis, la
utilización de una metodología ágil parece estar reñida con
conceptos clave de la Ley de Contratos del Sector Público:
• Se necesitan modificaciones del contrato. Hemos
expuesto más arriba que, de manera constante durante
el desarrollo del proyecto, se van a hacer cambios en el
proyecto en función de lo que se va aprendiendo sobre
el problema. En principio, esto nos lleva a una
modificación del contrato, ya que no estamos hablando
de causas imprevistas que hagan actuar al órgano de
contratación por el bien del interés público (art. 202.1
párrafo primero LCSP), sino de que el proceso de
desarrollo y aprendizaje técnico nos lleva a tomar
decisiones de modificaciones. Además, esto sólo sería
posible si estas modificaciones estuvieran previstas ya
en el expediente, en consonancia con las prescripciones
de la Junta Consultiva de Contratación Administrativa
para modificaciones de contratos [6]. Por si fuera poco,
no parece una idea realizable en la práctica: una
iteración típica en un desarrollo ágil dura cuatro
semanas, y hacer repetidas modificaciones a un
contrato cada cuatro semanas chocaría contra los
plazos que se manejan en la práctica para
modificaciones contractuales al amparo del art. 202.
• No se admite la inconcrecion. El contrato debe tener
un objeto determinado (art. 74 LCSP), que está en
contradicción con la inconcreción con la que trabajan
las metodologías ágiles, según hemos explicado en el
párrafo III.A.
• Concepto de totalidad de la prestación.
Consecuencia de la inconcreción es que no estará claro
cuándo se considera que el contratista ha realizado la
totalidad de la prestación (art. 205.1 LCSP): la
metodología ágil sólo asegura que para una fecha
concreta estará implementado un número aproximado
de funcionalidades. O que para implementar un número
concreto de funcionalidades, la fecha será aproximada
(Fig. 3). ¿Cómo conjugar esto con el concepto de
“totalidad de la prestación”?
Tiempo
Características
Entregar cuando se
alcance este nivel
(a)
Tiempo
Características
Entregar en esta
fecha
(b)
Tiempo
Características
Entregar
en esta
zona
(c)
Tiempo
Características
Entregar cuando se
alcance este nivel
(a)
Tiempo
Características
Entregar cuando se
alcance este nivel
(a)
Tiempo
Características
Entregar en esta
fecha
(b)
Tiempo
Características
Entregar en esta
fecha
(b)
Tiempo
Características
Entregar
en esta
zona
(c)
Tiempo
Características
Entregar
en esta
zona
(c)
FIG. 3. QUÉ ESTARÁ DISPONIBLE Y CUÁNDO. FUENTE: [5]
C. Qué nos permite la Ley de Contratos del Sector
Público
Sin embargo, si seguimos en nuestro análisis, podemos
descubrir que la ley nos abre las puertas al desarrollo de
software a través de metodologías ágiles:
• Tipo del contrato. Un proyecto de software complejo
debe encajar necesariamente en un contrato de
servicios (art. 9b), por tratarse de la “adquisición de un
programa de ordenador desarrollado a medida”. Y así
como los parámetros que regulan un suministro de
bienes son las unidades entregadas, los plazos y la
calidad de esas unidades, una prestación de servicios se
debe medir con un nivel de calidad de servicio (Service
Level Agreement) según unas métricas [7] acordadas
entre las partes. Si definimos de la manera adecuada en
un contrato de desarrollo de software a medida los
niveles de servicio que debe obtener la Administración
al fin del proyecto, podríamos ir calculando el nivel de
servicio que presta en cada momento el software
desarrollado, de modo que hay un paralelismo entre
estado del desarrollo del programa y nivel de servicio
prestado. Las decisiones que tomase el equipo de
desarrollo y el cliente en cada iteración irían
encaminadas a obtener el máximo nivel de calidad de
servicio.
• Criterios de evaluación de una oferta. Se permite
que la adjudicación se haga por criterios complejos, y
se dará preponderancia (art. 134.2) a aquellos criterios
mensurables, de tal manera que se cree una fórmula en
la que se ponderen los elementos que para la
Administración son más importantes. Si bien no se dice
nada de la fase de ejecución del contrato, esta
importancia que se da a criterios objetivos y
mensurables nos inclina a pensar que la evaluación de
la completitud de un suministro mediante una fórmula
que tenga en cuenta unos criterios equivalentes a los de
evaluación de la oferta encajaría con las intenciones del
legislador.
• Procesos iterativos. El diálogo competitivo, en los
arts. 163.1 y 166.4, contiene un reconocimiento
implícito de que es difícil llegar a formular un
problema, y es necesario un proceso de estudio
iterativo en el que se vaya desarrollando entre cliente y
contratista la posible solución. Sólo tras varias
iteraciones se podrá definir con más precisión el
problema. Esta descripción es muy similar a la antes
descrita del desarrollo ágil, y nos inclina a pensar que
el espíritu de la ley estaría, por tanto, a favor de que
también durante el cumplimiento de un contrato se
siguiera un método iterativo entre cliente y contratista
para ir acercándose a la solución del problema. Como
explicábamos más arriba, llegar a definir el problema
es gran parte del trabajo necesario para solucionarlo,
sobre todo en casos de software.
• Reducción de riesgos. Debido al control detallado que
se hace sobre el esfuerzo de desarrollo, se tiene
también controlado el coste del proyecto. En cuanto se
descubren elementos complejos no previstos en el
planteamiento inicial, la Administración es consciente

4. ¿Permite la Ley de Contratos del Sector Público Proyectos Ágiles de Software? 4
de ello y recibe una valoración de la dificultad añadida.
Esto le permite tomar decisiones de proseguir o buscar
alternativas, de manera que no se generen costes extras
en el proyecto y cumpla su mandato de obtener la
prestación “más ventajosa” (art. 1 LCSP).
IV. PROPUESTA: “MÉTRICAS DE COMPLETITUD”
En resumen, si estamos convencidos de las bondades de
las metodologías ágiles para desarrollos de software y
deseamos que un proyecto se rija por ellas, debemos
asegurarnos que las sucesivas iteraciones no provocarán
modificaciones de contrato, debemos buscar que a pesar de
la inconcreción siempre tengamos un objeto determinado, y
que las variaciones que se produzcan, aunque estén
acordadas entre contratista y Administración, siempre sean
tales que se cumpla la totalidad de la prestación. Todo ello
se encuadrará en un contrato de servicios, y utilizaremos
unos criterios paralelos a los comúnmente utilizados para
evaluación de ofertas. Esto redundará en una reducción de
los riesgos para las dos partes, mayor eficiencia y
contaremos con la confianza de que el proceso iterativo que
seguimos está de acuerdo con el espíritu de la ley.
La propuesta que aquí hacemos es:
1. Que los pliegos de condiciones tengan una definición
expresa de las métricas que se utilizarán para
determinar que el software funciona correctamente y
a satisfacción de la Administración según prescribe el
artículo 205.1. Estas métricas serán semejantes a las
que se utilizan para medir prestaciones de servicios
diferentes de desarrollo de software, y se podrían basar
en las que se utilizan en la fase de evaluación de
ofertas, en las que típicamente se dividen las
características del bien deseado en diferentes niveles
(básico, deseable, opcional…) y se ponderan en función
de la importancia que cada característica tiene para la
Administración.
2. Estas métricas deberán dar la suficiente flexibilidad
para que se puedan tomar decisiones durante el
desarrollo como prescriben las metodologías ágiles sin
provocar cambios en el objeto del contrato, a la vez
que deberán asegurar que todas las funcionalidades
más importantes para la administración serán
implementadas.
3. Los pliegos de condiciones deberán establecer que
durante el desarrollo del proyecto se seguirá un proceso
iterativo para practicar el desarrollo del software, con
participación de contratista y Administración, y en el
que los resultados de cada revisión servirán para
establecer los pasos a seguir en la iteración siguiente.
Este proceso se considerará semejante al del diálogo
competitivo, pero en vez de aplicado a obtener un
conocimiento para definir una solución y concluir en
una oferta, estará aplicado a obtener un conocimiento
para definir los pasos siguientes de un desarrollo
Así, un pliego de prescripciones podría tener una tabla
con funcionalidades básicas, deseables y menores, y un
porcentaje mínimo de las funcionalidades que deben estar
implementadas para aceptar el software. De manera similar
a los típicos criterios de número de errores (bugs) que se
utilizan en la industria para aceptar una versión de software
(Tabla 1), se podría generar una tabla (Tabla 2) con los
criterios para número de funcionalidades implementadas y
con cuántas se considera el software aceptable.
Tipo de
error
Máximo
número
Explicación
Mayor 5
Impide el correcto
funcionamiento
Menor 50
El software funciona
mediante un método
alternativo
Cosmético 100
El software funciona, pero
visualmente hay elementos
incorrectos
TABLA 1: CONDICIONES DE ACEPTACIÓN TÍPICAS, NÚMERO DE ERRORES
Nótese que para las funcionalidades básicas (o
imprescindibles) proponemos una cantidad ligeramente
inferior al 100%; la razón es que, de la misma manera en
que a partir de una complejidad media es imposible ([1],
pág. 21) obtener un software absolutamente libre de errores
(y de ahí el valor no nulo para la primera línea de la Tabla
1), es también imposible que un software coincida de
manera ideal con lo que se solicitaba inicialmente, en
especial tras todo el trabajo iterativo desempeñado con la
metodología ágil. Será labor de quienes definen los criterios
de aceptación hacerlo de manera que esta teórica
imperfección no impida en la práctica que el software
funcione como se desea.
Tipo de
funcionalidad
Implementadas
al
Explicación
Básica 98%
Necesarias para el
buen funcionamiento
Muy deseable 80%
Prescindibles si entran
en conflicto con la
clase anterior
Deseable 50%
Son prescindibles si el
costo de tenerlas es
más elevado que lo
que aportan
TABLA 2: MÉTRICAS DE COMPLETITUD
V. CONCLUSIÓN
Las metodologías ágiles de desarrollo son un marco de
referencia muy prometedor para los desarrollos de software
complejo; necesitan un cambio de manera de pensar y
gestionar un proyecto, pues ponen de relieve inconcreciones
–que de cualquier manera existen– y nos obligan a
manejarlas de manera diferente a la gestión clásica de
proyectos. Su ventaja es que permiten más eficiencia en los
proyectos y mayor satisfacción para desarrollador y cliente.
La Ley de Contratos del Sector Público tiene
requerimientos que, en principio dificultan la realización de

5. ¿Permite la Ley de Contratos del Sector Público Proyectos Ágiles de Software? 5
un proyecto siguiendo estas metodologías. Sin embargo,
aplicando métricas de nivel de servicio al objeto del
contrato, es perfectamente posible compatibilizar el
desarrollo de un software complejo según las prescripciones
de la ley y utilizando los procedimientos de las
metodologías ágiles.
Ya que la Administración habrá estado presente durante
todo el proceso de desarrollo del software, conocerá
perfectamente el estado del proyecto y sabrá que obtiene un
producto que numéricamente cumple con sus criterios y, lo
que es más importante, tiene las funcionalidades que, tras el
proceso iterativo de desarrollo ágil, ha descubierto que son
las que más le convienen y con un coste controlado.
Como en cualquier cambio tecnológico, posiblemente el
mayor obstáculo a su utilización generalizada no será el
marco legal, sino la resistencia mental al cambio y el apego
que todos tenemos a utilizar los viejos métodos conocidos,
aunque no sean tan eficientes.
REFERENCIAS
[1] A. M. Neufelder, Ensuring software reliability, Marcel Dekker, 1993,
ISBN 0-8247-8762-5
[2] Ley 30/2007 de 30 de octubre, Contratos del Sector Público
[3] Problema del viajante:
http://es.wikipedia.org/wiki/Problema_del_viajante
[4] W.W.Royce: Managing the Development of Large Software Systems.
Proceedings, IEEE WESCON, Agosto 1970, pp. 1-9
[5] Mike Cohn, Agile Estimating and Planning. Prentice Hall 2005.
[6] Informe de la Junta Consultiva de Contratación Administrativa nº
43/08, de 28 de julio de 2008 sobre modificaciones de los contratos,
pág 8.
[7] Métricas de servicio:
http://en.wikipedia.org/wiki/Service_level_agreement#Common_metr
ics