Lo primero que recomendaría es empezar por lo básico, los fundamentos. Tratar de entender la norma ISO9001 es complicado si no conoces los principios de gestión de la calidad. Por ello es recomendable leerse y estudiar la norma ISO9000 que lleva el título de Sistemas de gestión de la calidad —Fundamentos y vocabulario. Es importante entender bien las definiciones y conceptos para comprender mejor el texto de la ISO9001. Parece una perogrullada, pero si empezáis a leer la ISO9001, sin haber comprendido los conceptos que trata, no os va a servir de nada. Aun así, el texto a veces es ambiguo y puede dar lugar a varias interpretaciones.

En cuanto a vuestras expectativas, si no habéis leído otras normas y esperáis un guía para implantar un sistema de gestión de la calidad, os llevaréis una decepción. Es una norma que ha de valer para todo tipo de empresas de cualquier tamaño y sector. Por tanto, sólo recoge los requisitos del sistema.

Hablar de ISO9001, también es hablar de los procesos. La norma recomienda o, más bien, exige, que la empresa adopte un enfoque basado en procesos. Es aconsejable tener identificados los diferentes procesos de tu empresa y sus interacciones entre sí.

El siguiente paso es traducir los requisitos en vuestro sistema de gestión de la calidad. Siendo prácticos, los requisitos se traducen en tener un plan y un manual de calidad, definir procedimientos y registrar las evidencias de que éstos se cumplen. Y siempre con la idea de buscar la mejora continua y la satisfacción del cliente. Este es un paso complicado pero podéis contar con un consultor especializado que os ayude a implementar el sistema. Luego sólo queda aplicarlo, velar por su cumplimiento, medirlo, analizarlo y mejorarlo cada año. ¡Fácil!

Para terminar, os dejo la pregunta o reflexión que debemos hacernos antes de abordar a la norma ISO9001. ¿Por qué queremos aplicar la norma ISO9001? Podríamos decir que hay dos tipos de empresas: las que sólo quieren obtener la certificación por motivos estratégicos o comerciales, y las que realmente creen en la eficacia del sistema de gestión de la calidad. Y tú, ¿crees en la ISO9001? ¿Crees que este tipo de normas aportan valor a la compañía? Si ya tienes experiencia ¿ha mejorado la satisfacción de tus clientes con ISO9001?

Los objetivos principales del análisis de requisitos es detectar y resolver los conflictos y definir la arquitectura del software. Un requisito presenta un conflicto cuando es incompatible con otros requisitos y otras partes del sistema, o que no encaja en el entorno operacional y organizativo (y requiere cambios en procesos de negocio o de la estructura organizativa no previstos). Durante el análisis se caracteriza un requisito, es decir, se le asignan atributos como, funcional/no-funcional, prioridad, si es obligatorio, deseabe o innecesario, alcance, volatilidad o estabilidad (probabilidad de sufrir cambios), etc. Otra actividad es el modelado conceptual, para identificar los objetos o entidades y sus relaciones y dependencias que servirán como base para el diseño del software y la base de datos. Este es un tema que trataremos más en profundidad en otro artículo.

En este punto la arquitectura y los componentes del software ya deben estar definidos a partir de los requisitos (incluso podrían haberse esbozado ya antes a partir de requisitos de alto nivel en fases anteriores), aunque depende de la metodología utilizada. Por ejemplo, en una modelo iterativo la arquitectura puede ser modificada o perfeccionada en cada iteración a medida que se detallan o analizan los requisitos..

Lo siguiente es la especificación de requisitos, que consiste en elaborar un documento que recoge la definición de cada requisito y sus atributos, además, de estimaciones de coste y tiempos de desarrollo, riesgo etc. Estos documentos son la base para negociaciones o acuerdos, para validar y verificar el cumplimiento de los requisitos. Tener los requisitos bien documentados facilitará el mantenimiento y la mejora del software. Uno de los principios de la Filosofía Ágil es que se valora más un software que funcione que una buena documentación. Esto no quiere decir que no sea necesario documentar los requisitos, pero tampoco debemos convertirnos en esclavos de la documentación. Si queréis saber cómo hacer la especifícación de requisitos, podéis basaros en el estándar IEEE 830-1998.

La validación de los requisitos consiste en revisar los documentos de especificaciones y el modelo y conseguir la aprobación del cliente. También se puede emplear prototipos para la validación. Muy útil sobre todo para la validación de la interfaz de usuario. Hay que tener claro el objetivo del prototipo para evitar costes innecesarios: no es lo mismo un prototipo para validar una interfaz que un prototipo evolutivo que se convertirá en el entregable final. Es decir, para ahorrar tiempo y dinero con un prototipo, es mejor definir que va a incluir y que no.

Por último, el cliente y usuarios realizan las pruebas de aceptación. Testearán el software entregado y comprobarán si cumple o no con lo acordado en las especificaciones. Esto es la verificación del software. Es un momento delicado. Como ya comentamos en la primera parte, en un proceso en cascada, donde la verificación tiene lugar al final del proyecto, si el software no pasa las pruebas de aceptación, puede suponer el desastre. En modelos iterativos, la verificación se hace al final de cada iteración, con lo que puedes ir corrigiendo los problemas en iteraciones sucesivas.

Otras consideraciones a tener en cuenta es la gestión de cambios. Cuando los objetivos del sofware no están claros desde el principio, será más probable que los requisitos cambien. Hay modelos más o menos flexibles a la hora de asumir un cambio. La documentación de las especificaciones y la trazabilidad de los requisitos ayudarán a identificar el alcance y coste de un cambio. El volumen de requisitos ayudará a estimar el coste del proyecto, el mantenimiento necesario y número de cambios.

Aquí termina este artículo sobre la ingeniería de requisitos basado en las mejores prácticas recogidas en SWEBOK (si queréis saber más, tenéis acceso gratuito a la guía aquí). En otras Categorías del blog hablaremos de modelos de desarrollo y técnicas de modelado y otros aspectos del mundo del desarrollo de software.

El tema lo he dividido en dos partes. En esta primera veremos los tipos de requisitos, cómo deben ser, qué actores intervienen, cómo obtenerlos y qué dificultades podemos encontrarnos.

Aquí hablamos de requisitos del software, es decir, una característica que queremos que cumpla el software que queremos construir. Si hablamos construir un sistema, éstos formarán parte de los requisitos del sistema (hardware, software, redes, información, infraestructuras, personas, etc.). También hay que distinguir entre requisitos funcionales y no funcionales: los primeros son las funciones que queremos haga el software y, el segundo se refiere a requisitos de calidad, seguridad, capacidad, etc.

Los requisitos deben ser cuantificables, es decir, se debe evitar descripciones poco claras o ambiguas y deben ser verificables. Nos permitirá seguir la trazabilidad durante el transcurso del proyecto y medir el grado de cumplimiento de los mismos. En algunos modelos de desarrollo iterativos, se parte de requisitos amplios que describen las metas o factores críticos de éxito y en sucesivas iteraciones se van detallando o desgranando.

Los actores que intervienen en la toma de requisitos son fundamentalmente usuarios, cliente y analistas o ingenieros de software. En algunos casos pueden participar más stakeholders (partes interesadas).

Antes de empezar la toma de requisitos es importante que todas las partes comprendan el problema que el software va a solucionar, quiénes van a ser los actores y de qué forma van a ser las relaciones entre cliente y el equipo de desarrollo. Un aspecto fundamental es la comunicación entre usuarios y los analistas. El analista de tener conocimientos del ámbito o domino del que se trate (Sanidad, Industria, Banca, Seguros, etc.), es decir, debe saber lo que el usuario quiere decir y detectar lo que no le cuenta. La experiencia y conocimiento del analista ayudan a interpretar mejor lo quiere o hace el usuario e identificar con más facilidad conflictos entre requisitos.

Por último, describimos las técnicas que podemos emplear para la recogida de requisitos:

• entrevistas, el método tradicional
• escenarios, donde se plantean situaciones a los usuarios y se hacen preguntas sobre sus tareas
• prototipos, hay varias técnicas de prototipado en función de lo que se persiga: aclarar requisitos confusos, validarlos o ver el diseño de la interfaz de usuario
• reuniones, intervienen varios de los stakeholders con lo que permite identificar requisitos en conflicto con alguna de las partes implicadas.
• observación, el analistas observa al usuario en su tarea. Permite conocer bien el proceso de negocio

Hay que destacar que la toma de requisitos no es una actividad pasiva. El analista se encontrará dificultades, como usuarios que no describen bien sus tareas o necesidades, que se dejan información importante o poco dispuestos a cooperar. Normalmente en todos los proyectos ocurren estos problemas, pero también hay mecanismos para corregirlos o minimizar las consecuencias.

En la segunda parte hablaremos del análisis y validación de los requisitos.

Este libro proporciona las pautas para la dirección de proyectos, describe normas, métodos, procesos y prácticas establecidos, aunque se trata más de una guía que de una metodología.

Primero define los términos clave y fundamentos de la gestión de proyectos, así como características del ciclo de vida, los interesados o stakeholders, la estructura organizativa (funcional, matricial y orientada a proyectos), etc.

En segundo lugar presenta los procesos de la Dirección de proyecto agrupados por las actividades que tienen lugar en cualquier tipo de proyecto, fase o subproyecto -Iniciación, Planificación, Ejecución, Seguimiento y control y Cierre- en lo que llama norma para la Dirección de proyectos. Puntualiza que lo norma no se debe aplicar tal cual en todos los proyectos, sino que se ha de estudiar qué procesos son necesarios en cada caso.

Por último, hace una nueva clasificación reagrupando actividades y procesos relacionados en Áreas de Conocimiento:

• Gestión de la Integración del Proyecto. Describe los procesos y actividades que forman parte de los diversos elementos de la dirección de proyectos.
• Gestión de Alcance. Abarca los procesos necesarios para asegurar que el proyecto incluye todo el trabajo requerido para completar el proyecto satisfactoriamente.
• Gestión del Tiempo. Procesos relativos a la puntualidad en la conclusión del proyecto
• Gestión de los Costes. Describe los procesos involucrados en la planificación, estimación, presupuesto y control de costes de forma que el proyecto se complete dentro del presupuesto aprobado
• Gestión de la Calidad. Conjunto de procesos necesarios para asegurar que el proyecto cumple con los objetivos definidos
• Gestión de los Recursos Humanos. Describe los procesos que organizan y dirigen el equipo del proyecto
• Gestión de las Comunicaciones. Procesos relacionados con la generación, recogida, distribución, almacenamiento y destino final de la información del proyecto en tiempo y forma
• Gestión de Riesgos. Procesos que tienen que ver con el desarrollo de la gestión de riesgos de un proyecto
• Gestión de las Adquisiciones del Proyecto. Describe los procesos para comprar o adquirir productos, servicios o resultados, así como para contratar procesos de dirección

Para cada proceso enumera y define entradas, herramientas y técnicas y salidas, así como la interacción con otros procesos.

En resumen, es una guía completa que define todas las actividades que pueden ser necesarias para la Dirección de proyectos. Aunque no hay que olvidar que se trata de una guía y por tanto nos sirve como referencia o punto de partida para definir las actividades y procesos más adecuados para cada proyecto o fase del mismo.