unidad i / procesos de la ingenieria de requerimientos · pdf filela ingeniería de...

UNIDAD I / PROCESOS DE LA INGENIERIA DE REQUERIMIENTOS

1

UNIDAD 1

PROCESOS DE LA INGENIERIA DE

REQUERIMIENTOS

Objetivo: El estudiante conocerá, y

discriminará los tipos de

requerimientos para un proyecto de

software.


2

UNIDAD 1.-PROCESOS DE LA INGENIERIA DE REQUERIMIENT OS

INTRODUCCIÓN.

La ingeniería de requerimientos es un proceso que comprende todas las actividades para crear y mantener los requerimientos de un sistema.

En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los años, la Ingeniería de Software ha introducido y popularizado una serie de estándares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Se han publicado muchos libros y artículos relacionados con este tema, con el modelado de procesos del negocio y la reingeniería. Un número creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en día la economía global depende más de sistemas automatizados que en épocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y estándares de calidad.

Sin embargo, ¿cómo explicamos la alta incidencia de fallos en los proyectos de software? ¿Por qué existen tantos proyectos de software víctimas de retrasos, presupuestos sobregirados y con problemas de calidad? ¿Cómo podemos tener una producción o una economía de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema?

Tal vez suene ilógico pero, a pesar de los avances que ha dado la tecnología, aún existen procesos de producción informales, parciales y en algunos casos no confiables.

La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.

En nuestro país somos partícipes de este problema a diario, en donde se ha vuelto común la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas.

El reemplazo de plataformas y tecnologías obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definición de los requerimientos.

Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participación del usuario, requerimientos incompletos y el cambio a los requerimientos, también ocupan sitiales altos en los motivos de fracasos.


3

¿Qué son Requerimientos?

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presentan algunas definiciones:

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

Un requerimiento puede definirse como un atributo necesario dentro de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales. A nivel general los requerimientos pueden clasificarse como requerimientos indicados o reales. Los requerimientos indicados son los entregados por el usuario al comienzo del proyecto, en tanto que los requerimientos reales son aquellos que reflejan la satisfacción de las necesidades del usuario en un sistema en particular. El proceso para convertir los requerimientos indicados en requerimientos reales consisten en un proceso de filtrado según el significado y otros aspectos según se considere.

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.

Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Características de los requerimientos

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo.

A continuación se presentan las más importantes.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El


4

lenguaje usado en su definición, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

Dificultades para definir los requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes. • Son difíciles de expresar en palabras (el lenguaje es ambiguo). • Existen muchos tipos de requerimientos y diferentes niveles de detalle. • La cantidad de requerimientos en un proyecto puede ser difícil de manejar. • Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más

estables que otros. • Los requerimientos están relacionados unos con otros, y a su vez se relacionan con

otras partes del proceso. • Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales

específicas. • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. • Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para

cada proyecto.

DEFINICION DE INGENIERIA DE REQUERIMIENTOS

"Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979.

"Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987.

"Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987.

La Ingeniería de Requerimientos se define, según Ortas [Ortas 1997], como un "conjunto de actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces más de una)." Entonces, "Ingeniería de Requerimientos" se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto determinado. El uso del término "ingeniería" implica que se deben utilizar técnicas sistemáticas y repetibles para asegurar que los requerimientos del sistema estén completos y sean consistentes y relevantes.

"Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto".


5

Importancia de la Ingeniería de Requerimientos

Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son:

• Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.

• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

• Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.

• Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).

• Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

• Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

1.-REQUERIMIENTOS DE PROCESO

Un proceso es un conjunto ordenado de tareas; una serie de pasos que involucran actividades, restricciones y recursos que producen una determinada salida esperada.

Un proceso involucra por lo general un conjunto de herramientas y técnicas.

Un proceso es entonces, un conjunto de procedimientos de tal modo que los productos que se construyen satisfacen un conjunto de metas o estándares.

Un procedimiento es una serie de pasos; una manera de combinar herramientas y técnicas para generar un producto.

Características de los procesos:

� Un proceso utiliza recursos � Esta sujeto a una serie de restricciones � Genera productos intermedios y finales � Cada actividad del proceso tiene criterios de entrada y salida, es decir se conoce

cuando inicia y termina el proceso � Todo proceso tiene un conjunto de principios que permiten explicar las metas de

cada actividad � Las actividades se realizan secuencialmente.

Cuando el proceso implica la construcción de algún producto, solemos referirnos al proceso como un ciclo de vida.

El proceso de desarrollo de software se denomina ciclo de vida del software.

Los procesos son importantes porque imponen consistencia y estructura sobre un conjunto de actividades.

Un proceso de desarrollo de software debe describirse de forma flexible de modo que permita que las personas diseñen y construyan el software utilizando las técnicas y herramientas preferidas.

Fases en la definición de requerimientos

PROCESO DE DESARROLLO DE SOFTWARE


Un proceso de desarrollo de software debe describirse de forma flexible de modo que mita que las personas diseñen y construyan el software utilizando las técnicas y

herramientas preferidas.

Fases en la definición de requerimientos

PROCESO DE DESARROLLO DE SOFTWARE

PROCESOS DE LA INGENIERIA DE REQUERIMIENTOS

6

Un proceso de desarrollo de software debe describirse de forma flexible de modo que mita que las personas diseñen y construyan el software utilizando las técnicas y


7

� Cada etapa en sí misma es un proceso (o colección de procesos) que puede ser descrito como un conjunto de actividades.

� Cada actividad tiene restricciones, salidas y recursos.

¿POR QUE DEBEMOS MODELAR UN PROCESO?

� Para tener una comprensión común de las actividades, recursos y restricciones del proyecto.

� Para encontrar las inconsistencias, redundancias y omisiones en el proceso y en las partes que lo constituyen; así se pueden corregir y de esta manera se obtiene un producto final de calidad.

� Para fijar las metas de desarrollo. � Para cumplir con cada actividad, con las restricciones y el presupuesto

establecido. � Debe existir adaptación a la situación especial en la que se utiliza. � Para construir un producto de calidad y que sea efectivo.

Para definir un modelo de desarrollo de software debemos tener en cuenta:

Al cliente, al usuario, el tiempo, el presupuesto, los recursos tanto materiales como humanos, el objetivo del proyecto y los requerimientos, entre otras cosas.

MODELOS DE DESARROLLO DE SOFTWARE

Modelo tradicional en cascada

Este modelo sugiere que los resultados de una tarea del proceso llevan a la siguiente, y así sucesivamente. En el ejemplo presentado, la extracción lleva al análisis, el análisis desencadena la documentación, y la documentación inicia la validación.

Si se ve a este modelo como una descripción general del proceso, es un modelo útil. Sin embargo, se debe entender que la realidad del proceso de IR es mucho más compleja que lo que se vislumbra a partir del modelo en cascada: no existen fases claramente delimitadas ya que hay una retroalimentación constante entre las distintas etapas; los requerimientos del sistema van cambiando por circunstancias ajenas al proceso (como una ley nueva o un cambio de mercado que a su vez cambia las necesidades de la empresa) durante el desarrollo del mismo; se descubren problemas durante la validación que llevan a un cambio de requerimientos, etc.; y todo esto hará que más de una vez se tenga que volver "hacia atrás" en el proceso de IR.

Modelo en espiral

Un modo alternativo de presentar modelos de actividad que toma en cuenta la retroalimentación entre etapas y la repetición de tareas, es el llamado Modelo en Espiral.


8

En este diagrama, el uso de la espiral implica que las diferentes actividades de la ingeniería de requerimientos son repetidas hasta que se toma la decisión final, que es la aceptación del documento de especificación de requerimientos.

Es decir, si en el diseño preliminar se encuentran problemas, entonces se recorrerá el ciclo nuevamente (extracción-análisis-especificación-validación) hasta que todos sean resueltos, que es lo mismo que decir que este ciclo continuará hasta que se pueda elaborar un documento aceptable.

Pero también existen factores externos que pueden determinar la finalización del ciclo, como por ejemplo la presión por cumplir con un determinado cronograma.

Luego del análisis de los dos modelos básicos antes mencionados, se podrá concluir que dado el escenario de trabajo es más válida la aplicación del modelo en espiral para desarrollar el proceso de IR. Y es que el modelo en espiral representa de manera más real cómo se irán desarrollando las actividades del proceso; esto es, debido al desconocimiento del tema, se genera un grado demasiado alto de incertidumbre que sólo puede disminuirse al repetir el ciclo de trabajo una y otra vez, permitiendo así ajustar todos los parámetros, cada vez en mayor detalle, hasta lograr un resultado satisfactorio.

2.-REQUERIMIENTOS DE LOS USUARIOS (ACTORES INVOLUCR ADOS)

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más de un tipo de usuario, los analistas de requisitos han de tomar en consideración a todos los implicados para que se obtengan y depuren sus requerimientos de la forma más fidedigna posible.

Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.


9

No conocer estos intereses puede ocasionar una comunicación poco efectiva entre clientes y desarrolladores, que a la vez traería impactos negativos tanto en tiempo como en presupuesto.

Los roles más importantes pueden clasificarse como sigue:

• Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario.

• Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema.

• Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.

• Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan directamente con el cliente.

• Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos, entre otros.

Problemas relacionados con los actores involucrados

Las vías que pueden dificultar la determinación de los requisitos se presentan a continuación:

Relacionados con los usuarios

• Los usuarios no tiene claro lo que desean • Los usuarios no se involucran en la elaboración de requisitos escritos • Los usuarios insisten en nuevos requisitos después de que el coste y la

programación se hayan fijado. • La comunicación con los usuarios es lenta • Los usuarios no participan en revisiones o son incapaces de hacerlo. • Los usuarios no comprenden los problemas técnicos • Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situación donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya está en marcha.

Relacionados con los desarrolladores

Los problemas posibles causados por los desarrolladores durante análisis de requisitos son:


10

• El personal técnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que están de acuerdo, no dándose cuenta del desacuerdo hasta que se provee el producto final.

• Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente.

• El análisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en vez de personal con las dominio habilidades de relación con la gente y el conocimiento del para entender las necesidades de un cliente correctamente.

3.-REQUERIMIENTOS PARA EL ANALISIS Y NEGOCIACION

ANALISIS

Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y además contienen múltiples relaciones entre sí. Lo que nos da a concluir, de acuerdo a lo expuesto anteriormente, que el conjunto de requerimientos de un sistema computacional es complejo.

Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Esto se logra mediante al clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras palabras al analizar sus requerimientos.

El análisis de requerimientos consiste brevemente en los siguientes pasos:

• Obtener información acerca de lo que los usuarios desean

• Clasificar esos deseos para comenzar a estructurar requerimientos

• Identificar los niveles de jerarquía del sistema y empezar a alojar los ya clasificados requerimientos en cada nivel.

• Especificar formalmente los requerimientos de acuerdo al nivel de audiencia que se desea.

Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente.

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que para recabarlos haya que obtener la información de primera mano. Esto es, mediante entrevistas con el cliente o recabando documentación que describa la manera que el cliente desea que funcione el sistema de software.

Las necesidades y/o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentación


11

original del cliente, así como cada revisión o cambio que se haga a esta documentación

Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuáles de ellas serán satisfechas por el software y cuales por algún otro producto del sistema.

NEGOCIACION

La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El término "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan resultados completos, correctos y sin ambigüedades.

En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y descomposición de cada problema presentado.

Los principales pasos de esta actividad son:

Descubrir problemas potenciales: En este paso se asegura que todas las características de los requerimientos estén presentes en cada uno de los ellos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc.

Clasificar los requerimientos:

En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño 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 clasificados como mandatorio, deseables o innecesarios. Un requerimiento es mandatorio si afecta una operación crítica del negocio. Si existe algún 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 categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también 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 más que éste sea sólo deseable.

Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología actual?); factibilidades operacionales (¿puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).


12

En la actividad de negociación, se incrementa la comunicación 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 tenemos:

• 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.

Estas tareas se desarrollan en forma interactiva a partir de un abordaje progresivo del problema. Se espera que una especificación de requerimientos que fue aprobada por clientes y/o usuarios tenga al menos las siguientes características:

• Que contenga todos los requerimientos deseados.

• Que cada requerimiento solo tenga una interpretación posible (esto apunta a eliminar ambigüedades).

• Que el cumplimiento de cualquier requerimiento no provoque conflictos con el cumplimiento de otro requerimiento, es decir, que sea consistente.

• Que se definan prioridades.

4.-REQUERIMIENTOS PARA LA GESTION

La administración de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos.

La planeación comienza al mismo tiempo que la obtención de requerimientos.

La administración activa debe iniciar tan pronto esté lista la primera versión del documento de requerimientos.

El proceso de gestión de requerimientos implica tres tipos de tareas:

• Elicitación: Se trabaja estrechamente con los usuarios a fin de conocer la problemática en detalle. La esencia de esta etapa consiste en extraer el conocimiento relevante del problema.

• Especificación: Es el proceso de documentación del comportamiento deseado del sistema. Una especificación puede ser vista como un acuerdo entre usuarios y desarrolladores del software.

• Validación: Permite asegurar que las especificaciones reflejan correctamente las intenciones de clientes y usuarios.


13

Estas tareas se desarrollan en forma interactiva a partir de un abordaje progresivo del problema. Se espera que una especificación de requerimientos que fue aprobada por clientes y/o usuarios tenga al menos las siguientes características:

• Que contenga todos los requerimientos deseados. • Que cada requerimiento solo tenga una interpretación posible (esto apunta a

eliminar ambigüedades). • Que el cumplimiento de cualquier requerimiento no provoque conflictos con el

cumplimiento de otro requerimiento, es decir, que sea consistente. • Que se definan prioridades.

unidad i / procesos de la ingenieria de requerimientos · pdf filela ingeniería de...

Documents