martes, 14 de febrero de 2012

Revisión de Especificación de Requerimientos

Cuando un requerimiento pasa por una puerta de calidad, se puede tener confianza acerca de la corrección y viabilidad de los requisitos. ¿Pero qué ocurre con la especificación en conjunto? En este punto se sabe que los requerimientos son correctos, pero ¿se puede asegurar que todos estos requerimientos, en conjunto, describen la "historia" completa?

El término especificación de requerimientos hace referencia a la colección de requerimientos especificados y definidos previamente. La especificación no tiene que estar en un determinado formato, puede ser una especificación sobre papel, o un blog, o algo similar.

Una vez que la especificación de los requerimientos está completa se tendrá un conocimiento preciso del alcance y funcionalidad del producto. Este es el momento de llevar a cabo la revisión de la especificación. En esta revisión final se valida que no falta ningún requerimiento.

Otro punto muy importante a tener en cuenta es asegurarse de que los requisitos tengan consistencia, y en caso contrario, que cualquier conflicto entre los requerimientos ha sido resuelto. Dos requerimientos están en conflicto si no pueden implementarse juntos, es decir, si la solución a un requerimiento impide la implementación de otro.

Cuando las expectativas del cliente son altas, la fecha de entrega y los recursos son limitados, es importante asegurarse de que las funciones más importantes del producto sean entregadas y además tan pronto como sea posible. Otro problema que se puede plantear es que haya demasiados requerimientos.

La solución a los problemas anteriores es la priorización de los requerimientos.

Verificación de los Requerimientos

En esta fase, el usuario final añade criterios de aceptación para cada requisito. Además, apoya el hecho de que los requerimientos han de ser correctos antes de que sean entregados a los diseñadores y desarrolladores.

La puerta de calidad es un punto por el que pasan cada uno de los requerimientos antes de formar parte de la especificación.

Una de las tareas de las puertas de calidad es asegurarse de que cada requerimiento cumple con el criterio que tiene asignado. Este criterio es una medida del requisito que le hace entendible y con capacidad para ser probado.

Otra razón por la que el proyecto tiene puertas de calidad es para prevenir posibles fugas de requerimientos. Los requerimientos, algunas veces, aparecen en las especificaciones sin que nadie realmente sepa de dónde vienen y qué valor añaden al producto. Asegurándose de que la única forma de que los requerimientos entren a formar parte de las especificaciones sea a través de las puertas de calidad, el equipo del proyecto tiene un total control de los requerimientos.

Definición de Requerimientos - Buenas Prácticas

  • Los requerimientos son escritos de una forma tecnológicamente neutra, es decir, especifican lo que el producto hace y no qué tecnología se usará para crearlo.
  • Su especificación NO debe ser ambigua.
  • Eliminar todos los pronombres de la especificación de requerimientos, sustituyéndolos por los sujetos.
  • Tener cuidado con adjetivos y adverbios ya que pueden llevar a confusiones.
  • Se debe evitar usar palabrasque lleven a confusión al escribir los requerimientos, cómo "debería", ya que da a entender que el requisito es opcional.
  • Al escribir los requerimientos una buena técnica es leerlos en voz alta. Y si es posible, pedir a alguien que los lea.
  • Confirmar que los involucrados en el negocio tienen el mismo entendimiento acerca de los requerimientos que la persona que los escribe.
  • Utilizar una convención de nombres y definiciones comunes dentro de la organización. De esta forma se aseguran que en todos los proyectos se está usando el mismo vocabulario.

Definiendo los Requerimientos

Conseguir que los requerimientos estén claramente definidos puede ser difícil. Para ello es importante:

  • Definir los requerimientos teniendo en cuenta la perspectiva del cliente/usuario.
  • Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un requerimiento ha sido especificado satisfactoriamente para un producto y que el producto ha tenido éxito, el requerimiento no tendrá que volverse a inventar, podrá ser utilizado las veces que se desee.
  • Documentas los requerimientos de la forma correcta. Aunque escribir los requerimientos puede parecer una tarea tediosa, es la única manera de asegurar que la esencia de los requerimientos ha sido capturada correctamente y que esto pueda ser aprobado.

Un mal uso del lenguaje puede llevar a un mal entendimiento, horas de trabajo perdido, una mala comunicación entre miembros del equipo, y en definitiva una especificación de requerimientos de poca calidad.

miércoles, 8 de febrero de 2012

Necesidad de la Ingeniería de Software

  • Para construir algo, antes hay que entender qué es ese "algo".
  • Si la aplicación funciona, pero no satisface las necesidades del cliente... ¿de que sirve?
  • En general, los requerimientos expresan qué debe hacer una aplicación, sin decir cómo debe hacerlo: expresan el punto de vista del cliente, que sabe lo que quiere (en el mejor de los casos), pero no tiene por qué saber cómo conseguirlo:
  • A menudo el cliente ni siquiera sabe lo que quiere.
  • La tarea del analista es ayudar a que el cliente se exprese.

Qué es la ingeniería de requerimientos

  • Es la rama de la ingeniería de software que se ocupa de la primera etapa en el proceso de desarrollo del software: la comprensión y formalización de las necesidades que debe satisfacer un sistema informático.
  • "Es el desarrollo sistemático de los requisitos a través de un proceso iterativo y cooperativo en el que se analiza el problema, se documenta el resultado en diversos formatos de representación, y se comprueba la exactitud de la comprensión alcanzada" (Locopaulos & Karakostas. Systems Requirements Engineering. McGraw-Hill, 1995).
  • Se pueden distinguir dos fases en el proceso:
    1. Captura: interacción cuidadosa con todos aquellos interesados en la aplicación o sistema informático; adquisición de información, "requisitos en bruto".
    2. Análisis: estudio cuidadoso de la información adquirida para lograr una verdadera comprensión de los requisitos y estructurarlos adecuadamente; expresar los requisitos de forma concreta y detallada; refinamiento, depuración, estructuración, "requisitos depurados".
  • Obtener los requisitos correctos es un proceso difícil:
  • Adivinar los deseos y necesidades que habitualmente el cliente no es capaz de describir más que en forma confusa, incompleta y desordenada.
  • Los requisitos no se descubren, se inventan; los requisitos no están ahí esperando que alguien los descubra, sino que son creados, construidos o inventados en un proceso interactivo entre el cliente y el ingeniero.
  • La mayor parte de los defectos en el software entregado tienen su origen en el análisis de requisitos, y son en general los más difíciles de reparar.
  • El éxito en el producto requiere colaboración y comunicación fluida entre clientes y desarrolladores: cuanto más completo y menos ambiguo sea el conjunto de requisitos, más probabilidades de éxito.
  • El resultado del proceso es el "documento de requisitos", que es uno de los productos (o artefactos del proceso de desarrollo de software: modelos de diseño, código fuente, pruebas, manuales...

martes, 7 de febrero de 2012

Qué es el Levantamiento de Requerimientos

El Levantamiento de requerimientos se define como el proceso de identificar las necesidades del negocio, solucionando las posibles disparidades entre las personas involucradas en el mismo, con el propósito de definir y destilar los requerimientos para cumplir las restricciones impuestas por las distintas partes.

Un buen proceso de levantamiento de requerimientos soporta el desarrollo de la especificación de los requerimientos, de tal forma que tengan los siguientes atributos:

  • Deben ser completos, consistentes y han de estar dentro del alcance del proyecto.
  • Deben tener un único identificador.
  • Cumplen con los objetivos de los clientes.
  • Son viables y apropiados para el desarrollo.
  • Los requerimientos han de ser "testeables" (deben tener capacidad de prueba).