Your SlideShare is downloading. ×
  • Like
Ingenieria de requisito grupo 2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Ingenieria de requisito grupo 2

  • 2,405 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,405
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
50
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. LAURA RODRIGUEZ
  • 2. LAURA RODRIGUEZ
  • 3. INGENIERÍA REQUISITO REQUERIMIENTO INTERFAZ HARDWARE STAKEHOLDER SOFTWARE LAURA RODRIGUEZ
  • 4. Fuente: Montilva, J. (2008). LAURA RODRIGUEZ
  • 5. Permite descubrir, analizar, especificar y validar el conjunto de requisitos funcionales y no-funcionales que la aplicación empresarial debe satisfacer Según el autor JONÁS MONTILVA LAURA RODRIGUEZ
  • 6. LOS REQUISITOS DEFINEN: LAURA RODRIGUEZ
  • 7. act Otras figuras1 «Documento» Requisitos de la Aplicación «Documento» Documento Definición de Requisitos «Documento» Lista de Requisitos de la Aplicación «Documento» Matriz resuisitos vs requisitos «Documento» Requisitos clasificados «Documento» Plan de gestión de Requisitos «Documento» Matriz de rastreo de requisitos «Documento» Documento de Especificación de Requisitos de la Aplicación «modelo» Modelo de Casos de Uso «modelo» Modelo preliminar de clases «Documento» Casos de Prueba de Aceptación «producto técnico» Prototipo de la Aplicación «Documento» Descripciones textuales «diagrama UML» Diagramas de casos de uso «diagrama UML» Diagramas preliminares de clases de objetos Modelo de Productos del Proceso de Ingeniería de Requisitos
  • 8. Subprocesos del Proceso act Capitulo 3 Ingeniería de Requisitos Descubrimiento de Requisitos Análisis de Requisitos Especificación de Requisitos Gestión de Requisitos Validación de Requisitos AURIMAR REQUENA
  • 9. Actividad Tareas Producto Determinar Objetivos de la Aplicación. 1. Identificar objetivos de la aplicación. 2. Definir alcance de la aplicación. 3. Determinar el problema a resolver. 4. Establecer restricciones. 1. Objetivos y Alcance de la aplicación claramente definidos. Establecer dominio a partir del Modelo del Negocio. 1. Analizar el modelo de negocios y determinar el dominio de la aplicación. 2. Revisar documentación relacionada con aplicaciones dentro del dominio identificado - reuso de requisitos. 3. Estudiar documentación sobre aplicaciones en dominio. 4. Identificar los actores o interesados de la aplicación y que participarán directamente en la definición de requisitos. 1. Lista de actores clasificados. Recolectar requisitos de la Aplicación. 1. Contactar interesados o actores miembros del sistema de negocios. 2. Recabar los requisitos (funcionales, no funcionales y de interfaz) de la aplicación desde el punto de vista de cada actor o interesado. 3. Definir requisitos (funcionales, no funcionales y de interfaz) a partir del modelo de negocios. 4. Definir requisitos (funcionales, no funcionales y de interfaz) a partir de aplicaciones del dominio. 5. Definir requisitos de interacción de la aplicación con otros sistemas dentro o fuera del mismo sistema de negocios. 1. Planillas (Volère) de recolección de requisitos. 2. Modelos de casos de uso con sus respectivos escenarios Consolidación de Requisitos. 1. Verificar consistencia entre los requisitos recolectados. 2. Unificar requisitos recolectados. 1. Lista de requisitos de la aplicación Descubrimiento de Requisitos
  • 10. Análisis de Requisitos Actividad Proceso Producto Clasificar Requisitos Recolectados. 1. Revisar los requisitos recolectados. 2. Determinar criterios de agrupamiento, generalmente va asociado al tipo de requisitos: funcionales y no-funcionales. 3. Agrupar requisitos en las categorías establecidas. 1. Requisitos clasificados. Definir interacciones entre requisitos. Establecer contradicciones entre requisitos. Determinar grado de completitud de requisitos. Determinar solapamientos y dependencia entre requisitos. Elaborar matriz de requisitos .vs. requisitos. 1. Matriz de requisitos .vs. Requisitos. Depurar lista de Requisitos. 1. Eliminar incompatibilidades y contradicciones entre requisitos. 2. Redefinir requisitos. 3. Determinar viabilidad de los requisitos. 4. Establecer prioridades de los requisitos junto con el usuario. 1. Lista de requisitos factibles con prioridades acordadas con usuario o interesado. Refinar Requisitos Clasificados. 1. Describir en mayor nivel de detalle los requisitos recolectados: a) Elaborar diagramas de caso de uso para explorar funcionalidad. b) Definir escenarios de utilización y describiros textualmente. c) Elaborar diagramas de clases de objetos para representar objetos persistentes y requeridos para la funcionalidad. d) Describir atributos y restricciones de la aplicación. 1. Diagramas de casos de uso. a) Descripciones textuales. 2. Diagramas preliminar de clases. 3. Diagramas de estados. Validar Requisitos. 1. Revisar requisitos con los actores o interesados. 2. Ajustar y corregir los diagramas de casos de uso, clases y la definición de restricciones y atributos. 1. Documento de definición de requisitos
  • 11. Especificación de Requisitos Actividad Tareas Productos Definición del documento de especificación. 1. Establecer la estructura y contenido de la especificación de requisitos. a) Especificar requisitos desde el punto de vista del actor o interesado: funcionales y no funcionales. b) Especificar requisitos desde el punto de vista del desarrollador: Modelos del sistema funcional, estático o estructural y dinámico. 1. Estructura y contenido de documento. Especificar requisitos desde el punto de vista del interesado (stakeholder) 1. Documentar técnicamente los requisitos de la aplicación (punto de vista del grupo de desarrollo): a) Refinar los diagramas y modelos preliminares de casos de uso, clases de objetos, estados y transiciones, objetos y secuencia. 2. Documentar atributos, restricciones y otras especificaciones según la estructura y contenido definidos para el documento. 1. Documento de especificación de requisitos de la aplicación.
  • 12. Validación de Requisitos Actividad Tareas Producto Revisar documento de especificación de requisitos. 1. Validar la estructura y el contenido del documento. 2. Validar especificación técnica de los requisitos. 1. Documento validado. Construir un prototipo para validar los requisitos. 1. Desarrollar un prototipo que emule la funcionalidad (según los casos de uso) y la interfaz que tendría la aplicación. 2. Validar funcionalidad e interfaz de la aplicación. 1. Prototipo de la aplicación. Ajustar los modelos y descripciones de la especificación de requisitos. 1. Modificar los modelos y descripciones de especificación técnica atendiendo a los resultados de validación del prototipo. 2. Verificar consistencia e integridad de la especificación técnica. 1. Modelos actualizados y validados. Definir pruebas y parámetros de aceptación de la aplicación. 1. Determinar parámetros de aceptación de la aplicación. 2. Definir casos de prueba de aceptación. 3. Verificar, con los interesados, los parámetros de aceptación y los casos de prueba de aceptación de la aplicación. 1. Conjunto de casos de prueba de aceptación de la aplicación.
  • 13. Gestión de Requisitos Actividad Tareas Productos Planificar el proceso de gestión de modificaciones en los requisitos. 1. Definición de los medios y modos de almacenamiento de los requisitos de la aplicación – Base de Datos de apoyo a la gestión. 2. Establecer procedimientos y mecanismos de actualización, mantenimiento y control de requisitos. 1. Plan de gestión de Requisitos. Realizar cambios en los requisitos. 1. Seguir los procedimientos y mecanismos establecidos para la gestión de cambios en los requisitos. 2. Realizar los cambios en los requisitos. 3. Modificar documento de especificación de requisitos. 4. Asegurar consistencia e integridad de la base de datos una vez realizados los cambios 1. Documento de especificación actualizado. 2. Base de datos de Requisitos actualizada. Rastreo de cambios en los requisitos. 1. Definir ámbito de influencia del cambio sobre los requisitos de la aplicación. 2. Elaborar matriz de rastreo de requisitos. 3. Asegurar actualización de documentos y modelos de la aplicación. 1. Matriz de rastreo de requisitos.
  • 14. CREAR Y MANTENER UN DOCUMENTO DE REQUERIMIENTO DEL SISTEMA. Según el autor IAN SOMMERVILLE LUIS MARTINEZ
  • 15. ETAPA 1 ESTUDIO DE VIABILIDAD Una descripción resumida del sistema Informe que recomiende si merece o no seguir con la ingeniería de requerimientos y procesos del desarrollo del sistema LUIS MARTINEZ
  • 16. ETAPA 2 OBTENCIÓN Y ANÁLISIS El descubrimiento de requerimiento Punto de vista Entrevista Punto de vista de los interactuadores Puntos de vistas indirectos Punto de vista del Dominio LUIS MARTINEZ
  • 17. VALIDACIÓN DEL REQUERIMIENTO Trata de mostrar que esto realmente define el sistema que el cliente desea 1 • Verificaciones de valides 2 • Verificación de consistencia 3 • Verificación de completitud 4 • Verificación de realismo 5 • Verificabilidad ETAPA 3 LUIS MARTINEZ
  • 18. Según el autor JAMES A. SENN Cumple un papel primordial en el proceso de producción de software, MARIANNY UGUETO
  • 19. ETAPA 1 LAS ESTRATEGIAS PARA EL DESARROLLO DE SISTEMAS MARIANNY UGUETO
  • 20. ETAPA 2 Investigación preliminar Determinación de los requerimientos de los sistemas Diseño del sistema Desarrollo de software Prueba de los sistemas Implantación y evaluación. CICLO DE VIDA DEL DESARROLLO DE SISTEMAS MARIANNY UGUETO
  • 21. Investigación preliminar Aclaración de la Solicitud Estudio de Factibilidad Aprobación de la Solicitud Factibilidad técnica Factibilidad económica Factibilidad operacional MARIANNY UGUETO
  • 22. Determinación de los requerimientos de los sistemas ¿qué es lo que se hace? ¿cómo se hacen? ¿con que frecuencia se presentan? ¿qué tan grande es el volumen de transacciones o de decisiones? ¿cuál es el grado de eficiencia con el que se efectúa las tareas? ¿existe algún problema? si existe un problema ¿Qué tan serio es? si existe un problema ¿cuál es la causa que lo origina? MARIANNY UGUETO
  • 23. Diseño del Sistema MARIANNY UGUETO
  • 24. Desarrollo del Software MARIANNY UGUETO
  • 25. Prueba de los sistemas MARIANNY UGUETO
  • 26. Implantación y Evaluación MARIANNY UGUETO Verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todo los archivos de datos necesarios para utilizarla. 1. Evaluación operacional 2. Impacto organizacional 3. Opinión de los administradores 4. Desempeño del desarrollo La evaluación se lleva a cabo para identificar puntos débiles y fuertes , y ocurre a lo larga de cualquiera de las siguientes dimensiones:
  • 27. IAN SOMMERVILLE JAMES. A SENN JONAS MONTILVA Proceso de crear y mantener un documento de requerimiento del sistema. Herramienta que cumple un papel Primordial en el proceso de producción de software. Una estrategia para permitir descubrir, analizar, especificar y validar el conjunto de requisitos funcionales y no funcionales que la aplicación empresarial debe conocer. Estudio de viabilidad, obtención y análisis, especificación y validación. Estrategias para el desarrollo de sistemas y ciclo de vida del desarrollo de sistemas. Descubrimiento, análisis, especificación, validación y gestión de requisitos. No plantea ningún tipo de requisitos o preguntas. En la etapa 2, plantea ocho preguntas para la determinación de los requerimientos del sistema. En la etapa 1, emplea ocho requisitos que complementan las 5 etapas. CARLOS LOPEZ
  • 28. Caso practico INGENIERÍA DE REQUISITOS PARA PROCESOS DE EJECUCIÓN DE ESTRATEGIAS DE MERCADEO (IMPULSOS Y FACHADAS), COORDINACIÓN DE DESARROLLO EN EL PUNTO DE VENTA CERVECERÍA POLAR C.A TERRITORIO COMERCIAL ORIENTE SUR Autor: Br. Sarabia D, Karinthia L Desarrollar la ingeniería de requisitos de aplicación empresarial para la gestión, control y seguimiento de los procesos de ejecución de estrategias de mercadeo (Impulsos y Fachadas). CARLOS LOPEZ
  • 29. Autor: Br. Sarabia D, Karinthia L • Carácter Proyectivo y nivel comprensivo Investigación • Observación directa • Revisión documental • Entrevistas no estructuradas • Cuestionario Técnicas de recolección de datos • Gray watch • Lenguaje unificado de modelado (UML)Metodología • Solución para diseñar y construir una aplicación empresarial que atienda las necesidades planteadas en la coordinación con la finalidad de automatizar los procesos Impulsos y Fachadas Propuesta CARLOS LOPEZ
  • 30. Solicitud de Impulsos Rol Usuario y SuperUsuario. Autor: Br. Sarabia D, Karinthia L Se plantea un sistema desarrollado bajo ambiente web que permita mejorar el procesamiento de manera eficaz de las estrategias requeridas. CARLOS LOPEZ
  • 31. Autor: Br. Sarabia D, Karinthia L Planilla Volere Identificador del requisito: RF-01 Tipo de requisito: Funcional Caso de uso/Evento: Descripción: El sistema debe validar el acceso de todos los usuarios del sistema. Justificación del requisito: es necesario para restringir el acceso al sistema sólo a personas autorizadas y a su vez muestra opciones del sistema de acuerdo al rol del usuario. Fuente: Jaime Albornett Unidad en la que se origina: Departamento de Sistemas Criterios de validación: El sistema implementado se estará revisando periódicamente para evaluar si la aplicación permite el acceso a la misma a personas que no se encuentren registradas o autorizadas. Grado de satisfacción del interesado: 5 Grado de insatisfacción del interesado: 1 Dependencias: 2, 5, 6, 7, 32, 34, 35, 36, 38, 40 Conflictos: No presenta Documentos de soporte: No definido Histórico de cambios:06/09/2010 Proyecto: Sistema para la gestión y control de las estrategias de mercadeo Analista: Karinthia Sarabia Primer Requisito Funcional CARLOS LOPEZ