INSTITUTO TECNOLOGICO SUPERIOR DE FRESNILLO

Resumen: Ingeniera de Requerimientos

Unidad 4.- Resumen

Materia: Ingeniera de Requerimientos Profesor: Alberto Rodrguez Zamarripa

Semestre: 7 Alumna: Ana Patricia Salas Torres

Contenido
Actividades del proceso de Ingeniera de Requerimientos ................................................................. 3 Anlisis del problema ...................................................................................................................... 3 Evaluacin y negociacin de los requerimientos ............................................................................ 5 Especificacin .................................................................................................................................. 6 Validacin ........................................................................................................................................ 6 Extraccin de informacin en Ingeniera de Requerimientos ............................................................. 7 Entrevistas y Cuestionarios ............................................................................................................. 7 Lluvia de ideas (Brainstorm) ............................................................................................................ 8 Proceso de Anlisis Jerrquico (AHP) .............................................................................................. 8 Documentacin de Requerimientos ................................................................................................... 8 Validacin de Requerimientos ............................................................................................................ 9 Administracin de Requerimientos..................................................................................................... 9 Requerimientos duraderos y voltiles. ............................................................................................. 11 Mtricas de la IR. ............................................................................................................................... 12

Actividades del proceso de Ingeniera de Requerimientos

A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son: Anlisis del Problema. Evaluacin y Negociacin. Especificacin. Validacin. Evolucin.

Anlisis del problema

El objetivo de esta actividad es entender la verdadera necesidad de los negocios. Antes de describir que pasos deben cumplirse en esta actividad, se debe tener una definicin clara del trmino Problema. Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean. Aqu vemos nuevamente la importancia que tiene una buena

comunicacin entre desarrolladores y clientes; de esta comunicacin con el cliente depende que entendamos sus necesidades. A travs de la definicin de problema, podemos ver entonces que la actividad de Anlisis del Problema tiene por objetivo que se comprendan los problemas del negocio, se evalen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solucin de alto nivel para resolverlo. Durante el anlisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Estos pasos son los siguientes: Comprender el problema que se est resolviendo: Es importante determinar quin tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista.

Las soluciones iniciales, deben ser definidas tomando en cuenta tanto la perspectiva tcnica como la del negocio. Construir un vocabulario comn: Debe confeccionarse un glosario en dnde se definan todos los trminos que tengan significados comunes (sinnimos) y que sern utilizados durante el proyecto.

La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunin estn en la misma pgina, adems de ser reutilizable en otros proyectos. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto.

Las necesidades de cada afectado, son discutidas y sometidas a debate durante de ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la informacin necesaria para especificar un sistema adecuado. Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern afectadas por el sistema, debemos realizar algunas preguntas. Quin usar el sistema que se va a construir? Quin desarrollar el sistema? Quin probar el sistema? Quin documentar el sistema? Quin dar soporte al sistema?

 Quin dar mantenimiento al sistema? Quin mercadear, vender, y/o distribuir el sistema? Quin se beneficiar por el retorno de inversin del sistema? Como vemos, debe conocerse la opinin de todo aqul que de una u otra forma est involucrado con el sistema, ya sea directa o indirectamente. Definir los lmites y restricciones del sistema: Este punto es importante pues debemos saber lo que se est construyendo, y lo que no se est construyendo, para as entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restriccin ambiental, presupuestaria, de tiempo, tcnica y de factibilidad que limite el sistema que se va a construir.

Evaluacin y negociacin de los requerimientos

La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluacin de los mismos antes de definir si son adecuados para el cliente. El trmino "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades tcnicas y econmicas, a la vez que se buscan resultados completos, correctos y sin ambigedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstraccin y descomposicin de cada problema presentado.

Los principales pasos de esta actividad son: Descubrir problemas potenciales: En este paso se asegura que todas las caractersticas antes descritas estn presentes en cada uno de los requerimientos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes. Clasificar los requerimientos: En este paso se busca identificar la importancia que tiene un requerimiento en trminos de implementacin. A esta caracterstica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirn las actividades de diseo y prueba de cada requisito. La prioridad de cada requerimiento depender de las necesidades que tenga el negocio.

En base a la prioridad, cada requerimiento puede ser clasificado como mandatario, deseables o innecesarios. Un requerimiento es mandatario si afecta una operacin crtica del negocio. Si existe algn proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario.

Una vez hecha esta categorizacin de los requerimientos, se puede tomar como estrategia general el incluir los mandatarios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusin de un requerimiento, tambin debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por ms que ste sea slo deseable. Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (pueden implementarse los requerimientos con la tecnologa actual?); factibilidades operacionales (puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades econmicas (ha sido aprobado por los clientes el presupuesto?). En la actividad de evaluacin y negociacin, se incrementa la comunicacin entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales estn: Documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones

Especificacin
En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la prctica, esta etapa se va realizando conjuntamente con el anlisis, pero podramos decir que la Especificacin es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin, como la notacin UML.

Validacin
La validacin es la etapa final de la IR. Su objetivo es verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripcin, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estn completos. La validacin representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se est haciendo, y externo, porque se debe validar con el cliente. Preferentemente, el documento de requerimientos obtenido en la etapa anterior slo debera incluir los requerimientos que son aceptables para los usuarios. Pero es inevitable que durante la validacin se descubran algunos problemas relacionados con los usuarios, y esto se debe corregir antes de aprobarse el documento final de requerimientos. En definitiva, la validacin de especificaciones realmente significa asegurarse de que el documento de requerimientos represente una descripcin clara del sistema, y es una verificacin

final de que los requerimientos cubren las necesidades de los usuarios. Esta etapa puede confundirse con la de anlisis, pero la diferencia es clara: mientras que en el anlisis se trabaja sobre el boceto del documento de requerimientos, en la validacin se utiliza el documento final, lo que equivale a decir, los requerimientos "depurados".

Extraccin de informacin en Ingeniera de Requerimientos

Entrevistas y Cuestionarios
Se emplean para reunir informacin proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema. Por lo comn, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que sern afectados por l. Las preguntas que deben realizarse en esta tcnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener informacin sobre aspectos globales del problema del usuario y soluciones potenciales. Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar un proceso o problema. Este tipo de preguntas son siempre apropiadas, adems que ayudan a entender la perspectiva del afectado y no estn influenciadas por el conocimiento de la solucin. Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El siguiente ejemplo muestra algunos tipos de preguntas abiertas. Del Usuario Del Proceso Del Producto Cul es la razn por la que se quiere resolver este problema? Cul es el valor de una solucin exitosa? Cmo usted resuelve el problema actualmente? Qu retrasos ocurren o pueden ocurrir? Quin es el cliente? Quin es el usuario? Son sus necesidades diferentes? Cules son sus habilidades, capacidades, ambiente?

Qu problemas podra causar este producto en el negocio? En qu ambiente se usar el producto? Cules son sus expectativas para los conceptos fcil de usar, confiable, rendimiento? Qu obstculos afectan la eficiencia del sistema?

El xito de esta tcnica combinada, depende de la habilidad del entrevistador y de su preparacin para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la entrevista y saber cmo tratar con problemas potenciales. Asimismo, necesitan considerar no slo la informacin que adquieren a travs del cuestionario y la entrevista, sino tambin, su significancia.

Lluvia de ideas (Brainstorm)

Este mtodo comenz en el mbito de las empresas, aplicndose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos mtodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se extendi a otros mbitos, incluyendo el mundo de desarrollo de sistemas; bsicamente se busca que los involucrados en un proyecto desarrollen su creatividad, promoviendo la introduccin de los principios creticos. A esta tcnica se le conoce tambin como torbellino de ideas, tormenta de ideas, desencadenamiento de ideas, movilizacin verbal, bombardeo de ideas, sacudidas de cerebros, promocin de ideas, tormenta cerebral, avalancha de ideas, tempestad en el cerebro y tempestad de ideas, entre otras.

Proceso de Anlisis Jerrquico (AHP)

Esta tcnica tiene por objetivo resolver problemas cuantitativos, para facilitar el pensamiento analtico y las mtricas. Consiste en una serie de pasos, a saber: Encontrar los requerimientos que van a ser priorizados. Combinar los requerimientos en las filas y columnas de la matriz n x n de AHP. Hacer algunas comparaciones de los requerimientos en la matriz. Sumar las columnas. Normalizar la suma de las filas. Calcular los promedios.

Estos pasos pueden aplicarse fcilmente a una cantidad pequea de requerimientos, sin embargo, para un volumen grande, esta tcnica no es la ms adecuada.

Documentacin de Requerimientos
Los documentos de Ingeniera de Requerimientos son largos. La mayora estn compuestos de cientos o miles de pginas; cada pgina contiene muchos detalles que pueden tener efectos profundos en el resto del sistema. Normalmente, las personas se encuentran con dificultades para

comprender documentos de este tamao, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificacin de gran tamao, pues difcilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta despus de haberse construido el sistema.

Validacin de Requerimientos
El resultado del trabajo realizado es una consecuencia de la ingeniera de requisitos (especificacin del sistema e informacin relacionada) y es evaluada su calidad en la fase de validacin. La validacin de requisitos examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estndares establecidos para el proceso, el proyecto y el producto. El primer mecanismo para la validacin de los requisitos es la revisin tcnica formal. El equipo de revisin incluye ingenieros del sistema, clientes, usuarios, y otros intervinientes que examinan la especificacin del sistema buscando errores en el contenido o en la interpretacin, reas donde se necesitan aclaraciones, informacin incompleta, inconsistencias (es un problema importante), requisitos contradictorios o requisitos imposibles o inalcanzables.

Administracin de Requerimientos
Es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento. Muchas de estas actividades son idnticas a las tcnicas de gestin de configuracin del software. TCNICA Entrevistas Y Cuestionarios VENTAJAS DESVENTAJAS

Mediante ellas se obtiene una La informacin obtenida al gran cantidad de informacin principio puede ser correcta a travs del usuario. redundante o incompleta. Pueden ser usadas para Si el volumen de informacin obtener un pantallazo del manejado es alto, requiere dominio del problema. mucha organizacin de parte del analista, as como la Son flexibles. Permiten combinarse con habilidad para tratar y comprender el otras tcnicas. comportamiento de todos los involucrados. Los diferentes puntos de vista Es necesaria una buena y las confusiones en cuento a compenetracin del grupo terminologa, son aclarados participante. por expertos.

Lluvia de Ideas

Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto.

Anlisis Jerrquico

Permite determinar el grado de importancia de cada requerimiento. Ayuda a identificar conflictos en los requerimientos. Muestra el orden en que deben ser implementados los requerimientos.

Debe construirse un estndar claro de evaluacin, que incluya la participacin del cliente.

Actividades en donde pueden ser utilizadas las tcnicas de IR.

Anlisis del Problema Evaluacin y Negociacin

Especificacin Validacin de los Requisitos

Evolucin

Entrevistas y cuestionarios Lluvia de idea Prototipos Anlisis Jerrquico Casos de Usos

X X X X X X

X X X X

Como en la Gestin de Configuracin del Software (GCS), la gestin la gestin de requisitos comienza con la actividad de identificacin. A cada requisito se le asigna un nico identificador, que puede tomar la forma: <tipo de requisito><requisito n,o>

Requerimientos duraderos y voltiles.

Requerimientos duraderos: Son requerimientos relativamente estables que se derivan de la actividad principalmente de la organizacin y que estn relacionados directamente con el dominio del sistema. Requerimientos voltiles: Son requerimientos que probablemente cambian durante el proceso de desarrollo del sistema o despus de que se haya puesto en funcionamiento Clasificacin de los Requerimientos Voltiles. TIPO DE REQUERIMIENTOS Requerimientos cambiantes DESCRIPCION Requerimientos que cambian debido a los cambios en el entorno en el que opera la organizacin. Requerimientos que emergen al

Requerimientos emergentes

Requerimientos consecuentes Requerimientos de compatibilidad

incrementarse la comprensin del cliente en el desarrollo del sistema. Requerimientos que son resultado de la introduccin del sistema informtico. Requerimientos que dependen de sistemas particulares o procesos de negocios dentro de la organizacin.

Mtricas de la IR.
Una mtrica es un instrumento que cuantifica un criterio. Las mtricas nos ayudan a entender tanto el proceso tcnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad. Desgraciadamente la medicin se aleja de lo comn en el mundo de la ingeniera del software. Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas. Hay varias razones para medir un producto. 1. Para indicar la calidad del producto. 2. Para evaluar la productividad de la gente que desarrolla el producto. 3. Par evaluar los beneficios en trminos de productividad y de calidad, derivados del uso de nuevos mtodos y herramientas de la ingeniera de software. 4. Para establecer una lnea de base para la estimacin 5. Para ayudar a justificar el uso de nuevas herramientas o de formacin adicional. Las mediciones del mundo fsico pueden englobarse en dos categoras: medidas directas y medidas indirectas. Medidas Directas. En el proceso de ingeniera se encuentran el costo, y el esfuerzo aplicado, las lneas de cdigo producidas, velocidad de ejecucin, el tamao de memoria y los defectos observados en un determinado periodo de tiempo. Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc. MTRICAS DEL SOFTWARE Son las que estn relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia. MTRICAS TCNICAS: Se centran en las caractersticas de software por ejemplo: la complejidad lgica, el grado de modularidad. Mide la estructura del sistema, el cmo est hecho.

MTRICAS DE CALIDAD: proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente. MTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniera del software. Es decir que tan productivo va a ser el software que voy a disear. MTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e informacin sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y mtodos. Son las medidas que voy a hacer de mi personal que va har el sistema. MTRICAS ORIENTADAS AL TAMAO. Es para saber en qu tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organizacin de software mantiene registros sencillos. MTRICAS ORIENTADAS A LA FUNCIN. Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las mtricas orientadas a la funcin se centran en la funcionalidad o utilidad del programa. Las mtricas orientadas a la funcin fueron el principio propuestas por Albercht quien sugiri un acercamiento a la medida de la productividad denominado mtodo del punto de funcin. Los puntos de funcin que obtienen utilizando una funcin emprica basando en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivos de la complejidad del software. 1. Inicio del Plan: Determina el arranque formal del plan de sistemas, con el apoyo del nivel ms alto de la organizacin. 2. Definicin y Organizacin: Detalla y concreta la descripcin del PSI asignando un calendario y recursos humanos al mismo 3. Estudio informacin relevante: Se analiza informacin de inters para el correcto desarrollo del plan de sistemas 4. Identificacin Requisitos: Obtiene la especificacin de requisitos que deben tener los sistemas de informacin analizados por el plan de sistemas. 5. Estudio S.I. Actuales: Obtiene una valoracin de la situacin actual. 6. Diseo modelo: Identifica y define los S.I. Que van a dar soporte a los procesos afectados por el Plan de Sistemas de Informacin 7. Arquitectura tecnolgica: Se propone la arquitectura tecnolgica que d soporte al modelo de informacin y sistemas de informacin. 8. Definicin plan: Se elabora y detalla el plan de sistemas de informacin: definicin de proyectos, actividades, calendario y recursos para implementar los sistemas de informacin e infraestructura tecnolgica 9. Revisin y aprobacin: Se somete el plan a la revisin ltima y aprobacin de la direccin. 10. Documentacin:

Catlogo de requisitos Arquitectura de informacin Modelo de informacin Modelo de sistemas de informacin Arquitectura tecnolgica Plan de accin Plan de proyectos Plan de mantenimiento

Fases de la mtrica: METRICAS COMO PLANEACION DE SISTEMAS LOS OBJETIVOS PRINCIPALES DE LAS MTRICAS Comprender mejor la calidad del producto Estimar la efectividad del proceso Mejorar la calidad del trabajo realizado en el nivel del proyecto.

DESVENTAJAS DE LAS METRICAS Uno de los problemas que tienen las mtricas es que no existe un esquema de criterios generalmente aceptado (un estndar). Como no hay acuerdo en los criterios involucrados, abundan las propuestas de mtricas que abordan la calidad con criterios propios. Otro problema de las mtricas es que no proporcionan informacin por s solas y a veces en vez de claridad aportan confusin a la contraparte del modelador dentro del proceso. Esto se debe a que muchas mtricas no guardan relacin con los intereses de las partes, y el indicador de la calidad de un esquema se construye generalmente con todas ellas. CARACTERISTICAS DE LAS METRICAS Localizacin: La localizacin es una caracterstica del software que indica la forma que se concentra la informacin dentro de un programa. Encapsulamiento: define el encapsulamiento como el empaquetamiento (o enlazado) de una coleccin de elementos. Entre los ejemplos de encapsulamiento de bajo nivel (software convencional) se cuentan los registros y matrices, y los subprogramas (por ejemplo, procedimientos, funciones, subrutinas y prrafos) son mecanismos de nivel medio para el encapsulamiento. El encapsulamiento influye en las mtricas cambiando el objetivo de la medida, que pasa de ser un nico mdulo a ser un paquete de datos (atributos) y de mdulos de procesamiento (operaciones). Adems, el encapsulamiento impulsa a la medida hasta un nivel de abstraccin ms elevado.

Ocultamiento de informacin: El ocultamiento de informacin suprime los detalles operativos de un componente de un programa. Tan slo se proporciona la informacin necesaria para acceder a ese componente o a aquellos otros componentes que deseen acceder a l. Herencia: La herencia es un mecanismo que hace posible que los compromisos de un objeto se difundan a otros objetos. La herencia se produce a lo largo de todos los niveles de la jerarqua de clases Abstraccin: La abstraccin es un mecanismo que permite al diseador centrarse en los detalles esenciales de algn componente de un programa (tanto si es un dato como si es un proceso) sin preocuparse por los detalles de nivel inferior.