Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Modelado de requerimientos del sistema con los casos de uso.

No description
by

Enrique Merino

on 5 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Modelado de requerimientos del sistema con los casos de uso.

Modelado de requerimientos del sistema con los casos de uso. Modulación de casos de uso 1986 Introducción Los casos de uso Un actor inicia la actividad del sistema, un caso de uso, con el propósito de terminar alguna tarea de negocio que produzca algo con valor apreciable.

Un actor representa un papel desempeñado por un usuario que interactúa con el sistema y no significa que retrate a una persona o un puesto de trabajo.

Existen cuatro tipos de actores:

•Actor primario de negocios: el interesado que se beneficia principalmente de la ejecución de un caso de uso al recibir algo de valor mediable u observable. Puede o no iniciar el evento de negocios.

•Actor primario de sistema: El involucrado que tiene una interfaz directa con el sistema para iniciar el evento de negocio o de sistema. Puede interactuar con los actores primarios de negocio. El actor principal de negocios y el actor principal de sistema pueden ser la misma persona para eventos en los cuales el actor de negocios tiene una interfaz directa con el sistema.

•Actor externo servidor: el involucrado que responde a una solicitud desde el caso de uso (por ejemplo, un buró de crédito que autoriza el pago mediante tarjeta de crédito).

•Actor externo receptor: el involucrado que no es el actor primario pero que recibe algo de valor mediable u observable (salida) proveniente del caso de uso.
Actores Relaciones PASO 1 El proceso de la modelación
de los casos de uso
para los requerimientos Construir el diagrama del modelo de casos de uso Identificar a los actores de negocios Identificarlos casos de uso para los requerimientos de negocios. Narraciones de los casos de uso para los requerimientos de documentos para los negocios. PASO 2 PASO 3 PASO 4 Una vez que esté completo el modelo de caso de uso de los requerimientos de negocios, el administrador de proyectos o el analista de sistemas usa los casos de uso para los
requerimientos de negocios para planear (estimar y programar) los ciclos de construcción del proyecto.
A un ciclo de construcción, que consiste en las actividades del análisis, el diseño y la construcción de sistemas, se le asigna su alcance basándose en la importancia del caso de uso y en el tiempo que toma implantar el caso de uso.
Cuando un caso de uso es demasiado grande o complejo para terminarse el ciclo de construcción, entonces inicialmente se implantara una versión simplificada, seguida por la versión completa en el siguiente ciclo de construcción. El administrador de proyectos o el analista de sistemas terminaran la jerarquización de los casos de uso y la matriz de evaluación y construirá un diagrama de dependencia de casos de uso con entradas de los involucrados y el equipo de desarrollo.

Como jerarquizar y evaluar los caso de uso

Los casos de uso más importantes se desarrollan primero.
El administrador de proyectos usa una herramienta llamada matriz de jerarquía y prioridad de los casos de uso.
Esta matriz se llena con las entradas de los involucrados y del equipo de desarrollo.
Esta matriz, adaptada del trabajo de Craig Larman evalúa los casos de uso en una escala de 1 a 5 con respecto a seis criterios.

1.Impacto significativo sobre el diseño de la arquitectura.
2.Fácil de implantar pero contiene una funcionalidad significativa.
3.Incluye funciones riesgosas, criticas con respecto al tiempo, o que son complejas.
4.Implica mucha investigación o tecnología nueva o de alto riesgo.
5.Incluye funciones primarias de negocios.
6.Aumentará las utilidades o disminuirá los costos. Los casos de uso y la administración de proyectos Como jerarquizar y evaluar los casos de uso Grupos de trabajo 1992 Dr. Jacobson Beneficios Existen 2 elementos primordiales cuando se realiza la modelación de casos de uso. El primero es el diagrama de casos de uso y el segundo elemento es la narración del caso de uso, a continuación explicaremos cada uno de los elementos.

Diagrama de casos de uso:
Ilustración gráfica al sistema como una colección de casos, actores(usuarios) y sus relaciones.

Narración del caso de uso:
Describe los detalles de cada evento de negocios y especifica cómo interactúan los usuarios con el sistema durante ese evento.
Concepto de sistemas en la modelación de casos de uso PLANIFICACIÓN Y MODELADO. GRUPO: 5751
Clemente Catañeda Perla Rocio.
Merino Vega Enrique. Proporciona una herramienta para capturar los requerimientos funcionales.
Ayuda a descomponer el alcance del sistema en piezas manejables.
Proporciona un medio de comunicación con los usuarios y con otros involucrados en relación con la funcionalidad dl sistema. Los casos de uso presentan un lenguaje común que se entiende fácilmente por los diferentes involucrados.
Proporciona una ayuda para estimar el alcance del proyecto, el esfuerzo a realizar y la programación.
Proporciona una línea de bases para pruebas en términos de la definición de los planes y casos de prueba.
Proporciona una línea de base para los sistemas y manuales que ayudan al usuario así como para la documentación de desarrollo del sistema.
Proporciona una herramienta para el seguimiento de requerimientos.
Proporciona un punto inicial para la identificación de los objetos o entidades de datos.
Proporciona un medio parea definir los requisitos de acceso a la base de datos en términos de crear, cambiar, borrar y leer.
Proporciona un marco para impulsar el proyecto de desarrollo de sistemas. ¿Por qué identificar primero a los actores?
Al centrarse en los actores, usted puede centrarse en como se usara el sistema y no en como se construirá.
Los actores también determinan que tan completos están los requerimientos del sistema.
Un beneficio de identificar a los actores primero es que al hacerlo se identifica a los candidatos que podemos
entrevistar y observar posteriormente para terminar el esfuerzo de modelación de los casos de uso.

¿Dónde busca usted a los actores potenciales? las siguientes referencias son fuentes excelentes:

•Un diagrama de contexto que identifique el alcance o las fronteras del sistema.
•La documentación del sistema y los manuales del usuario existentes.
•Minutas de las juntas y los talleres del proyecto.
•Documentos de los requerimientos, carta constitutiva del proyecto, o declaración del trabajo existente.
Al buscar actores haga las siguientes preguntas:
•¿Quien o que proporciona las entradas al sistema?
•¿Quien o que recibe las salidas del sistema?
•¿Se requieren interfaces con otros sistemas?
•¿Existen eventos que son originados automáticamente en un instante predeterminado?
•¿Quien mantendrá la información en el sistema?

Los actores deberán nombrarse con u sustantivo o con una frase sustantiva.
Cuando usted identifique a un actor, cree el texto de una definición de ese actor de acuerdo con la perspectiva
del usuario y usando sus términos. Algunos de los casos de uso pueden depender de otros, con un caso de uso que dejando al sistema en un estado que es una precondición para otro caso de uso. Usamos un diagrama llamado el diagrama de dependencia de caso de uso para modelar estas dependencias. El diagrama de dependencia de caso de uso proporciona los siguientes beneficios:

•La ilustración grafica de los eventos del sistema y de sus estados aumenta la comprensión de la funcionalidad del sistema.
•Ayuda a la identificación de los caso de uso faltantes. Un caso de uso con una precondición que no se satisfaga con la ejecución de cualquier otro caso puede indicar un caso de uso faltante.
•Ayuda a facilitar la administración del proyecto al ilustrar cuales son los casos de uso más críticos (que tienen el mayor número de dependencias) y entonces deben tener una prioridad más alta.
Identificación de las dependencias de los casos de uso Los casos de uso más importantes se desarrollan primero. El administrador de proyectos usa una herramienta llamada matriz de jerarquía y prioridad de los casos de uso. Esta matriz se llena con las entradas de los involucrados y del equipo de desarrollo. Esta matriz, adaptada del trabajo de Craig Larman evalúa los casos de uso en una escala de 1 a 5 con respecto a seis criterios.
1.Impacto significativo sobre el diseño de la arquitectura.
2.Fácil de implantar pero contiene una funcionalidad significativa.3.Incluye funciones riesgosas, criticas con respecto al tiempo, o que son complejas.4.Implica mucha investigación o tecnología nueva o de alto riesgo.5.Incluye funciones primarias de negocios.6.Aumentará las utilidades o disminuirá los costos.
Una vez que cada categoría ha sido calificada se anotan las calificaciones individuales,
lo que conduce a la calificación del caso de uso.

A los casos de uso con las calificaciones más altas se les asigna
la prioridad más alta y deben desarrollarse primero. Cuando usted prepara las narraciones, es prudente documentarlas primero a un alto nivel para obtener rápidamente una comprensión de los eventos y de la magnitud del sistema.
Entonces regrese a cada caso de uso y expándalo a una narración totalmente documentada de requerimientos de negocios. Para cada caso de uso de alto nivel ya identificado, ahora debemos expandirlo para incluir el curso típico de los eventos del caso de uso de los recursos alternos. El curso típico de los eventos del caso de uso es una descripción paso por paso que comienza con el actor que inicia el caso de uso y que continúa hasta el final del evento del negocio. El curso alterno documenta las excepciones o la bifurcación condicional del caso de uso. Documentación del curso de los eventos del caso de uso Una vez que los casos de uso y los actores han sido identificados, puede usarse un diagrama de modelo de caso de uso para ilustrar gráficamente el alcance y las fronteras del sistema. Un sistema de información típico puede constar de docenas de caso de uso. Durante el análisis de requerimientos tratamos de identificar y documentar solamente los más críticos, complejos e importantes, frecuentemente denominados caso de uso esenciales debido a consideraciones de tiempo y costo. Un caso de uso de requerimientos del negocio captura las interacciones con el usuario de manera que este libre de los detalles de la tecnología y de la implantación.
Al buscar los casos de uso haga las siguientes preguntas:

•¿Cuáles con las principales tareas del actor?
•¿Qué información necesita el actor del sistema?
•¿Qué información proporciona el actor del sistema?
•¿Necesita el sistema informar al actor de cambios o eventos que hayan ocurrido?
•¿Necesita informar el actor al sistema de cambios o eventos que hayan ocurrido?

Ejemplo de un glosario de casos de uso que puede usarse para documentarlos:
Existe una relación entre un actor y un caso de uso siempre que el caso describa una interacción entre estos. Una asociación se modela como una línea continua que conecta al actor y al caso de uso. Si un actor se asocia con un caso de uso, decimos que el actor se comunica con el caso. Las asociaciones pueden ser bidireccionales o unidireccionales. Asociaciones Un caso de uso puede contener una funcionalidad compleja que consiste de varios pasos que hacen difícil entender a la lógica del caso. Extiende la funcionalidad del caso de uso original.

La relación entre caso de uso de extensión y el que se esta extendiéndose llama una relación de extensión. Un caso de uso de extensión puede ser invocado solamente por el caso que se esté extendiendo. Generalmente los casos de uso de extensión no se identifican en la fase de requerimientos, sino en la de análisis. Extensión Un caso de uso resumen representa una forma de “reuso” y es una herramienta excelente para reducir la redundancia entre los casos de uso. Esta disponible como referencia (o uso) para cualquier otro caso de uso que requiera su funcionalidad. La relación entre el caso de uso resumen y el caso de uso que lo usa se llama una relación de uso (algunas herramientas de la modelación de caso de uso lo denominan una relación de inclusión). Usos (o inclusión) Dependencia Cuando dos o mas actores comparten un comportamiento común lo mejor es extrapolar este comportamiento común y asignarlo a un nuevo actor resumen con objeto de reducir la comunicación redundante con el sistema. Herencia Marco para metodología de objetos
Sistemas de información orientados a objetos Explica y describe las funciones del sistema desde la perspectiva de los usuarios externos. Como administrador de proyectos o desarrollador líder, es de mucha ayuda saber cuales casos de uso tienen una dependencia sobre otros casos de uso con objeto de determinar la secuencia en que es necesario desarrollar los casos de uso. La relación de dependencia, se ilustra con una línea con cabeza de flecha (ya sea continua o segmentada) que comienza en un caso de uso y que apunta al caso de uso del cual depende.
Full transcript