Resumen: Análisis de requerimientos

Slides:



Advertisements
Presentaciones similares
UML DCU -DS Alvaro Garrido V..
Advertisements

Ingeniería del Software
Requerimientos No Funcionales
DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
Diseño del Software Diseño de datos Diseño arquitectónico
Metodología para el desarrollo de Software educativo POO
Ingeniería de software
Importancia en la efectividad del:
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.
Conceptos Fundamentales
Ingeniería de Requisitos
Unidad 3 MODELO DE ANALISIS.
Fundamentos de Ingeniería de Software
InfoMedia Planificación. Resumen de tareas ● PLANIFICACIÓN: – Definición del formato de los documentos. – Documentación: Asignación de tareas, recursos.
Diseño (Diagrama de Clases) Francisco Valdés Souto 2 al 6 de marzo 2009 © Avantare Consultores S. A. de C. V. – Derechos.
INGENIERÍA DE SOFTWARE RODRÍGUEZ CADENA CYNTHIA VIRIDIANA GRANADOS HERNÁNDEZ ERICK METODOLOGÍA OMT.
Organizaciones involucradas: El centro de cálculo noruego. Crea lenguaje llamado Simula 67, desarrollado por Krinsten Nygaard y Ole-Johan Dahl, en 1967.
BASE DE DATOS EN LA WEB POR- OSIRYS MARCIAGA JESUS NIETO.
Análisis de Proyecto de Software.
Flujo de trabajo: Requisitos Modelado de Casos de Uso
El Lenguaje de Modelación Unificado
METODOLOGÍA DE SISTEMAS
METODOLOGÍA DE SISTEMAS
Ingeniería de requisitos y
Flujo de trabajo: Requerimientos
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Universidad de los Andes
Ingeniería de Software
Evolución de paradigmas y lenguajes de Programación
Metodología Desarrollo de Sistemas de Información.
¿ Que hemos aprendido? Análisis Entendimiento del problema
Programación Avanzada
Técnica de relevamiento de datos
Proyecto de Software. t07
Proyecto de Software. Clase 06
INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS
Diseño Distribuido de una Arquitectura de Software
Especificación de Requisitos
METODOLOGÍA DE SISTEMAS
Ingeniería de Software Somerville
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno. INTRODUCCIÓN A UML  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
Tema 3. Lenguaje unificado de modelado UML
(Unified Modeling Language)
Pregunta del examen 1. Todas las siguientes acciones deben realizarse durante la iniciación del proyecto, EXCEPTO: a. Identificar y documentar las necesidades.
Fundamentos de Ingeniería de Software MODELO DE CASOS DE USO
Ciclo de Vida del Software
SUBSECRETARÍA DE EDUCACIÓN SUPERIOR DIRECCIÓN GENERAL DE EDUCACIÓN SUPERIOR TECNOLÓGICA INSTITUTO TECNOLÓGICO DE SALINA CRUZ.     NOMBRE DEL TEMA: HERRAMIENTAS.
Continuación Unidad 4. Control de flujo
Diagramas del modelo uml
Capitulo 5: modelado de objetos
Especificación de requerimientos por: Sonia Cristina Gamboa Sarmiento
Ingeniería del Software
Análisis. Actividades. Por Miguel y Michael
Danny Frank Otero Arrascue Ingeniería de Requisitos / Requerimientos Advisor: MEJIA CABRERA HEBER IVAN.
Ciclo de vida del Software
ANALISIS DE SISTEMAS ANALISIS ORIENTADO A OBJETOS.
INTRODUCCIÓN A UML Y AL ADOO 1 Diagramas en UML ◦Diagramas de casos de uso ◦Diagramas de clases y objetos ◦Diagramas de secuencia ◦Diagramas de colaboración.
Requisitos Ing. Maribel Valenzuela Beltrán 1.
INGENIERIA DE REQUISITOS
Definición Proceso Unificado Es el flujo de trabajo Realización de casos de uso Roles, actividades, artefactos Es dirigir el desarrollo hacia el sistema.
Casos de Uso Análisis de requisitos con casos de uso.
IEEE-STD PRÁCTICA RECOMENDADA PARA LA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE.
PRESENTACION DE INGENIERIA ORIENTADA A OBJETOS. INTRODUCCION. ¿ Qué es UML ?. UML, por sus siglas en Ingles, Unified Modeling Languaje.(Lenguaje Unificado.
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno. INTRODUCCIÓN A UML  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
INTRODUCCIÓN A UML.  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
PRUEBAS DE CAJA NEGRA. -Internationa Software Testing Qualification Board (ISTQB) Internationa Software Testing Qualification Board (ISTQB) Técnica de.
Estudio de Viabilidad del Sistema (EVS). Estudio de Viabilidad del Sistema Cuestiones ¿Qué es la viabilidad de un sistema? ¿Cuáles son los objetivos del.
Plan de Sistemas de Información (PSI). Plan de Sistemas de Información (PSI) Descripción y Objetivos Tiene como objetivo la obtención de un marco de referencia.
Especificación de Requerimientos
Luis Fernando Muñoz Pantoja Ingeniero de Sistemas Copyright 2019 Luis Fernando Muñoz Pantoja Ingeniero de Sistemas Derechos reservados UML.
Transcripción de la presentación:

Resumen: Análisis de requerimientos 1. ¿Cuáles son las transformaciones? Crear escenarios y diagramas de casos de uso Hable con el cliente, observar, obtener registros históricos, qué experimentos mentales Modelado funcional 2. ¿Cuál es la estructura del sistema? Crea diagramas de clases Identificar los objetos. ¿Cuáles son las relaciones entre ellos? ¿Cuál es su multiplicidad? ¿Cuáles son los atributos de los objetos? ¿Qué operaciones se definen en los objetos? Modelado de objetos 3. ¿Cuál es su comportamiento? Crea diagramas de secuencia Identificar a los remitentes y receptores Mostrar secuencia de eventos intercambiados entre objetos. Identificar las dependencias de eventos y concurrencia evento. Crea diagramas de estado Sólo para los objetos dinámicamente interesantes. Modelado Dinámico Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Vamos a hacer el análisis 1. Analizar el enunciado del problema Identificar los requisitos funcionales Identificar los requisitos no funcionales Identificar las restricciones (requerimientos seudo) 2. Construir el modelo funcional: Desarrollar casos de uso para ilustrar los requisitos de funcionalidad 3. Construir el modelo dinámico: Desarrollar diagramas de secuencia para ilustrar la interacción entre los objetos Desarrollar diagramas de estado para objetos con un comportamiento interesante 4. Construir el modelo de objetos: Desarrollar diagramas de clase que muestra la estructura del sistema Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Cuando es un modelo dominante? Modelo del objeto: El sistema cuenta con objetos con estado no trivial. Modelo dinámico: El modelo tiene diferentes tipos de eventos: entrada, salida, excepciones, errores, etc Modelo funcional: El modelo realiza transformaciones complicadas (por ejemplo, cálculos consistentes en varios pasos). ¿Cuál de estos modelos es dominante en los siguientes tres casos? Compilador Base de datos del sistema Hoja de cálculo del programa Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Dominio de modelos compilador: Sistemas de base de datos: El modelo funcional más importante. (¿Por qué?) El modelo dinámico es trivial ya que sólo hay una entrada de tipo y sólo unas pocas salidas. Sistemas de base de datos: El modelo de objetos más importante. El modelo funcional es trivial, ya que la finalidad de las funciones es generalmente para almacenar, organizar y recuperar datos. Hoja de cálculo del programa: El modelo funcional más importante. El modelo dinámico es interesante si el programa permite cálculos en una célula. El modelo de objeto es trivial, debido a que los valores de hoja de cálculo son triviales y no se puede estructurar aún más. El único objeto interesante es la célula. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Análisis colaborativo Un sistema es un conjunto de subsistemas de prestación de servicios Análisis de los servicios es proporcionada por un conjunto de los equipos que proporcionan los modelos para sus subsistemas Integración de los modelos de subsistemas en el modelo del sistema completo por el equipo de arquitectura Análisis de lista de verificación de integración: ¿Son todas las clases mencionadas en el diccionario de datos? Son los nombres de los métodos que sean compatibles con los nombres de las acciones, actividades, eventos o procesos? Compruebe si las suposiciones hechas por cada uno de los servicios Faltan métodos, clases asociaciones incomparables Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Integración del modelo de objetos en un proyecto grande modulo 1 equipo 1 Equipo de interfaz de usuario Módulo de intefaz Integración Modelo del Sistema Integrado Modelo del sistema revisado Modulo 5 Modulo 4 equipo 5 equipo 4 Modulo 3 equipo 3 Modulo 2 equipo 2 Análisis Revisión análisis Todos los equipos Cambios modelo Equipo de arquitectura Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Plantilla de documento de análisis de requerimientos 1. introducción 2. Sistema actual 3. Sistema propuesto 3.1 Resumen 3.2 Requisitos funcionales 3.3 Los requisitos no funcionales 3.4 Limitaciones (“pseudo Requerimientos") 3.5 Los modelos de sistema 3.5.1 Escenarios 3.5.2 Uso de modelo de casos de 3.5.3 Modelo de objeto 3.5.3.1 Diccionario de datos 3.5.3.2 Los diagramas de clases 3.5.4 Modelos dinámicos 3.5.5 Interfaz de usuario 4. glosario Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Plantilla de documento de análisis de requerimientos 1. introducción 2. Sistema actual 3. Sistema propuesto 3.1 Resumen 3.2 Requisitos funcionales 3.3 Los requisitos no funcionales 3.4 Limitaciones (“pseudo Requerimientos") 3.5 Los modelos de sistema 3.5.1 Escenarios 3.5.2 Uso de modelo de casos de 3.5.3 Modelo de objeto 3.5.3.1 Diccionario de datos 3.5.3.2 Los diagramas de clases 3.5.4 Modelos dinámicos 3.5.5 Interfaz de usuario 4. glosario Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Plantilla de documento de análisis de requerimientos 1. introducción 2. Sistema actual 3. Sistema propuesto 3.1 Resumen 3.2 Requisitos funcionales 3.3 Los requisitos no funcionales 3.4 Limitaciones (“pseudo Requerimientos") 3.5 Los modelos de sistema 3.5.1 Escenarios 3.5.2 Uso de modelo de casos de 3.5.3 Modelo de objeto 3.5.3.1 Diccionario de datos 3.5.3.2 Los diagramas de clases 3.5.4 Modelos dinámicos 3.5.5 Interfaz de usuario 4. glosario Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Plantilla de documento de análisis de requerimientos 1. introducción 2. Sistema actual 3. Sistema propuesto 3.1 Resumen 3.2 Requisitos funcionales 3.3 Los requisitos no funcionales 3.4 Limitaciones (“pseudo Requerimientos") 3.5 Los modelos de sistema 3.5.1 Escenarios 3.5.2 Uso de modelo de casos de 3.5.3 Modelo de objeto 3.5.3.1 Diccionario de datos 3.5.3.2 Los diagramas de clases 3.5.4 Modelos dinámicos 3.5.5 Interfaz de usuario 4. glosario Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Plantilla de documento de análisis de requerimientos 1. introducción 2. Sistema actual 3. Sistema propuesto 3.1 Resumen 3.2 Requisitos funcionales 3.3 Los requisitos no funcionales 3.4 Limitaciones (“pseudo Requerimientos") 3.5 Los modelos de sistema 3.5.1 Escenarios 3.5.2 Uso de modelo de casos de 3.5.3 Modelo de objeto 3.5.3.1 Diccionario de datos 3.5.3.2 Los diagramas de clases 3.5.4 Modelos dinámicos 3.5.5 Interfaz de usuario 4. glosario Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java