ingeniería de requisitos
TRANSCRIPT
Ingeniería de
requisitos
Ayuda a comprender mejor el
problema, mediante la elaboración de
tareas especificas las cuales ayudan a
comprender mejor el impacto del
software sobre el negocio y/o usuarios.
Ingeniería de Requerimientos:
Debe adaptarse a las necesidades delproceso
Es una acción que comienza durante laactividad de comunicación y lasactividades de modelado.
Tareas definidas para comprender mejorlos requisitos de software.
Es esencial analizar el problema antes deresolverlo.
Tareas de la IR Proporciona el mecanismo adecuado para
entender al cliente.
Se lleva acabo de siete funciones:
Inicio
Obtención
Elaboración
Negociación
Especificación
Validación
Gestión
Inicio
Tener una comunicación continua con el
cliente.
Obtener la suficiente información para
identificar correctamente el problema.
Obtención Es difícil definir cuales son los objetivos para
el sistema o producto, a continuación de
identifican una serie de problemas que
ayudan a entender la difícil obtención de
requisitos.
Para superar estos problemas, los ingenieros
de requisitos deben realizar en forma
organizada la actividad de recopilación de
requisitos.
Problemas de ámbito: Detalles innecesarios que noayudan a clarificar los objetivos generales del
sistema.
Problemas de comprensión: Los clientes no
comprenden y no están seguros del dominio del
problema, tienen problemas al comunicar sus
necesidades al isc, omiten información que para
ellos es obvia, especifican requisitos ambiguos o
inestables.
Problemas de volatilidad: Los problemas cambianconforme transcurre el tiempo.
Problemas comunes en la
obtención de requisitos
Elaboración
Se enfoca en el desarrollo de un modelo
técnico refinado de las funciones,
características t restricciones del software.
Se conduce mediante la creación y el
refinamiento de escenarios del usuario
que describen la forma en que el usuario
final interactuara en con el sistema.
Se obtienen clases de análisis.
Se definen atributos de cada clase de análisis.
Se identifican los servicios que requiere cada clase.
Se identifican las relaciones y colaboración entre
las clases.
El resultado es un modelo de análisis que define el
dominio de la información, funciones y el
comportamiento del problema.
Negociación Los clientes, usuarios y otros interesados deben
ordenar sus requisitos y posteriormente discutir losconflictos relacionados con la prioridad.
Se identifican y analizan riesgos asociados concada requisito.
Se hacen estimaciones preliminares del impacto,desarrollo, costo y tiempo.
Mediante un enfoque iterativo, los requisitos seeliminan, combinan o modifican de forma quecada parte alcance cierto grado de satisfaccion.
Especificación
Es el trabajo final que genera la IR.
Sirve como base para las actividades de
Ingeniería de Software subsecuentes.
Describe la función y el desempeño de
un sistema basado en computadora y las
restricciones que regirán el desarrollo.
Validación
Examina la especificación para asegurar
que los requisitos del software se han
establecido de manera precisa, que se
han detectado las inconsistencias,
omisiones y errores y que han sido
corregidos.
Los productos de trabajo cumplen con
los estándares establecidos por el
proceso, proyecto y producto.
Gestión de Requisitos
Conjunto de actividades que ayudan al
equipo de protector a identificar,
controlar y rastrear los requisitos y los
cambios a estos en cualquier momento
mientras se desarrolla el proyecto.
Comienza con la identificación.
Una vez identificados los requisitos de desarrollan lastablas de rastreabilidad:
Tabla de rastreabilidad de las características:muestra la relación entre las características delsistema/ producto observable para el cliente.
Tabla de rastreabilidad de la fuente: identifica lafuente de cada requisito.
Tabla de rastreabilidad de dependencia: indicala forma en que los requisitos están relacionadosentre si.
Tabla de rastreabilidad del subsistema: establececategorías entre los requisitos de acuerdo a lossubsistemas que gobiernan.
Tabla de rastreabilidad de la interfaz: muestra laforma en que los requisitos se relacionan con lasinterfaces internas y externas del sistema.
INICIO DEL PROCESO DE LA
INGENIERIA DE REQUISITOS
Para comenzar un proyecto de forma que
se mantenga en movimiento hacia una
solución exitosa se deben seguir los
siguientes pasos:
Identificación de los interesados
Crear una lista de personas que
contribuirán durante la obtención de
requisitos.
Reconocimiento de múltiples
puntos de vista Categorizar toda la información de los
interesados en forma que permita a quienestomen la decisión de elegir un conjunto derequisitos para el sistema y que seaconsistente de manera interna.
Trabajo con respecto a la
colaboración
Identificar áreas en común ( es decir, los
requisitos en los que los interesados están
de acuerdo) y áreas de conflicto o
inconsistencia.
Formulación de Preguntas
Son libres de contexto.
Son preguntas como ¿Quién?
¿Cómo?¿Qué?... Etc.
Este tipo de preguntas ayudan a
identificar a todos los participantes que
están interesados en el proyecto.
Existen otro tipo de preguntas que son las que
dejan que el equipo de DS comprenda mejor el
problema a solucionar.
¿Cómo?
¿Cuáles?
¿Podría describir en donde utilizaran la solución?
La serie de preguntas finales:
Son las llamadas metapreguntas, que son
encadas a la efectividad de la actividad
de la comunicación en si misma.
Recopilación conjunta de
Requisitos
En esta etapa los desarrolladores trabajan
conjuntamente con un equipo de trabajo
para identificar el problema y proponer
elementos de solución.
Directrices Básicas
Las reuniones las dirige alguno de losasistentes, ya sea ingeniero de software oun cliente.
Se establecen reglas para la preparacióny la participación.
Se sugiere una agenda que sea tanformal como para cubrir todos los puntos.
Un moderador, que es el que controla lareunión.
Después de la etapa de preguntas y
respuestas, se elabora la “Solicitud del
Producto”, se revisa previo a la reunión y
después de esto se le pide a cada
asistente elabore una lista de los servicios
que manipulan o interactúan con los
objetos.
El objetivo es desarrollar una lista consensada
en el área de cada tópico. Después de que
esta lista es completada, el equipo se divide
en subequípos menores, para desarrollar
miniespecificaciones.
Después de realizar las miniespecificaciones, se
comentan en el equipo de trabajo para
analizar si se descubrieron nuevos requisitos,
servicios, restricciones y rendimiento.
Despliegue de la función de
calidad (QFD)
QFD se concentra en aumentar lasatisfacción del cliente desde el proceso dela ingeniería del software.
El QFD identifica tres tipos de requisitos:
1. Requisitos normales (objetivos y metas)
2. Requisitos esperados (facilidad deinteracción)
3. Requisitos estimulantes (mas allá de lasexpectativas del cliente)
Escenarios del usuario
Los escenarios, llamados con frecuencia casos
de uso proporcionan una descripción de
como se usara el sistema.
Productos de trabajo de la obtención
Productos de trabajo:
Un enunciado de necesidad y facilidad
Un enunciado limitado del ámbito del sistema oproducto
Una lista de cliente, usuarios y otros interesadosque participaron en la obtención de requisitos
Una descripción del ambiente técnico del sistema
Una lista de requisitos y las restricciones dedominio aplicables a cada uno
Un conjunto de escenarios de uso queproporcionen un discernimiento de la utilizacióndel sistema o producto en diferentes condicionesde operación.
Cualesquiera prototipo desarrollados para definirde mejor forma los requisitos.
Desarrollo de casos de uso Un caso de uso captura un contrato
Comportamiento del sistema
Definir los actores (diferentes personas que van a utilizar el
sistema)
Preguntas para crear los casos de uso
1. ¿Quién es el actor primario?
2. ¿Cuales son las metas del actor?
3. ¿Cuáles son las condiciones previas que deben existir
antes de comenzar la historia?
4. ¿Cuáles son las tareas o funciones principales que
realiza el actor?
5. ¿Cuáles excepciones podrían consideraras mientras se
describe la historia ?
6. ¿Cuáles son las variaciones posibles en la interacción
del actor?
Diagrama entidad-relación
La pareja objeto-relación es la piedra angular delmodelo de datos. Con este diagrama se identificanlos componentes primarios :
Objetos de datos, atributos, relaciones e indicadoresde varios tipos. El propósito primordial de estemodelo es representar objetos de datos y susrelaciones.
Las conexiones entre objetos de datos y relacionesse establecen mediante una variedad de símbolosespeciales que indican su cardinalidad y modalidad.
Diagrama Entidad-Relación
Análisis Orientado a Objetos.1. Deben comunicarse los requisitos básicos del usuario entreel cliente y el ingeniero de software.
2. Deben identificarse las clases.
3. Se define una jerarquía de clases.
4. Deben representarse las relaciones de objeto a objeto.
5. Debe modelarse el comportamiento del objeto.
6. Las tareas 1 a 5 se vuelven a aplicar de manera iterativahasta que el modelo esté completo.
Conceptos Orientados a
Objetos
Atributos: Una colección de valores de losdatos que describen una clase.
Clase: Encapsula datos y las abstraccionesde procedimiento requeridos para describir elcontenido y el comportamiento de algunaentidad del mundo real.
Objeto: Instancia de una clase en especifica,heredan los atributos y operaciones de unaclase.
Conceptos Orientados a
Objetos
Operaciones: también llamadas métodos yservicios, proporcionan la representación de unode los comportamientos de una clase.
Subclase: una especialización de la superclase.Una subclase puede heredar tanto los atributoscomo las operaciones de una superclase.
Superclase: también llamada clase básica, es unageneralización de un conjunto de clases queestán relacionadas con ella.
Actividades de negociación En lugar de actividades sencillas de
comunicación con el cliente, se define lassiguientes actividades:
1. Identificación de los interesados clave en elsistema o subsistema.
2. Determinación de las «condiciones ganadoras»de los interesados
3. Negociación de las condiciones ganadoras delos interesados para reconciliarlas en conjuntode condiciones del tipo ganar- ganar paratodos los involucrados (incluso el equipo desoftware).
El arte dela negociación
1. Reconocer que no es una competencia
2. Diseñar una estrategia
3. Escuchar de manera activa
4. Enfocarse en los intereses de la otra
parte
5. No dejar que se vuelva personal
6. Ser creativo
7. Estar listo para pactar.
Validación de requisitosUna revisión del modelo de análisis se enfoca en las
siguientes preguntas:
¿cada requisito es consistente con el objetivo general delsistema/producto?
¿todos los requisitos han sido especificados con el grado
apropiado de abstracción?
¿el requisito es necesario en realidad o representa una
característica agregada irrelevante para el objetivo delsistema?
¿cada requisito esta limitado y no es ambiguo?
Estas y otras preguntas deben realizarse y contestarse para
asegurar que el modelo de requisitos es un reflejo exacto de
las necesidades del cliente y que proporciona una base
sólida para el diseño.