P. 1
INGENIERIA_REQUERIMIENTOS

INGENIERIA_REQUERIMIENTOS

|Views: 184|Likes:
Publicado porAngie Hdez

More info:

Published by: Angie Hdez on May 30, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPTX, PDF, TXT or read online from Scribd
See more
See less

11/16/2012

pdf

text

original

1.

ELEMENTOS:
2. Indagación Problemas: a) De alcance b) De entendimientos c) De volatilidad 3) Elaboración 4) Negociación 5) Especificación Formato ERS. 3) 7) Administración de los requerimientos (identificar, controlar y dar seguimiento)
Formato ERS IEEE 830 OTRA PROPUESTA ERS Validación (Revisión técnica) ejemplo 1 ejemplo2

1

• IDENTIFICACIÓN DE LOS PARTICIPANTES
• RECONOCER LOS MÚLTIPLES PUNTOS DE VISTA • TRABAJAR HACIA LA COLABORACIÓN ( uso de puntos de prioridad)

2 3

Recabación de los requerimientos en forma colaborativa

Despliegue de la función de calidad

Escenarios de uso

Indagación de los productos de trabajo

Entrevista Cuestionario Muestreo Observación Investigación MÉTODOS INTERACTIVOS MÉTODOS NO INSTRUSIVOS .

Qué precondiciones deben de existir antes de comenzar la historia? 4....Qué tareas o funciones principales son realizadas por el actor? 5.Quién es el actor principal y quién(es) el secuandario? 2..Quiere el actor se informado sobre cambios inesperados? .. produce o cambia el actor? 8..Qué información del sistemas adquiere.Tendrá que informar el actor de cambios al sistema en el ambiente externo? 9.PREGUNTAS QUE DEBE RESPONDER UN CASO DE USO: 1...Qué información desea obtener el actor del sistema? 10...Cuáles variaciones son posibles en la del actor 7.Cuáles son los objetivos de los actores? 3.Qué excepciones deben considerarse al describir la historia? 6.

1) Elementos del modelo de requerimientos • Basados en el escenario • De datos • Orientados a clases • De comportamiento • Orientados al flujo • Modelos de datos • Prototipos y Basados en el diccionario de datos 2) Patrones de Análisis 3) Modelos de para webapps .

a) Identificación de los participantes claves b) Determinación de las condiciones “ganar” de los participantes c) Negociación de las condiciones “ganar-ganar” para todos. .

¿Se ha usado el patrón de requerimientos para simplificar el modelo de éstos? ¿Se han validado todos los patrones de manera apropiada? ¿Son consistentes todos los patrones con los requerimientos del cliente? ..Una vez implementado cada requerimiento...¿Cada requerimiento es asequible en el ambiente técnico que albergará el sistema o producto? 8.Se han especificado todos los requerimientos en el nivel apropiado de abstracción? Es. decir ¿algunos de ellos tienen un nivel de detalle técnico que resulta inapropiado en esta etapa? 3... la función y el comportamiento del sistema que se va a construir? 10.PREGUNTAS DE VALIDACIÓN DEL MODELO: 1.. ¿puede someterse a prueba? 9..¿Se ha “particionado” el modelo de requerimientos en forma que exponga información cada vez más detallada sobre el sistema? 11.¿Tiene atribución cada requerimiento? Es.Cada requerimiento está acotado y no es ambiguo? 5.. ¿refleja de manera apropiada la información. ¿es realmente necesario o representa una característica agregada que tal vez no sea esencial para el objetivo del sistema? 4.¿Hay requerimientos en conflicto con otros? 7.. decir ¿hay una fuente (por lo general una individual y específica) clara para cada requerimiento? 6...Es coherente cada requerimiento con los objetivos generales del sistema o del producto? 2.El requerimiento.El modelo de requerimientos.

II. Análisis de Requerimientos MODELADO DE REQUERIMIENTOS Requerimientos Análisis . MODELADO DE LOS REQUERIMIENTOS 1.

2. Objetivos y Filosofía General A) Describir lo que requiere el cliente. . B) Establecer una base para la creación de un diseño de software. C) Definir un conjunto de requerimientos que puedan validarse una vez construido el software.

Relación entre la descripción y el diseño Descripción del sistema Modelo del análisis El modelo de requerimientos como puente entre la descripción del sistema y el modelo del diseño Modelo del diseño .

de la función y del comportamiento del sistema Retrasar las consideraciones de infraestructura y otros modelos no funcionales Debe minimizarse el acoplamiento a través del sistema Asegurar que el modelo de requerimientos agrega valor a todos los participantes Mantener el modelo tan sencillo como se pueda .2. Reglas prácticas del análisis El nivel de abstracción debe ser relativamente elevado Cada requerimiento debe dar una visión del dominio de la información.

Análisis del dominio Es la identificación .3. [Firesmith 1993] OBJETIVO • Identificar elementos comunes para la solución de problemas. a partir de un dominio de aplicación específica. normalmente para usarlo varias veces en múltiples proyectos dentro del dominio de la aplicación. análisis y especificación de los requerimientos comunes. que sean útiles en todas las aplicaciones de un dominio .

Entradas y salidas para el análisis del dominio Bibliografía técnica Taxonomías de clase Fuentes de conocimi ento del dominio Aplicaciones existentes Encuestas a clientes Consejo de expertos Requerimientos actuales y futuros Análisis del dominio Estándares de reutilización Modelos funcionales Lenguajes del dominio Modelo de análisis del dominio .

4. Enfoques del modelado de requerimientos Análisis orientado a objetos •Modelos basados en el escenario : •Casos de usos •Historias de usuarios •Modelos de clase: •Diagramas de clase •Diagramas de colaboración Análisis orientado a objetos REQUERIMIENTOS DEL SOFTWARE Análisis orientado a objetos •Modelos de comportamiento: •Diagramas de estado •Diagramas de secuencia •Modelos de flujo: •DFD •Modelos de datos Análisis estructurado .

Modelado Orientado al Flujo PUNTO DE VISTA: ENTRADA REPRESENTACIONES: PROCESO SALIDA Entidades Externas (Productores y Consumidores de los datos) Objetos de Datos Transformaciones o Procesos .

para representarse en el siguiente nivel. • Todas las flechas y burbujas deben etiquetarse con nombres significativos • De un nivel a otro debe mantenerse la continuidad del flujo de información • Debe mejorarse una burbuja a la vez . objetos de datos y almacenamiento de éstos.Lineamientos: • El nivel 0 del diagrama debe mostrar el sistema como una sola burbuja • Debe anotarse con cuidado las entradas y salidas principales • La mejora debe comenzar por aislar procesos candidatos.

Alarma . hasta que cada burbuja realice una función simple.DFD en el nivel de contexto (0): • Ejemplo para la función de seguridad de “Casa Segura”: Panel de control Comandos y datos del usuario Información en pantalla Pantalla del panel de control Software de CasaSegura Sensores Estado del sensor Tipo de alarma Alarma Tonos del número telefónico Este diagrama debe expandirse a un siguiente nivel manteniendo la continuidad del flujo de la información.

¿Cómo expandir un DFD? ANÁLISIS GRAMÁTICAL Los sustantivos son: ° Entidades externas (cuadros) Los verbos son los procesos (burbujas) ° Datos u objetos de control (flechas) ° Almacenamiento de datos (líneas dobles) . hasta que cada burbuja tenga “un solo pensamiento” . . . .

Otro modelado para aplicaciones conducidas por “eventos” Un evento o aspecto de control se implementa como un valor booleano una lista discreta de condiciones MODELADO DEL FLUJO DE CONTROL 1) Especificación del control (CSPEC): ° Diagrama de estado (UML) ° Tabla de activación del programa (TAP) 2) Especificación del proceso (PSPEC): ° Texto narrativo ° Diagrama de actividades (UML) .

“ALARMA” TiempoTerminado Entrar/mostrar en la pantalla el mensaje 2. encendido Ocioso Sistema bien Reiniciar Entrar/fijar Estadodel Sistema en “inactivo” Entrar/mostrar en la pantalla el mensaje 1. “Listo” Entrar/mostrar en la pantalla el mensaje 2. “DispararSensor” Entrar/fijar EstadodePantalla en ParpadearRápido Hacer:SonarAlarma SensorDisparo/ ComienzaCronómetro OprimirTecla/ManipularTecla Hacer:NotificaraResponsablesdeAlarma SensorDisparo/ ReiniciarCronómetro . “” Entrar/fijar en la pantalla EstadodePantalla OprimirTecla/ManipularTecla Apagar/Interruptor Apagado Activar FallaDetectada/mostrar en la pantalla el mensaje 2 “contacte al proveedor Desactivar password Desactivar password ActivarAlarma VigilanciadelEstadodelSistema Entrar/fijar Estadodel Sistema en “vigilancia” Entrar/mostrar en la pantalla el mensaje 1. “Iniciando sistema” Entrar/mostrar en la pantalla el mensaje 2. Reiniciar Entrar/fijar Estadodel Sistema en “inactivo” Interruptor de iniciar/detener.Ejemplo: Diagrama de estado para la función de seguridad de CasaSegura. “Por favor espere” Entrar/fijar EstadodePantalla en ParpadearDespacio Hacer: activar diagnóstico Entrar/mostrar en la pantalla el mensaje 1. “Activada” Entrar/mostrar en la pantalla el mensaje 2. “” Entrar/fijar en la pantalla EstadodePantalla Hacer:VigilaryControlarelSistema FalsaAlarma Entrar/fijar Estadodel Sistema en “VigilaryAlarma” Entrar/mostrar en la pantalla el mensaje 1.

eventos de entrada evento del sensor bandera de parpadeo Interruptor de iniciar o detener estado de la acción en pantalla terminado en marcha tiempo terminado salida señal de alarma actividad del proceso vigilar y controlar el sistema activar o desactivar el sistema mostrar mensajes y estado interactuar con el usuario 0 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 1 1 1 1 0 0 0 0 0 1 0 0 0 1 1 1 0 1 0 1 0 1 1 .Ejemplo: Tabla de activación del proceso (TAP) para la función de seguridad de CasaSegura.

Modelo de Comportamiento • Indica la forma en la que responderá el software a eventos o estímulos externos. Pasos: 1) Evaluar todos los casos de uso para entender por completo la secuencia de interacción dentro del sistema 2) Identificar los eventos que conducen la secuencia de interacción dentro del sistema a)Identificar los eventos (siempre que el sistema y un actor intercambian información) b)Identificar un actor por cada evento c)Anotar la información que se intercambia d)Enlistarse cualesquiera restricciones condiciones o e)Asignar los objetos involucrados (son los responsables de la generación de eventos) 3) Crear una secuencia por cada caso de uso 4) Construir un diagrama de estado para el sistema 1)El estado de cada clase cuando el sistema ejecuta su función 2)El estado del sistema según se observa desde el exterior cuando realiza su función 5) Revisar el modelo de comportamiento para verificar la exactitud y consistencia .

El estado de cada clase tiene características: PASIVAS: ACTIVAS: El estado actual del objeto conforme pasa por una transformación o procesamiento continuos Através de ventos externos El estado actual de los atributos de un objeto Através de una función de tiempo Diagramas de estado para clases Diagramas de secuencia .

Diagramas de estado (especificación de control CSPEC) c) Construye una base de datos 6..Diagramas de actividades para administrar y evaluar (especificación de proceso PSPEC) modelos UML ...Diagramas E-R 3.Diagramas UML.Análisis Estructurado vs..Jerarquías de objetos 4..-Diccionario de datos 2.. Análisis generalizado en UML Estructurado 1. que permiten: a) Revisiones sobre los diagramas UML b) Proveen vínculos para producir el diseño y generar código UML 5.Diagramas de flujo de datos 1.

en forma que permita que vuelva a aplicarse cuando se encuentre un problema nuevo Nombre del patrón 2) Se documenta (PAS) Objetivo Motivación Restricciones Patrón de Análisis Semántico Aplicabilidad Estructura (Diagrama de clases) Comportamiento (Diagrama de secuencia) 3) Se guardan en un depósito Participantes Colaboradores Consecuencias .Patrones para el Modelado de Requerimientos 1) Se descubre el patrón 4) Se busca y selecciona para reutilizarse Son un mecanismo para capturar conocimiento del dominio.

Modelado de Requerimientos para WEBAPPS Entradas (Actividad de Comunicación) Participantes Medida de dependencia entre el éxito de la organización y de la webapp Número de participantes Tamaño y complejidad Salidas (Modelos) De contenido (árbol de datos) Categorías de usuario De interacción Contexto del negocio FACTORES Funcional (diagrama de actividades) Metas definidas de información Metas definidas de aplicación Requerimientos generales de webapps Escenarios de uso De navegación Grado en el que ha trabajado junto el equipo Tamaño de equipo De configuración (ambiente y estructura) Descripciones en lenguaje natural .

Árbol de datos • Ejemplo: para CasaSeguraAsegurada.com Descripción de mercadotecnia Número de parte Nombre de la parte Fotografía Descripción técnica Esquema Video Precio al mayoreo Componente Tipo de parte Descripción Precio Precio al menudeo .

ERS MEDIOS PARA LA EVALUACIÓN DE LA CALIDAD DEL SOFTWARE(una vez construido) MODELADO DE LOS REQUERIMIENTOS .Concluimos……….

Estimación de Costos y Tiempos Costos Tiempos Ejemplo .

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->