Temas UNIDAD 1

Requerimientos de Software Actores e Involucrados relevantes Qu es un caso de uso? Cundo usar casos de uso?

Requerimientos de Software
Un requerimiento es considerado una condicin o capacidad a la que se debe ajustar el sistema que se est desarrollando Un requerimiento es una capacidad o cualidad que el sistema ofrece. Los requerimientos pueden ser funcionales y no funcionales. Los requerimientos funcionales definen los servicios que el sistema ofrece al usuario. Ej. Agregar registro de contrato, Eliminar registro. Los requerimientos no funcionales definen aspectos de calidad del sistema. Ej. Performance, usabilidad, etc. Requerimientos Los requerimientos funcionales de software describen las funcionalidades en trminos del sistema que entregan valor al usuario. Los requerimientos funcionales de software deben concentrarse en el qu y no el cmo. Proveen una definicin de caja negra del sistema.

Objetivos de los requerimientos Llegar a un acuerdo formal con los clientes y Usuarios finales sobre lo que el sistema debe de

Hacer. Proporcionar a los miembros del proyecto una Idea clara de los requerimientos del sistema. Delimitar las fronteras del sistema. Proporcionar las bases para la planificacin del Contenido tcnico de las iteraciones, los costos y el tiempo para el desarrollo del sistema. Definir la interface grfica del sistema

Como capturar requerimientos Entrevistas. Cuestionarios. Encuestas. Descripcin de puestos. Artefactos del Modelado de Negocio TCNICAS DE RECOPILACIN DE INFORMACIN Los analistas utilizan una variable de mtodos a fin de recopilar los datos sobre una situacin existente, como entrevistas, cuestionario, inspeccin de registros y observacin. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigacin completa. A continuacin se vern cada una de ellas. ENTREVISTA Las entrevistas se utilizan para recabar informacin en forma verbal, a travs de preguntas que propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos que proporcionaran datos o sern afectadas por la aplicacin propuesta. El analista puede entrevistar al personal en forma individual o en grupos. Recabar datos mediante la entrevista. La entrevista es una forma de conversacin, no interrogacin! Al analizar las caractersticas de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre ese sistema los analistas pueden conocerlos datos que no estn disponibles en ninguna otra forma. En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la informacin son importantes. La informacin cualitativa est relacionada con opiniones, polticas y descripciones cuantitativas tratan con nmeros, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de

informacin cualitativa; los otros mtodos tienden a ser mas tiles en la recabacin de datos cuantitativos. Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como resultado de esto las entrevistas pueden descubrir rpidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a menudo es ms fcil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios. Generalidades de la entrevista. La estructura de las entrevistas vara. Si el objetivo de la entrevista radica en adquirir informacin general, es conveniente elaborar una serie de preguntas sin estructura, con una seccin de preguntas y respuestas libres. La atmsfera abierta y de fcil flujo de esta modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin embargo, cuando los analistas necesitan adquirir datos ms especficos sobre la aplicacin o desean asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores. Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para las preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Todas las personas que responden se basan en un mismo conjunto de posibles respuestas. La confiabilidad es solo una consideracin en la seleccin del mtodo de entrevista. Los analistas tambin deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparacin, porque no se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las respuestas despus de las entrevistas lleva ms tiempo que con las entrevistas estructuradas. De cualquier manera, el mayor costo radica en la preparacin, administracin y anlisis de las entrevistas estructuradas para preguntas cerradas.

Dado que un nmero de personas se seleccionara para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen informacin que no se podr conseguir de otra forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan la factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal de supervisin. Sin embargo, durante la investigacin detallada en donde el objetivo es descubrir hechos especficos, opiniones y

conocer como se manejan las operaciones desempeadas actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen de quien pueda proporcionar la mayor parte de la informacin til para el estudio. As, los analistas que estudian ala administracin de inventarios pueden entrevistar a los trabajadores del embarque y de recepcin, al personal del almacn y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacn; tambin entrevistaran a los agentes ms importantes. Realizacin de la entrevista. La habilidad del entrevistador es vital para el xito en la bsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparacin del objetivo de una entrevista especfica como de las preguntas por realizar a una persona determinada. El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de xito. Por ejemplo, un analista que trabaja en la aplicacin enfocada a la reduccin de errores probablemente no tendra xito si llegar a una oficina de gerencia de nivel medio con la presentacin equivocada, por ejemplo, si dijera, "hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aqu. O la introduccin: "Estamos aqu para resolver su problema", es igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo. A travs de la entrevista, los analistas deben preguntarse a s mismos las siguientes interrogantes: Qu es lo que me est diciendo la persona? Por qu me lo est diciendo a m? Qu se est olvidando? Qu espera esta persona que haga yo? Si se considera cada elemento de la informacin contra estas preguntas, los analistas tendrn ms conocimientos no solamente de la informacin adquirida sino tambin de su importancia. C U E S T I O N A R I O. Los cuestionarios proporcionan una alternativa muy til para las entrevistas; sin embargo, existen ciertas caractersticas que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.

Recabacin de datos mediante cuestionarios Para los analistas los cuestionarios pueden ser la nica forma posible de relacionarse con un gran nmero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos con relacin al sistema. Por supuesto, no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios. Tambin las preguntas estandarizadas pueden proporcionar datos ms confiables. Por otra parte, las caractersticas anteriores tambin son desventajas de los cuestionarios. Aunque su aplicacin puede realizarse con un mayor nmero de individuos, es muy rara una respuesta total. Puede necesitarse algn seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas se encontraran en una proporcin entre el 25 o 35%, que es lo ms comn. Seleccin de formas para cuestionarios . El desarrollo y distribucin de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. Tambin es importante el formato y contenido de las preguntas en la recopilacin de hechos significativos. Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de sistemas. Cuestionarios abiertos. Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; tambin son tiles al explorar el problema bsico, por ejemplo, un analista que utiliza cuestionarios para estudiar los mtodos de verificacin de crdito, en un medio ambiente de ventas al a menudeo, podra recabar mas informacin provechosa de una pregunta abierta de este tipo: Cmo podra simplificarse y mejorarse el proceso de verificacin de crdito para los clientes? Cuestionarios cerrados. El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor mtodo para obtener informacin sobre los hechos. Tambin fuerza a los individuos para que tomen una posicin y forma de opinin sobre los aspectos importantes.

Etapas en el desarrollo de un cuestionario Los cuestionarios bien hechos no se desarrollan rpidamente, llevan tiempo y mucho trabajo. La primera consideracin se encuentra en determinar el objetivo del cuestionario. Qu datos quiere conocer el analista a travs de su uso? El analista define como utilizar los cuestionarios a fin de obtener los hechos al considerar la estructura mas til para el estudio y la ms sencilla de entender por parte de los interrogados. Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es necesario, antes de que imprima una forma final y se distribuya. Seleccin de quienes recibirn el cuestionario Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la informacin que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir ampliamente sin un anlisis previo. Lo pueden contestar personas no calificadas y si el cuestionario no es annimo, y no ser posible retirar sus respuestas de la muestra. La realizacin de esto tambin es desgastante y cara.

OBSERVACION Ver es creer! Observar las operaciones le proporciona la analista hechos que no podra obtener de otra forma. Recopilacin de datos mediante la observacin Leer en relacin con una actividad del negocio le proporciona al analista una dimensin de las actividades del sistema. Entrevistar personal, ya sea directamente o a travs de cuestionarios, tambin le ayuda y le dice algo ms. Ninguno de los dos mtodos da una informacin completa; por ejemplo, leer en relacin con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies de altura. La observacin proporciona informacin de primera mano en relacin con la forma en que se llevan a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan las tareas y si ocurren los pasos especficos como se pre-establecieron, pueden contestarse rpidamente si se observan las operaciones. Cuando observar

La observacin es muy til cuando el analista necesita ver de primera mano cmo se manejan los documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que buscar y como guiar su significado, tambin requiere de experiencia. Los observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades; tambin estn alertas para detectar documentos o registros que no se utilizan.

MUESTREO Con frecuencia, en muchas empresas la informacin ya se encuentra disponible para que el analista conozca las actividades u operaciones con las cuales no est familiarizado. Muchos tipos de registros e informes son accesibles si el analista sabe dnde buscar. En la revisin de registros, los analistas examinan datos y descripciones que ya estn escritos o registrados y en relacin con el sistema y los departamentos de usuarios. Esta forma de encontrar datos puede servir como presentacin del analista, si se realiza al iniciar el estudio, o como un trmino de comparacin de lo que sucede en el departamento con lo que los registros presentan como lo que debera suceder. Recopilacin de datos por medio de la inspeccin de registros. El trmino "registro" se refiere a los manuales escritos sobre polticas, regulaciones y procedimientos de operaciones estndar que la mayora de las empresas mantienen como gua para gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos de datos existentes, o sistemas de informacin que entran dentro del rea de investigacin, tambin proporcionan una visin sobre la forma en la que el negocio debera conducirse. Normalmente muestran los requerimientos y restricciones del sistema (como cantidad de transacciones o capacidad de almacenamiento de datos) y caractersticas de diseo (controles y verificacin del procesamiento). Los registro permiten que los analistas se familiaricen con algunas operaciones, oficinas de la compaa y relaciones formales a las que debe darse apoyo. No obstante, no muestran como producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como se realizan las tareas en la actualidad. Los otros mtodos con objeto de encontrar datos estudiados en esta seccin son ms eficaces para proporcionar al analista este tipo de informacin. Seleccin de los registros para revisin En la mayor parte de las empresas los manuales de estndares sobre procedimientos de operacin usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para sealar los procedimientos existentes.

Los diagramas de organizacin muestran como las diferentes unidades deberan relacionarse con otras; pero muchas no reflejan las operaciones actuales.

Actores e Involucrados relevantes

Definicin Actores Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores. Un actor es aquel involucrado relevante que tiene interaccin con el sistema. Puede ser una persona, una empresa u organizacin, un programa o un sistema computacional. Se emplea el trmino de actor para llamar as al usuario, cuando desempea ese papel dentro del sistema. Cuando se trata con actores, conviene pensar en los papeles, no en las personas ni en los ttulos de sus puestos. Los actores llevan a cabo casos de uso. Un mismo actor puede realizar muchos casos de uso; a la inversa, un caso de uso puede ser realizado por varios actores. Se debe tener en cuenta que no es necesario que los actores sean seres humanos, a pesar de que los actores estn representados por figuras humanas en el diagrama de casos de uso. El actor puede ser tambin un sistema externo, que necesite cierta informacin del sistema actual o interacte con l como una base de datos por ejemplo. Una forma fcil de representar casos de uso es haciendo que solo se muestren los actores del sistema cuando ellos sean los que necesiten el caso de uso. Por tanto, si el sistema genera cada noche un archivo que despus es recogido por el sistema de contabilidad, entonces este es el actor que corresponde, debido a que es quien necesita el archivo generado. Un involucrado relevante es aquel que tiene un inters de por medio en las funcionalidades del sistema. El actor primario es aquel que generalmente inicia un caso de uso. Los involucrados relevantes pueden participar o no en un caso de uso. Elementos

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.

Qu es un caso de uso?
Tpicamente los casos de uso son tiles para documentar requerimientos funcionales de un sistema o para documentar los procesos de negocio de una organizacin (casos de uso de negocio). Un caso de uso describe el comportamiento de cmo un sistema responde a las solicitudes de uno de los involucrados relevantes llamado actor primario. El sistema responde protegiendo los intereses de todos los involucrados relevantes. Los casos de uso son generalmente un documento de texto. Sin embargo, pueden ser representados como diagramas de flujo, diagramas de secuencia, redes de Petri o en un lenguaje de programacin. Un caso de uso debe ser fcil de leer. Contiene oraciones de una sola forma gramtica -pasos que representan una accin- en las que el actor alcanza una meta. Sirven como un medio de comunicacin entre personas que no tienen habilidades especializadas en el rea de desarrollo de software, por lo cual los casos de uso en forma de documentos de texto son la mejor opcin. Para escribir un caso de uso efectivo se deben tener en cuenta los siguientes tres aspectos: Alcance: Qu es el sistema en discusin. Actor primario: Quin tiene la meta. Nivel: Que tan alto o bajo es el nivel de esa meta. Un caso de uso puede ser representado como una secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema. Relaciones de Casos de Uso Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones.

Inclusin (include o use) Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a una descripcin individual, desde el caso El estndar de Lenguaje de Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin grfica y las descripciones son importantes, ellos forman parte de la documentacin de un caso de uso --un propsito para el que el actor puede usar el sistema. de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "include". Este uso se asemeja a una expansin de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parmetros o valores de retorno. Aqu tambin podemos decir q este va de padre a hijo.

Extensin (Extend) Es otra forma de interaccin, un caso de uso dado, (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de La extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. Uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin. "La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos." Generalizacin "Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intencin y extensin." En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma

especializada de un caso de uso existente. La notacin es una lnea slida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de subclases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados . Ejemplos de casos de uso Para comprender un poco mejor la funcionalidad de los casos de uso, se da un pequeo ejemplo de cmo funcionan todos los elementos integrados en un diagrama, tanto actores como relaciones y casos de uso como tal. Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea. En la Figura se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automtico.

Con este ejemplo podemos comprender las diferentes relaciones entre Casos de Uso

Un caso de uso, en principio, debera describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin con un alcance menor como caso de uso. La razn para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicacin en el equipo de desarrollo, el manejo de la documentacin de casos de uso. Para el caso de que queramos utilizar estos casos de uso ms pequeos, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: Incluye (<>): Un caso de uso base incorpora explcitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial comn a varios casos de uso. En la Figura se muestra cmo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorizacin.

Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos de extensin) en los cuales, dependiendo de ciertos criterios, se va a realizar una interaccin adicional. El caso de uso que extiende describe un comportamiento opcional del sistema (a diferencia de la relacin incluye que se da siempre que se realiza la interaccin descrita) En la Figura se muestra como el caso de uso Comprar Producto permite explcitamente extensiones en el siguiente punto de extensin: info regalo. La interaccin correspondiente a establecer los detalles sobre un producto que se enva como regalo estn descritos en el caso de uso Detalles Regalo.

Ambos tipos de relacin se representan como una dependencia etiquetada con el estereotipo correspondiente (<> o <>), de tal forma que la flecha indique el sentido en el que debe leerse la etiqueta. Junto a la etiqueta <> se puede detallar el/los puntos de extensin del caso de uso base en los que se aplica la extensin. Generalizacin ( ): Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso ms especfico. Se representa por una lnea continua entre los dos casos de uso, con el tringulo que simboliza generalizacin en UML (usado tambin para denotar la herencia entre clases) pegado al extremo del caso de uso ms general. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y caractersticas del caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto, que no est definido completamente. Este tipo de relacin se utiliza mucho menos que las dos anteriores.

Cundo usar casos de uso?

Son una herramienta esencial para la captura de requerimientos, la planificacin o el control de proyectos iterativos. La captura de los casos de uso es una de las tereas principales durante la fase de elaboracin; de hecho es lo primero que se debe hacer. La mayora de los casos de uso se generaran durante la fase del proyecto, pero se irn descubriendo otros a medida que se avance. Todo caso de uso es un requerimiento potencial y hasta que o se hayan capturado todos los requerimientos, no se podr planear como se manejaran estos en el proyecto. Algunas personas prefieren listar y analizar los casos de uso primero y luego llevar a cabo un poco de modelado. Esta fase ayuda en gran medida a comprender mejor los procesos de interaccin, el modelado conceptual ayuda a descubrir los casos de uso.

Los diseadores emplean casos de uso en distintos grados de granularidad. Pero es recomendable o manejar demasiados, que hagan tedioso y extenso el trabajo dependiendo de su interpretacin. Para concluir podemos comentar que los casos de uso se usan cuando se desea definir el comportamiento de un sistema de una manera clara, coherente y fcil de entender. Cuando se tienen la necesidad de comunicar el comportamiento de un sistema con miembros de un equipo multidisciplinario. Cuando es necesario documentar los requerimientos funcionales de un sistema. Cuando se desea estimar el esfuerzo que representar el diseo y construccin de un sistema.