ingenieria de requisito grupo 2
TRANSCRIPT
CONTENIDO
1 Conceptos Básicos1.1 Ingeniería1.2 Requisito 1.3 Requerimiento
1.4 Interfaz 1.5 Hardware 1.6 Software1.7 Stakeholder
2 Ingeniería de Requisitos Según el Autor:
JONÁS MONTILVA 2.1 Estructura de los Modelos de Procesos
2.2 Requisitos
2.3 Modelo de Productos del Proceso
de Ingeniería de Requisitos
2.4 Subprocesos del Proceso IR
2.5 Descubrimiento de los Requisitos
2.6 Análisis de Requisitos
2.7 Especificación de Requisitos
2.8 Validación de Requisitos
2.9 Gestión de Requisitos
LAURA RODRIGUEZ
CONTENIDO
3 Ingeniería de Requisitos según el Autor Ian Sommerville
3.1 Etapa 1: Estudio de Viabilidad
3.2 Etapa 2: Obtención y Análisis
3.3 Etapa 3: Validación del requerimiento
4 Ingeniería de Requisitos según el Autor JAMES A. SENN
4.1 Etapa 1: Las estrategias para el desarrollo de
sistemas4.2 Etapa 2: Ciclo de vida del desarrollo de sistemas
5 Comparaciones entre las actividades de cada autor
LAURA RODRIGUEZ
INGENIERÍA REQUISITO REQUERIMIENTO
INTERFAZHARDWARE
STAKEHOLDER
SOFTWARE
CONCEPTOS BÁSICOS
LAURA RODRIGUEZ
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
LOS REQUISITOS DEFINEN:
Lo que la aplicación debe hacer La interacción entre los usuarios y la aplicación Las restricciones bajo las cuales la aplicación debe operar Los atributos de calidad que la aplicación debe satisfacer Los requisitos se clasifican en dos tipos: funcionales y no funcionales Las cualidades o atributos que el sistema debe satisfacer Reglas y normas internas o externas al Sistema de Negocios
LAURA RODRIGUEZ
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 v s
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
Subprocesos del Proceso
act Capitulo 3
Ingeniería deRequisitos
Descubrimiento deRequisitos
Análisis deRequisitos
Especificación deRequisitos
Gestión deRequisitos
Validación deRequisitos
AURIMAR REQUENA
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
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
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.
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.
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.
CREAR Y MANTENER UN DOCUMENTO DE REQUERIMIENTO DEL SISTEMA.
Según el autor IAN SOMMERVILLE
LUIS MARTINEZ
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
ETAPA 2
OBTENCIÓN Y ANÁLISIS
El descubrimiento de requerimiento Punto de vista Entrevista
Punto de vista de los interactuadoresPuntos de vistas indirectosPunto de vista del Dominio
LUIS MARTINEZ
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
Según el autor JAMES A. SENN
Cumple un papel primordial en el proceso de producción de software,
MARIANNY UGUETO
ETAPA 1
LAS ESTRATEGIAS PARA EL DESARROLLO DE SISTEMAS
Los sistemas de información basados en computadoras sirven para diversas finalidades que van desde el
procesamiento de transacciones de una empresa, hasta proveer la información necesarias para decidir sobre
asuntos que se presenten con frecuencia
MARIANNY UGUETO
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
Investigación preliminar
Aclaración de la Solicitud
Estudio de Factibilidad
Aprobación de la Solicitud
Factibilidad técnicaFactibilidad económicaFactibilidad operacional
MARIANNY UGUETO
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
Diseño del Sistema
Produce los detalles que establecen la forma en que el sistema cumplirá con los requerimientos
identificados durante la fase de análisis.
MARIANNY UGUETO
Desarrollo del Software
Los encargados de desarrollar software pueden instalar o modificar y después instalar software comprado a terceros o
escribir programas diseñados a la medida del solicitante
MARIANNY UGUETO
Prueba de los sistemas
El sistema se emplea de manera experimental para asegurar que el software no tenga fallas
Trata asegurar, por una parte, que las pruebas sean completas e imparciales y por otra, que el software sea
más confiable.
MARIANNY UGUETO
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 operacional2. Impacto organizacional3. Opinión de los
administradores4. 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:
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
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
Autor: Br. Sarabia D, Karinthia L
• Carácter Proyectivo y nivel comprensivoInvestigació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
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
Autor: Br. Sarabia D, Karinthia L
Planilla VolereIdentificador 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