Pages Menu
Categories Menu

Posted by on Dic 4, 2012 in General | 7 comments

Lo que no deberíais hacer si redactáis requisitos. Caso práctico: el pliego de la web del senado

Para redactar el pliego de subcontratación de la nueva web del senado, hubiese sido de gran ayuda haber utilizado cualquier libro básico de ingeniería del software, el Presman, o el Code Complete, y su checklist de requisitos, u esta otra checklist de Construx que a mi me gusta especialmente. Hay decenas. E incluso, como poco, podría haberse utilizado la Wikipedia.

En cualquiera de los anteriores vienen bien claramente explicadas las cualidades mínimas que debe cumplir un buen requisito. Y en todos ellos nos hablan de que un requisito debe ser no ambiguo (preciso, única interpretación), simple y atómico, verificable, completo (contener la información necesaria). Y muchas otras cualidades más, pero, para el objetivo del post, con las anteriores es suficiente.

Ya comenté en su día que no hay datos suficientes para valorar si 500.000 € es mucho o poco para hacer la web del senado. Pero en lo que si quería aportar mi humilde ayuda es en las mejoras que podría haber tenido el pliego…

Srs. que hacen los pliegos públicos para subontratar desarrollos software: Los requisitos deben ser no ambiguos, atómicos, verificables y completos (si no luego pueden venir los problemas)

“La página web finalmente obtenida deberá permitir que toda su funcionalidad esté disponible utilizando los principales navegadores del mercado, como Explorer, Firefox, Opera y Chrome. (pág. 8)

“La solución deberá ser multiplataforma, encontrándose certificada para plataformas Linux, AIX y Windows. (pág. 9)

“Dada la naturaleza de este sistema de información, es requisito indispensable que la solución trabaje en alta disponibilidad.” (pág. 11)

Los anteriores son sólo algunos ejemplos extraídos del pliego, sólo algunos ejemplos de requisitos ambiguos, no atómicos, difícilmente verificables y que no están completos. Por ejemplo:

– ¿Qué versión de Firefox o de los otros navegadores? ¿Qué versión  de “plataformas” Linux y demás? Porque de unas versiones a otras hay enorme diferencia.

– ¿Alta disponibilidad? ¿en qué  porcentaje de tiempo de funcionamiento / año? ¿un 90%? ¿98%? La diferencia es tremendamente enorme.

Los anteriores consejos debieran tenerse en cosideración para muchos otros requisitos, como, por ejemplo “Arquitectura escalable”, “Solución orientada a servicios”, “Servicios Web 2.0” o “Solución modular”, entre otros muchos.

Srs. que hacen los pliegos: Es imprescindible especificar los requisitos de calidad software

Convendría recordar aquí la deuda técnica, los costes de la no calidad, o que al final la mala calidad alguien la paga, el cliente o el proveedor, o porque el estado debería ponerse en serio a controlar la calidad del software que subcontrata.

¿Qué mínimos deben cumplir los fuentes? Complejidad ciclomática, estilo de codificación, código repetido, etc. ¿Qué pruebas, verificaciones y validaciones se requerirán? ¿en qué cobertura? ¿Qué tiempos de respuesta? ¿capacidad?

También hubiese sido deseable acotar la calidad del proceso con el que se construirá el software. Costes de un mal proceso de desarrollo software. Si desarrollas mal estás perdiendo dinero

Pero en todo el pliego la palabra calidad aparece sólo una vez…. “fotos de alta calidad”.

Terminando…

No queriendo extender más el post, no he tocado otros temas tan importantes como la seguridad, etc.

Puede que quizás, yo no tengo la certeza, la idea era que fuese el proveedor quien terminase y especificase los requisitos. Lo digo a tenor de esta frase del pliego: ”El licitador incluirá […] el detalle de los requisitos funcionales”. Sí eso es así, no se que me da más miedo, si requisitos mal especificados o que sea el proveedor el que le hace los requisitos al cliente.

Ya sabes, comparte y tuitea, y me ayudas a compartir el conocimiento.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

7 Comments

  1. Interesante temática la de este post. Yo me haría un par de preguntas sobre el tema de la redacción de pliegos técnicos informáticos en nuestras AAPP.

    La primera, si no sería bueno exigir que este tipo de pliegos esté redactado por personal con suficiente cualificación, Ingenieros Informaticos por ejemplo ¿No sería una de las futuras atribuciones que deberíamos conseguir si llega a regularse la profesión? Basandome en mi experiencia estos pliegos los redactan (o cortan y pegan) desde auxiliares informáticos, a personal administrativo o con suerte un tecnico superior informático (grupo A1) pero al que seguro no le exigieron el título de Ingeniería Informática para acceder a su plaza.

    Y la segunda pregunta (que me preocupa mucho), es si estamos los Ingenieros Informáticos suficientemente formados para redactar estos pliegos. Tal vez deberíamos empezar por ofrecer formación a través de nuestros colegios y asociaciones profesionales, de temas como este y otros relativos a la alta dirección. Si queremos algún día asumir estos roles directivos.

  2. A mi me sorprende que no se haya utilizado ningún estándar para formalizar la espcificación de requisitos, aunque desconozco si la administración pública obliga a utilizar algún tipo de plantilla.

  3. quien gano la licitación?

  4. Hola,

    Aquí puedes ver más datos http://www.javiergarzas.com/2012/11/nueva-web-del-senado.html

    Te adelanto desde la anterior referencia que… Según datos oficiales, este artículo y este, el importe de la adjudicación se divide en las siguientes consultoras: 281.325 euros para Vass, 118.338 euros para GFI y 49.156,25 euros para Ibermática.

    Saludos

  5. Estamos realizando una encuesta por Internet para conocer la práctica del reuso durante los procesos de ingeniería de requisitos en los proyectos de desarrollo de software.
    Es una encuesta orientada a profesionales con experiencia en elicitación y especificación de requisitos.
    Aquellos que tengáis ese perfil os agradeceríamos que la contestéis (estará abierta hasta mediados de julio).
    http://www.upc.edu/gessi/PABRE/Survey.html
    Carme

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: Para redactar el pliego de subcontratación de la nueva web del senado, hubiese sido…
  2. Lo que le contaría a Dijkstra: da igual que hagas mal software, al final… nunca pasa nada - Javier Garzás, sobre calidad software y otros temas relacionados - [...] unos mínimos a la hora de redactar los pliegos (dejo post sobre el tema) y realizar la contratación. Ni…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This