Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Captura de requisitos
Objetivo: descubrir y representar los requisitos e ideas que debe cumplir un nuevo sistema o la mejora de un sistema
Qu hay inicialmente? Inicialmente hay un gran volumen de informacin: requerimientos del usuario, del dueo del negocio, modelos del dominio, productos, etc.
Captura de requisitos
Se colectan requisitos brutos desde varias fuentes Se documentan explcitamente como una lista dividida en dos grandes grupos de requisitos:
Funcionales: dicen lo que el usuario puede hacer con el sistema No-funcionales: establecen restricciones y lmites tcnicos a la implementacin.
cmo estas?
Requisitos funcionales
1) El usuario puede enviar mensajes cortos desde un PC a travs de un telfono mvil adherido al PC 2) El usuario puede almacenar y cargar nmeros telefnicos basado en nombres de receptores (destinatarios) 3) El usuario puede construir listas de correo de mltiples destinatarios
Requisitos funcionales
4) El usuario puede almacenar y reutilizar dichos comunes como frases 5) El usuario puede grabar los mensajes enviados y ms tarde puede mirarlos y reutilizarlos
Requisitos no-funcionales
1) El sistema debe correr en plataformas Windows y Macintosh 2) El sistema debe permitir mltiples accesos simultneos a los nmeros de telfono almacenados as como a los grupos 3) El sistema debe almacenar los datos de las tonadas en archivos tipos ASCII delgado.
Casos de uso
El concepto del producto y la lista de requisitos es slo el comienzo del proyecto de desarrollo de un software En OMT++ se usan los casos de uso para que el usuario final y el desarrollador discutan los requisitos y se formen una comprensin comn sobre el tipo de sistema a desarrollar
Casos de uso
Los requisitos funcionales especifican qu debera hacer un sistema Un caso de uso describe cmo el sistema y el usuario final haran algo en forma conjunta El usuario final es un ser humano o cualquier otra entidad externa. Un caso de uso describe un flujo de eventos entre el usuario y el sistema
Casos de uso
El modelo de casos de uso usa actores para representar roles que los usuarios pueden jugar y usa casos para representar cmo los actores cooperan con el sistema. Un actor es tpicamente un usuario en un rol especfico. Tambin puede ser otro sistema que pide servicios.
Casos de uso
Los casos de uso explican las acciones de los actores y las respuestas del sistema. Los casos de uso ilustran escenarios de uso tpico del sistema (secuencia normal, feliz). Guan el diseo y la implementacin final del sistema. El sistema debera ser probado contra los casos de uso para verificar la equivalencia entre los casos de uso y el sistema final.
Casos de uso
Los casos de uso son ejemplos concretos de cmo un actor usa el sistema para obtener beneficios concretos.
La tcnica de los casos de uso es una herramienta para colectar y analizar diferentes formas de usar el sistema, y entrega un medio de comunicacin en la fase de captura y anlisis de los requisitos.
Casos de uso
10 mandamientos para obtener buenos casos de uso. (Segn los autores de OMT++)
Referencia: A. Jaaksi 'Our Cases with Use Cases', in Journal of Object-Oriented Programming, Vol 10, No 9, February 1998, pp 58 -65.
Por ejemplo, si es importante para el cliente que el sistema imprima informes, entonces esa tarea debiera estar incluida en uno o ms casos de uso.
2. Un caso de uso describe algo que el diseador estara orgulloso de hacer y que el
cliente estara dispuesto a pagar con gusto
Cada caso de uso debiera describir algo que es beneficioso para el usuario. Por ejemplo, producir un informe de venta suena como un buen caso de uso, mientras seleccionar una impresora es un caso de uso demasiado pequeo y no slo es beneficioso para el usuario final.
El caso de uso debiera describir la manera recomendada para ejecutar una tarea. No debera cubrir temas que quedan fuera de su incumbencia ni tratar de definir todas las posible formas de ejecutar la tarea. Otras maneras de usar el sistema se describe en otro caso de uso o en la seccin de Excepcin del caso de uso en cuestin.
Un caso de uso es como el manuscrito de un obra de teatro que describe lo que debe hacer un actor en un escenario dado. El que tome el lugar de un actor debe ser capaz de jugar su rol. El sistema juega el rol de otro actor. El caso de uso no debe dar demasiada libertad a los actores como para que el acto termine en un caos.
Cada caso de uso debiera ser una historia completa. El comienzo de la historia define las precondiciones y entrega una lista de los pasos iniciales del caso de uso. El cuerpo principal describe la funcionalidad que el cliente pagara con agrado. La parte final describe pasos con los cuales se termina la historia. Un caso de uso sin estas caractersticas es probablemente demasiado dbil.
A cierta edad los nios tienden a escribir historias que describen el flujo explcito de las acciones, una despus de la otra, eso es exactamente lo que un caso de uso debera hacer.
Los casos de uso grandes son difciles de comprender ya que, o son demasiado detallados, o intentan cubrir demasiada funcionalidad. En el ltimo caso el problema se puede resolver quebrando el caso de uso en dos o ms casos de uso.
Cada caso de uso debe hacer afirmaciones claras y explcitas para que cuando la gente lo lea, se pueda formar opiniones fuertes. Un caso de uso debe motivar a los clientes a mejorar el sistema argumentando, discutiendo, hasta lograr un acuerdo con el caso de uso. Si nadie est en desacuerdo con la primera versin de un caso probablemente es demasiado vago o debera ser ms explcito.
Cada caso de uso debera ser concreto y claro para que los clientes y los diseadores lo puedan firmar. Los casos de uso actan como un contrato entre los clientes y los desarrolladores. Nadie debera hacer alguna modificacin a los casos de uso sin la aprobacin de todos.
10. Un caso de uso puede ser usado en el desarrollo y la prueba del sistema
Los casos de uso no se usan en forma aislada. Los casos de uso deberan especificarse para ser usados en las siguientes fases del proceso, por ejemplo, en la fase de anlisis de objetos y la fase de anlisis de comportamiento. Si los casos son suficientemente explcitos ellos se pueden usar como una base para la prueba del sistema.
Ejercicio: escribir un caso de uso que describa el cmo toma lugar este envo Titular el caso de uso: Enviando un mensaje corto
Ejemplo 1
Ejemplo 2
Estudio de factibilidad
Se denomina estudio de factibilidad a la etapa en que se colectan y se analizan por primera vez los requisitos de un sistema Es una fase de clarificacin de los conceptos sobre el producto Ocurre antes de comenzar a monitorear el proceso de desarrollo.
Estudio de factibilidad
Sirve para dos propsitos:
Se colectan requisitos y se sugieren soluciones Se estima el esfuerzo de desarrollo basado en las soluciones sugeridas. Estas estimaciones son la fuente para la decisin de planificar y hacer el proyecto.
Estudio de factibilidad
Cules son los requisitos del sistema o sus mejoras? Cmo ha de funcionar el sistema para satisfacer los requisitos? Es tcnicamente posible implementar el sistema para satisfacer los requisitos? Qu tipo de soluciones diferentes de implementacin se pueden crear?
Estudio de factibilidad
Cul es la solucin ms factible, si la hay? Cunto trabajo se requiere? Dados los datos del anlisis anterior, se debera iniciar el proyecto?
Preguntas ?