metodologías de análisis 1 el proceso de la especificación de requerimientos metodologías de...

Metodologías de Análisis1

El proceso de la Especificación de Requerimientos

Metodologías de Análisis


Ingeniería de Requisitos

La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente:

.

+ Analizando necesidades

+ Confirmando su viabilidad

+ Negociando una solución razonable

+ Especificando la solución sin ambigüedad

+ Validando la especificación

+ Gestionando los requisitos para que se transformen

en un sistema operacional



• Conocer las principales actividades de la ingeniería de requisitos y sus relaciones.

• Introducir a diversas técnicas para la obtención y análisis de requisitos.

• Conocer la importancia de la validación de requisitos y la utilización de las revisiones en este proceso.

Índice del Tema

• Entender por qué es necesaria la administración de requisitos y cómo ayuda a otras actividades de la misma.



• Estudios de Factibilidad

• Obtención y Análisis de Requisitos

• Validación de Requisitos

• Administración de Requisitos

Tópicos a Cubrir



• Estudio de Factibilidad --> Informe de Factibilidad

• Especificación de Requisitos --> Requisitos del Usuario y del Sistema

Introducción

Actividades Genéricas de la Ingeniería de Requisitos

• Obtención y análisis de Requisitos --> Modelo de Sistemas

• Validación de Requisitos --> Documento de Requisitos


Ingeniería de RequisitosEstudio de Factibilidad

• Entrada: descripción resumida del sistema y de cómo se usará dentro de una organización.

• Salida: informe que recomienda si es conveniente llevar a cabo la ingeniería de requisitos y el proceso de desarrollo del sistema.



Estudio de Factibilidad

Estudio corto y orientado a resolver varias preguntas:

• ¿El sistema contribuye a los objetivos generales de la organización?

• ¿El sistema se puede implementar utilizando la tecnología actual y con las restricciones de costo y tiempo?

• ¿El sistema puede integrarse a otros que existen en la organización?



Aspecto Crítico: ¿el sistema contribuye a los objetivos del negocio?

• Si la respuesta es no, entonces el sistema no tiene un valor real para el negocio.



Actividades:

• Evaluación y Recolección de la Información.

– Identifica la información requerida para contestar las tres preguntas anteriores.

– Luego, se cuestionan las fuentes de información para descubrir las respuestas.



Actividades:

• Evaluación y Recolección de la Información: preguntas...

– ¿cómo se las arreglaría la organización si no se lleva a cabo este sistema?

– ¿cuáles son los problemas con los procesos actuales y cómo ayudaría el nuevo sistema a resolverlos?

– ¿cuál es la contribución directa que hará el sistema a los objetivos del negocio?



Actividades:

• Evaluación y Recolección de la Información: preguntas...

– ¿la información se puede obtener y transferir a otros sistemas de la organización?.

– ¿el sistema requiere de tecnología que no se ha utilizado previamente en la organización?

– ¿a qué debe ayudar el sistema y a qué no necesita ayudar?



Actividades:

• Evaluación y Recolección de la Información: fuentes...

– Administradores de departamentos– Ingenieros de software– Expertos en tecnología– Usuarios finales



Actividades:

• Redacción de Informes

– Recomendación de cuándo debe continuar el desarrollo del sistema.

– Debe proponer cambios en el alcance, presupuesto y calendarización del sistema.

– Sugerir requerimientos adicionales de alto nivel.


Ingeniería de RequisitosObtención y Análisis de Requisitos

• Objetivos: determinar el dominio de la aplicación, cuáles servicios debe proveer el sistema, el desempeño requerido, etc.

• Se deben incluir diversos tipos de personas de la organización: stakeholders.



Proceso: difícil debido a...

• Los stakeholders de un sistema expresan los requisitos con sus propios términos, de forma natural y con un conocimiento explícito de su trabajo.

• Los stakeholders, a menudo, no conocen realmente lo que desean obtener del sistema, excepto en términos muy generales.



• Los factores políticos influyen en los requisitos del sistema.

• Diferentes stakeholders tienen requisitos diferentes y podrían expresarlos de varias formas.

• El entorno económico y de negocios en el que se lleva a cabo el análisis.

Proceso: difícil debido a...



Proceso: actividades del...

• Comprensión del problema.

• Clasificación.

• Recolecciónde requisitos.

• Resolución de conflictos.

• Priorización.

• Verificación de requisitos.



Proceso: técnicas

• Obtención orientada al punto de vista (VORD).

• Etnografía.

• Escenarios.

• Análisis estructurado.

• Prototipos.



Técnica: Obtención Orientada a Puntos de Vista

• Los enfoques orientados a puntos de vista toman en cuenta diferentes puntos de vista, y los usan para estructurar y organizar tanto el proceso de obtención como los requisitos mismos.



Técnica: Obtención Orientada a Puntos de Vista

• Diferentes ideas de lo que significa un punto de vista:

– Una fuente o consumidor de datos.

– Un marco de trabajo de la representación.

– Un receptor de servicios.



Técnica: Obtención Orientada a Puntos de Vista…etapas:

• Identificación de puntos de vista, descubriendo los que reciben servicios del sistema e identificando los servicios específicos que se dan a cada punto de vista.

• Estructuración de puntos de vista, que comprende agrupar los relacionados en una jerarquía.



Técnica: Obtención Orientada a Puntos de Vista…etapas:

• Documentación de puntos de vista, que considera refinar la descripción de éstos y los servicios identificados.

• Trazado del punto de vista del sistema, que comprende identificar los objetos en un diseño orientado a objetos utilizando la información del servicio encapsulado en los puntos de vista.



Técnica: Obtención Orientada a Puntos de Vista…ejemplo.

• Referencia: Cliente• Atributos: Número de cuenta, clave secreta, inicio

transacción• Eventos: seleccionar servicio, cancelar transaccíón,

finalizar transacción• Servicios: retiro de efectivo, consulta de saldo• Subpuntos de Vista: cuenta habiente, cliente extranjero

Descripción de Punto de vista



• Referencia: Retiro de efectivo

• Fundamento: Mejorar el servicio al cliente y reducir papeleo

• Especificación: los usuarios eligen este servicio presionando el botón de retiro de efectivo. Después ingresan la cantidad requerida. Ésta se confirma y, si los fondos lo permiten, se entrega la cantidad solicitada.

• Puntos de Vista: Cliente

• Requisitos no Funcionales: entregar efectivo en menos de 30 segundos desde que se haya confirmado la cantidad.

Descripción de Servicio



Técnica: Etnografía

• Los sistemas de software no existen de forma aislada; se utilizan en un contexto social y organizacional.

• Un razón de por qué muchos sistemas de software se entregan pero no se usan (al menos con el impacto esperado), se debe a que no se toma en cuenta la importancia este tipo de requisitos.




• La etnografía es una técnica de observación que se puede utilizar para entender los requisitos sociales y organizacionales.

• Radica en que ayuda a descubrir los requisitos explícitos que reflejan los procesos reales más que los formales.

• Consiste en sumergir un analista en el entorno, para que observe el desarrollo diario del sistema.




• Especialmente efectiva para detectar:

– Los requisitos que se derivan de la forma en que la persona trabaja realmente, más que de la forma en que las definiciones de los procesos establecen que debería hacerse.

– Los requisitos que se derivan de la cooperación y conocimiento de las actividades de la gente.




• Se puede combinar con la construcción de prototipos (cont).

– La etnografía suministra información al desarrollo del prototipo de forma que se requieran menos ciclos de refinamiento.

– La construcción de prototipos usa la etnografía para identificar problemas y preguntas que se podrán discutir, posteriormente, con el etnógrafo.



Técnica: Escenarios

• Normalmente, es más fácil dar ejemplos de la vida diaria que descripciones generales o abstractas.

• Los analistas pueden aprovechar los datos obtenidos de estos ejemplos para formular los requisitos reales del sistema.

• Un escenario puede ser especialmente útil para agregar detalle a un bosquejo de descripción de requisitos.




• La obtención de requisitos basada en escenarios se puede llevar a cabo de modo informal trabajando directamente con los stakeholders, o aplicando un esquema más estructurado como los escenarios de eventos o los casos de uso.




• Un escenario incluye:– Una descripción del estado del sistema al inicio del escenario.

– Una descripción del flujo normal de eventos en el escenario.

– Una descripción de lo que puede ir mal y cómo manejarlo.

– Información de otras actividades que se podrían llevar a cabo al mismo tiempo.

– Una descripción del estado del sistema después de completar el escenario.


Especificación de requisitos de Calidad y otros Requisitos

• Todos los requisitos de calidad se pueden y deben expresar sin ambigüedades.

• Si un requisito se expresa claramente..– “Terminar antes del 15/09/2008”

• Se le da prioridad por sobre requisitos no tan claros– “más fácil de usar”– “Información consistente”– “User Friendly”– “Mejor que el sistema anterior”


Ejemplo de Requisito de Calidad cuantificado


Otro ejemplo de requerimiento de calidad


Cómo se describe un requisito de calidad


La escala y la prueba


Escala y Prueba


El peor nivel


El Nivel planificado


Los límites de la especificación de requisitos


Niveles actual y mejor


La autoridad


Jerarquía de Requisitos de calidad


Otro ejemplo de Jerarquía


Cómo hacer Jerarquía de Atributos


Análisis de requisitos


Caso M-DTV


Atributos relevantes del simulador (en Inglés)


Ease of learning


Ease of Operation


Time accuracy


TallerPaso 0: Identificar proyecto


Tallerpaso1: Jerarquía de Atributos


Tallerpaso 2: Especificación de Atributos


Clases de Atributos según ISO/IEC 9126 Parte 1


Requisitos usuales importantes


Atributos o cualidades ISO/IEC 9126-1


Advertencia


Funcionalidad


Confiabilidad


Usabilidad


Pseudo – Atributos de usabilidad


Eficiencia


Mantenibilidad


Portabilidad


Críticas a ISO/IEC 9126-1


Planificación de calidad


Pasos de la planificación de calidad


1.- Identificar los Interesados


Priorizar el Nivel de Impacto


Matriz de Priorización


Ejemplo con escala alternativa y unos en la diagonal


2.- Identificar Requerimientos de calidad del proyecto

• Acá sólo se enumeran los requerimientos de calidad• Cuidado que sean efectivamente requerimientos y no

sólo deseos o ideales.• Si algún requerimiento fuera de muy alto nivel (por

ejemplo, fácil de usar) conviene hacer una jerarquía de atributos.


3.- Priorizar requerimientos de calidad del proyecto

• Es posible usar una matriz de contribución• Identificar requerimientos y la contribución que hace a

cada interesado.• Contribución se pondera por la prioridad del interesado.• Esto entrega una priorización que indica cuánto

contribuye cada requerimiento a quién


4.- Desarrollo de Estándares de calidad del proyecto

• Estándar de calidad es una expresión medible de un requerimiento.– Anteriormente vimos como es posible especificarlos– Idealmente se hacen estándares para todos los requerimientos

de calidad, pero se podrían omitir los menos prioritarios.


Estándares de calidad SMART

• Cada Estándar debe ser SMART (Astuto)– S pecific (Específico)– M easurable (Medible)– A greed Upon (Acordado)– R ealistic (Realista)– T ime – bound (Acotado en el tiempo)


Estándares de calidad


Taller 1:Identificar Interesados


Taller 2:Priorizar interesados


Taller 3:Identificar requisitos


Taller 4:Priorización de requisitos de calidad

metodologías de análisis 1 el proceso de la especificación de requerimientos metodologías de...

Documents