Reglas para escribir buenos casos de uso Saludos a todos.

Desde principios de verano estoy colaborando con la empresa Icinetic (www.icinet ic.com) aplicando algunas de mis ideas sobre pruebas para mejorar su proceso de fabricacin de software y tambin desarrollando nuevos servicios. Uno de los primeros pasos para poner en marcha un proceso de prueba es tener bue nos casos de uso. Cuanto mejor sean los casos de uso, ms fcil ser fabricar el softw are y elaborar buenas pruebas. En Icinetic tienen su propio conjunto de reglas p ara desarrollar buenos casos de uso y, adems, me han dado permiso para difundirla s. Estas reglas son: 1. El caso de uso se inicia con la accin de un actor. 2. El caso de uso tiene una precondicin y una postcondicin 3. Mostrar todas las excepciones posibles, as como los flujos alternativos. Al me nos datos incorrectos y error al guardar los datos 4. Mantener el mismo nivel de abstraccin. 5. Rastreabilidad hacia el requisito/s de informacin y el objetivo/s por el que s e ha incluido el caso de uso. 6. Comprobar que las relaciones entre casos de uso (include y extends) sean cons ecuentes con diagramas de casos de uso. 7. Comprobar que los actores que inician los casos de uso sean consecuentes con los diagramas de caso de uso 8. En las eliminaciones comprobar revisando los requisitos de informacin si se de bera eliminar ms elementos en cascada. En tal caso detallarlo en la postcondicin. En general, este conjunto de reglas me parece muy bueno. A continuacin incluyo lo s comentarios que les hice a ellos para que el conjunto de reglas fueran an mejor . Completamente de acuerdo con las reglas 1, 4, 6 y 8. No estoy muy convencido de que un caso de uso deba tener siempre una precondicin y una postcondicin. Si no identificamos claramente una pre o postcondicin vale ms l a pena no ponerla que forzar la situacin. Por regla general, una precondicin expresa el estado que debe tener el sistema pa ra poder ejecutar un caso de uso y una postcondicin el estado en el que queda el sistema despus de ejecutar un caso de uso. Por ejemplo, no se me ocurre ninguna p ostcondicin para un caso de uso de realizar una bsqueda ya que no cambia nada en e l sistema. Poner por poner es para nada. La regla 5 puede hacerse ms genrica. Es buena idea que cualquier requisito sea ras treable, y no solo los requisitos de almacenamiento de informacin. La regla 7 me parece un poco ambigua. Cuando, en un diagrama de casos de uso hay ms de un actor que participa en un caso de uso, no hay, que yo conozca, ninguna notacin para saber cul es el actor que comienza el caso de uso. Yo les propuse esc ribir esta regla de una forma ms genrica: comprobar que los actores participantes e n un caso de uso son consecuentes con los diagramas de casos de uso . Adems, les propuse aadir las siguientes reglas, la mayora sacadas sobre todo del li bro Writting Effective Use Cases de Cockburn. 9. Si el caso de uso se inicia por la accin de un actor, al final de dicho caso d

e uso el actor debe obtener un resultado (salvo que el caso de uso sea una inclu sin o extensin de otro caso de uso. Entonces, probablemente, no se inicie con a ac cin de un actor.) 10. Comprobar que el caso de uso sea como un partido de tenis (El actor hace El s istema hace ) y como un partido de ftbol (se sabe en todo momento qu pasa y quin lo h ace) 11. Un caso de uso de 3 pasos o menos o de ms de 10 pasos probablemente no sea un buen caso de uso (salvo que el caso de uso sea una inclusin o extensin de otro ca so de uso).

12. Todas las acciones similares deben describirse con las mismas frases. Por ej emplo, enunciar todas las inserciones de datos con la frase El actor X introduce los datos . . No permitir variantes como inserta datos , aade datos , incluye datos , n era introducir datos , etc. Siempre igual, por muy aburrido que resulte. Por cierto, la regla 12 es muy til cuando varias personas distintas escriben caso s de uso y tambin a la hora de utilizar herramientas software de anlisis de casos de uso y de generacin de pruebas. Como resumen de todo lo visto: un buen requisito y caso de uso debe tener estas caractersticas: completo, correcto, no ambiguo, validado, verificable y rastreabl e. a. Un requisito completo es aquel que lo cuenta todo, si hay un limite dice cul e s, si hay algo que hacer dice el qu, etc. b. Un requisito correcto es aquel que est bien escrito, si faltas de ortografa, ni errores sintcticos y que, adems, sigue correctamente las reglas para definir requ isitos que se estn usando. c. Un requisito validado es un requisito que ha sido visto y comprendido por el cliente (y ha dado su visto bueno). d. Un requisito no ambiguo es aquel requisito que tiene el mismo significado par a todo el que lo lea. e. Un requisito verificable es un requisito que expresa cosas que se pueden prob ar. Un ejemplo de requisitos no verificables son los que dependen de que una per sona haga algo determinado (llevar un paquete, comprobar que los cdigos estn corre ctos, etc.). f. Un requisito rastreable es un requisito que se sabe de dnde viene y se sabe a dnde va.