Casos de Uso y el Proceso del Requerimiento

Slides:



Advertisements
Presentaciones similares
REQUISITOS GENERALES PARA LA COMPETENCIA DE LOS LABORATORIOS DE ENSAYO Y DE CALIBRACION NTG ISO/IEC 17025:2005 CURSO AUDITORES INTERNOS RELABSA UVG MAYO.
Advertisements

U.M.L A/Gx. Diego Gutiérrez Application Analysis and Design.
Sección 6 Ordenes de Pago
SISTEMAS DE INFORMACIÓN EN LAS ORGANIZACIONES
UML DCU -DS Alvaro Garrido V..
Contenido Sistemas de Información Desarrollo de software
También conocido como Diseño Lógico Rodrigo Salvatierra Alberú.
Evaluaciones de Sistemas de Administración de la Seguridad SMSA
DISEÑO ORIENTADO AL OBJETO
PORTAL WEB Manual de Usuario Perfil Autorizador
Bienvenido a Marangatu'i, Módulo del Contribuyente de la SET!
TEMA 8: DIAGRAMAS EN UML.
GUÍA DEL POSTULANTE Esta Guía le proporcionará ayuda para realizar de manera efectiva, postulaciones a Concursos de Alta Dirección Pública.
Prof. César Luza Montero
Fase Elaboración Conclusiones Grupo 6 – PIS
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno.
DESCRIPCION DEL PROBLEMA
Aspectos Avanzados de la Tecnología de Objetos
Modelo de Requisitos Centro ISYS Escuela de Computación
Desarrollo Orientado a Objetos con UML
Curso Administrativo OTEC Unidad II : Configuración de Cursos Curso creado por : Libro de Clases Electrónico (LCE) ACTUALIZADO
DSOO - María Eugenia Valencia
Determinar a que se le va a hacer Benchmarking
Algunas Herramientas de Apoyo al Diseño de Software Agustín J. González ELO329: Diseño y programación orientados a objetos.
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
Análisis y Diseño de Sistemas
UNIDAD 3: “Desarrollo Orientado a Objetos con UML”
DISEÑO DE SOFTWARE 1ª. Parte
Fundamentos de programación
Fundamentos de Ingeniería de Software Facultad de Ingenieria Universidad Distrital Francisco José de Caldas ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS.
CASOS DE USO Peña Freddy Vargas Gerardolenin.
Análisis y Diseño Orientado a Objetos utilizando UML
ANALISIS Y DISEÑO DE SISTEMA Ing. Sanchez Castillo Eddye Arturo
El lenguaje UML comenzó a gestarse en octubre de1994 (Booch, Rumbaugh y Jacobson), cuando Rumbaugh se unió a la compañía Rational, fundada por Booch (dos.
Gestión de Requerimientos
Requerimientos Funcionales y Casos de uso
INGENIERIA DE SOFTWARE
ANALISIS Y DISEÑO DE SISTEMA Ing. Sanchez Castillo Eddye Arturo
Organización y Estructuración de Datos
CASOS DE USO Ing. Sonia Godoy H..
Sistema de Invitaciones Para Compras Directas
Sistema de Invitaciones Para Compras Directas MANUAL DE PROVEEDORES
Ingeniería de software
Formación titulada a la medida
Algunas Herramientas de Apoyo al Diseño de Software Agustín J. González ELO329: Diseño y programación orientados a objetos.
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
Ing. Noretsys Rodríguez. Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de.
Christian Monrreal Gonzalez Daryl Silverman Aguilar Gone
Ingeniería de Software Laboratorio V
Como crear un contacto en outlook. 1.En Contactos, en la ficha Inicio, en el grupo Nuevo, haga clic en Nuevo contacto. Comando Nuevo contacto en la cinta.
MODELAMIENTO VISUAL Y UML
Ingeniería de Software Escuela de Sistemas Universidad Nacional de Colombia – Sede Medellín.
IMPLEMENTACIÓN DE ITIL EN 10 PASOS
Departamento de Informática Universidad de Rancagua Prof:Paula Quitral Introducción a UML Caso de uso Departamento de Informática Universidad de Aconcagua.
Introducción al proceso de verificación y validación.
Actividad 3 Diagrama de Actividades Dra. Anaisa Hernández González
Fundamentos del Análisis Orientado a Objetos
Microsoft Office Project INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS Microsoft Office Project 2010.
EduCat Prototipos. Introducción En las próximas páginas se muestra un bosquejo de lo que será la interfaz gráfica de nuestro programa, EduCat, para los.
Proceso de Diseño de Interfaces
UML DIAGRAMA DE CASOS DE USO
Casos de Uso - Programación II Analista Programador
Colegio de Bachilleres Plantel 13 Xochimilco - Tepepan
Programa de Administración de Desempeño (PATH) Etapa de inicio 2015 Laureate Centroamérica 2015 Honduras.
UML – Lenguaje de Modelado Unificado
SISTEMA DE GESTIÓN DE LA CALIDAD ISO 9001: AUDITORÍA INTERNA
Procesos de Planeación
Modelado UML Diagramas de Casos de Uso
DLM Transact SQL Sesión I Introducción al SQL Server Uso de las herramientas de consultas del Transact SQL.
Entregables del Proyecto
Transcripción de la presentación:

Casos de Uso y el Proceso del Requerimiento

Proceso de Requerimientos “Nuestra Clase” Declaración de Trabajo Listado de Casos de Uso Fachada Terminados Prototipos Actores Completos Enfocados Priorizar Especific. De Req.

Proceso de Requerimientos ¿Qué es lo primero? ¡¡ Saber que es lo que tenemos que hacer !! Lograr definiciones con los interesados.

Declaración de Trabajo Es una definición clara del proyecto que se va a realizar. Permite especificar los acuerdos iniciales establecidos con los interesados en el producto de software. (StakeHolders) Se realiza en las primeras reuniones con los intersados (gerentes o quienes toman las decisiones).

Declaración de Trabajo El objeto de la declaración de trabajo es establecer el alcance del proyecto. Uno de los principales problemas es que al comienzo de los proyectos no es claro el alcance, ni la composición del producto de software a desarrollar. No se puede comenzar hasta tener definiciones en torno a esto.

Declaración de Trabajo Título Alcance Objetivos Descripción del Software Demografía de Usuarios Restricciones Presunciones Grupo de Desarrollo Cronograma y Presupuesto.

Declaración de Trabajo Título: Nombre del Proyecto de Software. Ejemplo: Acadata. Sistema de Administración Académico para Universidades.

Declaración de Trabajo Alcance: Procesos y Actividades del negocio que serán soportadas por el producto de software. Ejemplo: Soportará las actividades relacionadas con la matrícula académica de los estudiantes, el registro de sus notas y la generación de reportes y certificados. No incluirá los procesos de auxilios financieros, préstamos, manejo de becas, procesos de entrevistas y admisiones, ni evaluación de profesores.

Declaración de Trabajo Objetivos: Metas que se esperan lograr con la implementación del software. Razones por las cuales el producto de software va a ser desarrollado. Ejemplo: El sistema permitirá reemplazar el sistema actual. El sistema posibilitará reducir el tiempo de generación de listados de notas de una semana a tres días hábiles. El sistema permitirá la generación de certificados académicos en múltiples idiomas, en un tiempo inferior a dos días hábiles.

Declaración de Trabajo Descripción del Software: Conjunto de Funcionalidades que se esperan del software. (Requerimientos Funcionales). Ejemplo: El Software permitirá el ingreso de diferentes tipos de notas por cada uno de los profesores en sus materias. Un tipo de nota, por ejemplo, puede ser “Examen Final”, “Trabajo Final”, etc.

Declaración de Trabajo Demografía de Usuarios: Tipos de Usuarios que emplearán el software. Ejemplo: Profesores: Personal adscrito a la Universidad, encargado de dictar las clases y quienes ingresarían información sobre el desempeño académico de cada estudiante. En muchos casos no tienen conocimientos de computadores.

Declaración de Trabajo Restricciones: Condiciones que debe satisfacer el software. (Requerimientos no funcionales) Ejemplo: El sistema deberá funcionar en los equipos que actualmente utiliza la compañía. En estos momentos la compañía cuenta con computadores Pentium a 233Mhz, con Windows 98.

Declaración de Trabajo Presunciones: Elementos y condiciones que deben ser cumplidas por el propietario del software para que este funcione. Ejemplo: La empresa deberá tener una red interna de alta velocidad en todos los puntos en donde los usuarios trabajen. El Software funcionará a través de una conexión permanente con el servidor central.

Declaración de Trabajo Otros Items: Grupo de Trabajo Cronograma y Presupuesto

Declaración de Trabajo Revisión Los documentos de declaración de trabajo deben elaborarse y validarse con los StakeHolder. La idea no es hacer un documento extensamente detallado. La idea es establecer un marco general del producto.

Declaración de Trabajo ¿Que sigue? Un Listado de Actores Un Listado de Casos de Uso

Declaración de Trabajo Listado de Casos De Uso Declaración de Trabajo Descripción Listado de Actores Usuarios

Listado de Actores Listado de Actores del Sistema Listado de Usuarios que interactúan con el Software. Listado de otros Sistemas/Software con los cuales interactúa el Software.

Listado de Actores Revisión Un Actor no debe ser una persona particular Jaime Un Actor no debe ser un cargo en partícular Director de Ventas del SurOccidente Una persona concreta puede hacer el papel de varios actores. Un actor es un rol dentro del sistema/Software. Profesor Coordinador Académico Estudiante

Listado de Casos de Uso Un Caso de Uso es una situación en la cual es software es utilizado. Un Caso de Uso representa una acción que puede ser desarrollada empleando el Software.

Listado de Casos de Uso ¿Cuáles son los casos de uso de un celular? ¿Para que lo utilizan? ¿Cuáles son los casos de uso de una videograbadora? ¿Para que la utilizan?

Listado de Casos de Uso Casos de Uso de un Celular Hacer una llamada Recibir una llamada Guardar los datos de un contacto Mirar la Hora Jugar “Culebrita”

Listado de Casos de Uso ¿Para que se va a utilizar el Software? ¿En que casos se va a usar el software?

Listado de Casos de Uso Revisión Un caso de uso no es una funcionalidad general (demasiado amplia y ambigüa). Manejo de Usuarios Un caso de uso no puede ser un paso elemental dentro del Software Ingresar código de estudiante No debe ser ambigüo. Generar estadísticas

Listado de Casos de Uso Revisión Un caso de uso debe representar una acción. Debe contener un verbo Documento Un caso de uso debe representar una acción concreta que se puede desarrollar con el software. Análizar el estado financiero del Cliente.

Listado de Casos de Uso Revisión El primer listado de casos de uso no pretende ser un listado exhaustivo. El primer listado es el punto de partida de nuestro trabajo. A medida que se empiecen a entrevistas usuarios y expertos de dominio (no solo al StakeHolder), los casos de uso pueden ampliarse en número.

Listado de Casos de Uso Revisión Nombres “sospechosos” Administrar Manejar Controlar Imprimir Soportar Suministrar Ingresar

Listado de Casos de Uso Ejemplo Matricular Estudiante por primera vez. Matricular Estudiante antigüo. Matricular Estudiante en Curso. Cancelar matrícula de estudiante en Curso. Listar cursos matriculados por un Estudiante. Listar estudiantes matriculados en un Curso

Listado de Casos de Uso ¿Qué sigue? Detallar cada uno de los requerimientos. Especificar cada uno de los casos de uso

Listado de Casos de Uso ¿Qué sigue? Listado de Casos De Uso Casos De Fachada Listado de Actores

Casos de Uso de Fachada Los Casos de Uso deben especificarse. A pesar de que idealmente los nombres de los casos de uso son bastante representativos y no ambigüos, el comportamiento del software en cada caso de uso puede ser interpretado de diversas formas. Es necesario establecer el comportamiento del software.

Casos de Uso de Fachada ¿Cómo se hace una llamada en el Celular? Es posible determinar un conjunto de pasos de forma independiente del aparato celular. ¿Cómo se ve una película en una videocasetera? Es posible determinar un conjunto de pasos de forma independiente del aparato partícular.

Casos de Uso de Fachada El primer paso consiste en establecer un guión inicial, una secuencia de pasos que serán ejecutados por el actor y por el software.

Casos de Uso de Fachada El primero paso consiste en establecer el tipo de interacción que se tendrá entre el actor y el software El guión permite llegar a un primer tipo de acuerdo con los usuarios sobre lo que debe hacer el software

Casos de Uso de Fachada La interacción se defina a través de un “guión”. Una serie de pasos que deben ser realizados por el usuario y por el sistema de software. También se conoce como “Secuencia de Eventos” o “Flujo Normal”.

Casos de Uso de Fachada Actor Sistema 1. Ingresa el login. 2. Verifica que exista un usuario con el login especificado. 3. Ingresa el password. 4. Verifica que el password coincida con el definido para ese usuario

Casos de Uso de Fachada La interacción no debe incluir “presunciones de diseño” o “detalles de implementación”. No debe incluirse: Hace clic en el botón X. Muestra una forma con los campos X, Y, Z. Arrastra el icono hasta la carpeta. Debe ser un guión lo más “general” posible, ojalá aplicable a una gran variedad de implementaciones.

Especificación de Casos de Uso de Fachada Número Nombre Descripción Fase (Fachada) Actores Guión

Especificación de Casos de Uso de Fachada Número: Identificador de cada caso de uso Nombre: Nombre del caso de uso Ejemplo: 01. Registrar datos de nuevo cliente 02. Registrar datos de producto. 03. Registrar pedido de cliente.

Especificación de Casos de Uso de Fachada Descripción: Descripción del caso de uso, la situación en la cual se utiliza y un resumen del comportamiento del software. Ejemplo: Cuando el vendedor ha iniciado el contacto con un nuevo cliente, incluso antes de vender el primer producto, puede registrar los datos del mismo en el sistema.

Especificación de Casos de Uso de Fachada Actores: Actores (Roles o Tipos de Usuarios que utilizan ese caso de uso) Principales: Aquellos actores que interactúan directamente con el software (quienes usan el teclado). Secundarios: Aquellos actores que proveen o reciben información para la ejecución del caso de uso, pero que no interactúan directamente con él.

Especificación de Casos de Uso de Fachada Actores Ejemplo: Para la compra de productos en un almacen de cadena. Principal: Cajero Secundario: Cliente, Jefe de Cajeros.

Especificación de Casos de Uso de Fachada No. 01 Nombre. Registrar Cliente Descripción Cuando un vendedor inicia los contactos con un nuevo cliente, aún cuando no realice una venta, debe ingresar los datos básicos del cliente. Fase Fachada Actores Principal: Vendedor Guión Actor Sistema 1. Ingresa su login 2. Verifica que exista un usuario con ese login

Casos de Uso de Fachada Revisión Todas las especificaciones deben incluir el guión. Los Actores deben ser usuarios que realmente interactúan con el software. El Guión debe verificarse con los usuarios. No deben existir presunciones de diseño y/o detalles de implementación.

Casos de Uso de Fachada ¿Qué sigue? Listado de Casos De Uso Casos Completos Listado de Actores

Casos de Uso Completos Lo primero... Ahora.. Establecer un primer guión para el caso de uso. Negociar que cosas va a hacer el usuario y que cosas va a hacer el software. Ahora.. Establecer los casos excepcionales. Determinar que debe hacer el software en cada una de las situaciones especiales.

Casos de Uso Completos Excepciones Ejemplo: Sitación/Caso en el que el software no desarrolla el guión normal. Secuencias de pasos que se deben ejecutar en una situación particular. Ejemplo: Cuando un estudiante hace su matricula por fuera del plazo estipulado, el software debe comportarse diferente a cuando se hace dentro del plazo estipulado.

Casos de Uso Completos El guión típico deberá contener validaciones y verificaciones que permitan conocer si una excepción ocurre o no. Cada una de las excepciones debe documentarse con un guión particular.

Casos de Usos Completos Guión Caso típico. Pasos a desarrollar en un caso típico. Excepciones Casos no típicos. Casos excepcionales en donde se desarrollan pasos diferentes.

Casos de Uso Completos Guión Excepciones El Usuario ingresa el código del contrato. El Sistema verifica que exista un contrato con ese código. El Sistema visualiza el nombre de la persona responsable del contrato, la fecha del contrato y el valor del mismo. El Usuario confirma que desea eliminar el contrato. El SIstema elimina el contrato. Excepciones Contrato no existe 2. 6. El Sistema visualiza un mensaje indicando que el contrato no existe 7. Termina Usuario no confirma que desea eliminar el contrato 4. 8. Termina

Casos de Uso Completos Revisión Cada uno de los pasos debe ser lo más detallado y específico posible Ingresa los datos.. ¿Cuáles datos? Verifica los datos... ¿Cómo se hace la verificación? Calcula el dato... ¿Cómo se hace el cálculo? Deben especificarse todas las excepciones. El guión debe incluir un paso que permita establecer si la excepción ocurre, para todos los tipos de excepción del caso de uso.

Casos de Uso Completos ¿Qué sigue? Casos de Uso Enfocados Casos de Uso De Fachada Casos de Uso Completos

Casos de Uso Enfocados Hasta ahora... Ahora... Tenemos unos casos de uso detallados con indicaciones de las diferentes excepciones que le ocurren. Ahora... Abordaremos con más detalle algunos pasos específicos. Buscaremos relaciones entre los diferentes casos de uso.

Casos de Uso Enfocados Diagrama Registrar cliente Vendedor Registrar venta

Casos de Usos Enfocados Un caso de uso “usa” a otro caso de uso, cuando el segundo representa uno o varios de los pasos que se realizan en el primero. La relación “de uso” entre los casos de uso se basa en los pasos de los guiones y excepciones de los casos de uso.

Casos de Usos Enfocados Ejemplo... Varios de los casos de uso de un software en particular tienen pasos en común. Validación del login y password de un usuario Validación del estado de cuenta de un cliente. Cálculo de una serie de valores y/o estadísticas.

Casos de Usos Enfocados Ejemplo. En varios casos de uso... 1. El usuario ingresa el login 2. El sistema verifica que exista un usuario con ese login. 3. El usuario ingresa el password. 4. El Sistema verifica que el password corresponda al cliente específicado

Casos de Uso Enfocados Diagrama Registrar cliente Iniciar Sesión <<usa>> Registrar cliente <<usa>> Iniciar Sesión Vendedor Registrar venta

Casos de Usos Enfocados Un diagrama de casos de uso NO es un flujograma. Es un diagrama que muestra relaciones entre los casos de uso.

Casos de Uso Enfocados Diagrama Registrar cliente Iniciar Sesión <<usa>> Registrar cliente <<usa>> Iniciar Sesión Vendedor Se puede establecer más detalle para este caso de uso Registrar venta Los pasos son “quitados” de aquí

Casos de Uso Enfocados Ejemplo... Luego de colocar los pasos comunes en otro caso de uso, el guión debe retirar esos pasos de donde originalmente estaban 1. Inicia sesión (ver caso de uso #20) 2. ...

Casos de Uso Enfocados Un caso de uso “extiende” a otro caso de uso, cuando el primer caso de uso se enfoca en un caso particular del segundo. Cuando el caso de uso “extendido” realiza básicamente lo mismo que el caso de uso inicial, pero tiene diferencias en los pasos que realiza.

Casos de Uso Enfocados Si una de las excepciones de un caso de uso resulta ser muy compleja (un guión muy extenso), puede ser “sacado” en un nuevo caso de uso para revisarlo con mayor detalle.

Casos de Uso Enfocados Diagrama Cuando se presta el libro a un estudiante se desarrollan pasos muy diferentes a cuando se presta un libro a un profesor Prestar Libro Vendedor

Casos de Uso Enfocados Diagrama Prestar Libro Vendedor Prestar Libro <<extiende>> Vendedor Prestar Libro a profesor

Casos de Usos Enfocados El formato debe incluir información de los casos de uso relacionados Nombre Mostrar datos de Proveedor Casos de uso relacionados Usa iniciar sesión (caso de uso #20) Es usado al mostrar informe de usuario (caso de uso #21) Extiende Mostrar datos de Usuario (caso de uso #12). Es extendido al Mostrar datos de un proveedor principal (caso de uso #14)

Casos de Usos Enfocados Revisión Los casos de uso relacionados deben estar incluídos en los diferentes formatos. El guión de un caso de uso que “use a otro”, no debe incluir los pasos del caso de uso que esta usando. El guión de un caso de uso que “extiende a otro”, debe estar completo y no debe omitir pasos debido a que esta en el otro caso de uso.

Casos de Uso Enfocados ¿Qué sigue? Casos de Uso De Fachada Casos Completos Casos de Uso Enfocados Casos de Uso Terminados

Casos de Uso Terminados Hasta ahora... Casos de uso completos, con información detallada de algunos pasos. Ahora... Definir un protitipo de la aplicación. Colocar información necesaria para realizar el análisis y el diseño del producto.

Casos de Usos Terminados Otros Requerimientos Precondiciones Postcondiciones Prototipo

Casos de Usos Terminados El prototipo consiste (de por sí) una presunción de diseño. El guión y las excepciones son la base para crear el prototipo. El guión y las excepciones no deben modificarse para “ser fiel” al prototipo. El prototipo debe ser un mecanismo para verificar el guión.

Casos de Usos Terminados Cada caso de uso representa “un diálogo” Puede tener múltiples pantallas y/o ventanas Una misma pantalla y/o ventana puede hacer parte del diálogo de varios casos de uso.