UNIVERSIDAD TÉCNICA ESTATAL DE QUEVEDO MODALIDAD SEMI PRESENCIAL
MODULO DESARROLLO DE SISTEMAS E INGENIERIA DE SOFTWARE
TEMA: CONSULTA DE INGENIERIA DE REQUERIMIENTOS
AUTOR: JEFFERSON STALIN MACIAS DIAZ
TUTOR: ING. RICARDO AGUIRRE Quevedo – Los Ríos – Ecuador 2014
Introducción 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. 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. A través de los años se ha podido constatar que los requerimientos o requisitos son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeación, básicamente en lo que se refiere a las estimaciones de tiempos y costos, así como la definición de recursos necesarios y la elaboración de cronogramas que será uno de los principales mecanismos de control con los que se contará durante la etapa de desarrollo. Además la especificación de requerimientos es la base que permite verificar si se alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo detallado de las necesidades de los clientes o usuarios del sistema y es contra lo que se va a estar verificando si se están cumpliendo las metas trazadas.
Objetivos
Permitir gestionar las necesidades del proyecto en forma estructurada cada actividad.
Mejorar la capacidad de predecir cronogramas de proyectos, así como sus resultados.
Disminuir los costos y retrasos del proyecto.
Mejorar la calidad del software
Mejorar la comunicación entre equipos de trabajo.
Evitar rechazo de usuarios finales.
¿Qué son Requerimientos? Se presenta a continuación la definición existente en el glosario de la IEEE de lo que es un “Requerimiento”: 1. “Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo”. (Std 610.12-1900, IEEE: 62) 2. “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”.(Std 610.12-1900, IEEE: 62) También, Ian Sommerville presenta una definición acerca de lo que es un “Requerimiento”: 3. “Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste”. (Sommerville, 2005: 108) Importancia de la Ingeniería de requerimientos Según la autora Lizka Johany Herrera en su documento de la ingeniería de requerimientos, los principales beneficios que se obtienen de la Ingeniería de Requerimientos son (2003: 3):
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: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo.
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.).
Determinación de Requerimientos La determinación de requerimientos se realiza mediante las tareas siguientes: Definición del caso de estudio. Se identifica el tema central que motiva el inicio del estudio, pudiendo ser la creación de un nuevo sistema o la modificación a uno ya existente. Estudio de la organización. Se determina con precisión las áreas usuarias participantes, su estructura orgánica, funciones, interrelaciones y compromisos con otras. Análisis de procedimientos. Se estudian todos los procedimientos relacionados con el problema planteado, identificando para cada uno de ellos: los objetivos que persiguen, las actividades que realizan, secuencia y periodicidad, responsables, niveles de agregación, sus relaciones con otros puntos de control y situaciones especiales que imperan.
Análisis de información. Se identificaran los flujos de información, documentos y reportes, operaciones (de registro, validación, almacenamiento, clasificación, cálculo y presentación), volúmenes y períodos; que se desprenden de la ejecución de los procedimientos estudiados. Identificación de recursos. Se hace un reconocimiento de los recursos humanos y materiales participantes en el desarrollo de las actividades. Determinación de puntos críticos. Consiste en identificar claramente aquellos aspectos que entorpecen y limitan el buen funcionamiento de los procedimientos actuales, los problemas más comunes y relevantes que se presentan, los motivos que crean insatisfacción y aquellos que deben ser cubiertos a plenitud. Por ejemplo: ¿El contenido de los reportes generados, satisface realmente las necesidades del usuario? ¿Los tiempos de respuesta ofrecidos, son oportunos?, etc. Tipos de Requerimientos Pressman Requerimientos normales. Objetivos y metas que se establecen para un producto o sistema durante las reuniones con el cliente. Si estos requerimientos están presentes, el cliente queda satisfecho. Ejemplos de requerimientos normales son los tipos de gráficos pedidos para aparecer en la pantalla, funciones específicas del sistema y niveles de rendimiento definidos. Requerimientos esperados. Están implícitos en el producto o sistema y quizá sean tan importantes que el cliente no los mencione de manera explícita. Su ausencia causará mucha insatisfacción. Algunos ejemplos de requerimientos esperados son: fácil interacción humano/máquina, operación general correcta y confiable, y facilidad para instalar el software. Requerimientos emocionantes. Estas características van más allá de las expectativas del cliente y son muy satisfactorias si están presentes. Por ejemplo,
el software para un nuevo teléfono móvil viene con características estándar, pero si incluye capacidades inesperadas (como pantalla sensible al tacto, correo de voz visual, etc.) agrada a todos los usuarios del producto. Sommerville Requerimientos del producto Estos requerimientos especifican o restringen el comportamiento
del
software.
Los
ejemplos
incluyen
requerimientos
de
rendimiento sobre qué tan rápido se debe ejecutar el sistema y cuánta memoria requiere, requerimientos de fiabilidad que establecen la tasa aceptable de fallas, requerimientos de seguridad y requerimientos de usabilidad. Requerimientos de la organización Son requerimientos de sistemas amplios, derivados de políticas y procedimientos en la organización del cliente y del desarrollador. Los ejemplos incluyen requerimientos del proceso operacional que definen cómo se usará el sistema, requerimientos del proceso de desarrollo que especifican el lenguaje de programación, estándares del entorno o el proceso de desarrollo a utilizar, y requerimientos ambientales que definen el entorno de operación del sistema. Requerimientos externos Este término cubre todos los requerimientos derivados de factores externos al sistema y su proceso de desarrollo. En ellos se incluyen requerimientos regulatorios que establecen lo que debe hacer el sistema para ser aprobado en su uso por un regulador, como sería un banco central; requerimientos legislativos que tienen que seguirse para garantizar que el sistema opere conforme a la ley, y requerimientos éticos que garanticen que el sistema será aceptable para sus usuarios y el público en general. Características de un Requerimiento Es importante no perder de vista que un requerimiento debe ser: Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe si se cumplió con él o no? 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 lenguaje usado en su definición, no debe causar confusiones al lector. Dificultades para definir los requerimientos Durante la etapa de especificación de requerimientos se pueden presentar muchos inconvenientes los cuales son importantes de identificar y prevenir, a continuación se presenta un listado con los problemas más comunes en este proceso:
Los requerimientos no son obvios y vienen de muchas fuentes.
Son difíciles de expresar en palabras (el lenguaje es ambiguo).
La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
El usuario no puede explicar lo que hace
Tiende a recordar lo excepcional y olvidar lo rutinario
Hablan de lo que no funciona
Los usuarios tienen distinto vocabulario que los desarrolladores.
Ingeniería de requerimientos El proceso de recopilar, analizar y verificar las necesidades del cliente para un
sistema de software es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos es entregar una especificación de requerimientos de software correcta y completa. La ingeniería de requerimientos apunta a mejorar la forma en que comprendemos y definimos sistemas de software complejos. Existen varias definiciones de requerimientos, de entre las cuales podemos citar las siguientes: Los Requerimientos fueron definidos por la IEEE como [IEEE90]: 1. Condición o capacidad requerida por el usuario para resolver un problema o alcanzar un objetivo 2. Condición o capacidad que debe satisfacer o poseer un sistema o una componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto 3. Representación documentada de una condición o capacidad como en 1 o 2. Según Zave: • Rama de la ingeniería del software que trata con el establecimiento de los objetivos, funciones y restricciones de los sistemas software. • Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer especificaciones precisas. Según Boehm: • 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. Según Loucopoulos:
• Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y cooperativo de análisis del problema, documentando los resultados en una variedad de formatos y probando la exactitud del conocimiento adquirido. Actividades de la ingeniería de requerimientos Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice que dentro de la IR existen cuatro actividades básicas que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene para el desarrollo de un proyecto de software realizar una especificación y administración adecuada de los requerimientos de los clientes o usuarios. Las cuatro actividades son: extracción, análisis, especificación y validación, y serán explicadas a continuación cada una de ellas. Extracción Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Es importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuan bien éste satisfaga las necesidades del cliente. Análisis Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se
conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos. El modelo debe centrarse en los requerimientos que sean visibles dentro del problema o dentro del dominio del negocio. El nivel de abstracción debe ser relativamente elevado. “No se empantane en los detalles” [Arl02] que traten de explicar cómo funciona el sistema. • Cada elemento del modelo de requerimientos debe agregarse al entendimiento general de los requerimientos del software y dar una visión del dominio de la información, de la función y del comportamiento del sistema. • Hay que retrasar las consideraciones de la infraestructura y otros modelos no funcionales hasta llegar a la etapa del diseño. Es decir, quizá se requiera una base de datos, pero las clases necesarias para implementarla, las funciones requeridas para acceder a ella y el comportamiento que tendrá cuando se use sólo deben considerarse después de que se haya terminado el análisis del dominio del problema. Especificación La especificación de requerimientos es el proceso de escribir, en un documento de requerimientos, los requerimientos del usuario y del sistema. De manera ideal, los requerimientos del usuario y del sistema deben ser claros, sin ambigüedades, fáciles de entender, completos y consistentes. Esto en la práctica es difícil de lograr, pues los participantes interpretan los requerimientos de formas diferentes y con frecuencia en los requerimientos hay conflictos e inconsistencias inherentes. Los requerimientos del usuario para un sistema deben describir los requerimientos funcionales y no funcionales, de forma que sean comprensibles para los usuarios del sistema que no cuentan con un conocimiento técnico detallado. De manera ideal, deberían especificar sólo el comportamiento externo del sistema. El documento de requerimientos no debe incluir detalles de la arquitectura o el
diseño del sistema. En consecuencia, si usted escribe los requerimientos del usuario, no tiene que usar jerga de software, anotaciones estructuradas o formales. Debe escribir los requerimientos del usuario en lenguaje natural, con tablas y formas sencillas, así como diagramas intuitivos. Los requerimientos del sistema son versiones extendidas de los requerimientos del usuario que los ingenieros de software usan como punto de partida para el diseño del sistema. Añaden detalles y explican cómo el sistema debe brindar los requerimientos del usuario. Se pueden usar como parte del contrato para la implementación del sistema y, por lo tanto, deben ser una especificación completa y detallada de todo el sistema. Validación La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos Los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos. Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar
un
mantenimiento
adecuado
al
documento
de
especificación
de
requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de
recurrir a consultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso. Durante el proceso de validación de requerimientos, tienen que realizarse diferentes tipos de comprobaciones sobre los requerimientos contenidos en el documento de requerimientos. Dichas comprobaciones incluyen: 1. Comprobaciones de validez Un usuario quizá crea que necesita un sistema para realizar ciertas funciones. Sin embargo, con mayor consideración y análisis se logra identificar las funciones adicionales o diferentes que se requieran. Los sistemas tienen diversos participantes con diferentes necesidades, y cualquier conjunto de requerimientos es inevitablemente un compromiso a través de la comunidad de participantes. Comprobaciones de consistencia Los requerimientos en el documento no deben estar en conflicto. Esto es, no debe haber restricciones contradictorias o descripciones diferentes de la misma función del sistema. Comprobaciones de totalidad El documento de requerimientos debe incluir requerimientos que definan todas las funciones y las restricciones pretendidas por el usuario del sistema. Comprobaciones de realismo Al usar el conocimiento de la tecnología existente, los requerimientos deben comprobarse para garantizar que en realidad pueden implementarse. Dichas comprobaciones también tienen que considerar el presupuesto y la fecha para el desarrollo del sistema. Verificabilidad Para reducir el potencial de disputas entre cliente y contratista, los requerimientos del sistema deben escribirse siempre de manera que sean verificables.
Técnicas y herramientas utilizadas en la ingeniería de requerimientos La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio. Existen varias técnicas para la IR propuestas para ingeniería de requerimientos (Herrera, 2003: 12), y de las cuales en este artículo solo se abarcarán cinco de ellas. Es importante resaltar que estas técnicas pueden ser aplicables a las distintas fases del proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las características propias del proyecto en particular que se esté desarrollándose para aprovechar al máximo su utilidad. Entrevistas Las entrevistas formales o informales con participantes del sistema son una parte de la mayoría de los procesos de ingeniería de requerimientos. En estas entrevistas, el equipo de ingeniería de requerimientos formula preguntas a los participantes sobre el sistema que actualmente usan y el sistema que se va a desarrollar. Los requerimientos se derivan de las respuestas a dichas preguntas. Las entrevistas son de dos tipos: 1. Entrevistas cerradas, donde los participantes responden a un conjunto de preguntas preestablecidas.
2. Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo de ingeniería de requerimientos explora un rango de conflictos con los participantes del sistema y, como resultado, desarrolla una mejor comprensión de sus necesidades. En la práctica, las entrevistas con los participantes son por lo general una combinación de ambas. Quizá se deba obtener la respuesta a ciertas preguntas, pero eso a menudo conduce a otros temas que se discuten en una forma menos estructurada. Rara vez funcionan bien las discusiones completamente abiertas. Con frecuencia debe plantear algunas preguntas para comenzar y mantener la entrevista enfocada en el sistema que se va a desarrollar. Las entrevistas son valiosas para lograr una comprensión global sobre qué hacen los participantes, cómo pueden interactuar con el nuevo sistema y las dificultades que enfrentan con los sistemas actuales. A las personas les gusta hablar acerca de sus trabajos, así que por lo general están muy dispuestas a participar en entrevistas. Sin embargo, las entrevistas no son tan útiles para comprender los requerimientos desde el dominio de la aplicación. Por dos razones resulta difícil asimilar el conocimiento de dominio a través de entrevistas: 1. Todos los especialistas en la aplicación usan terminología y jerga que son específicos de un dominio. Es imposible que ellos discutan los requerimientos de dominio sin usar este tipo de lenguaje. Por lo general, usan la terminología en una forma precisa y sutil, que para los ingenieros de requerimientos es fácil de malinterpretar. 2. Cierto conocimiento del dominio es tan familiar a los participantes que encuentran difícil de explicarlo, o bien, creen que es tan fundamental que no vale la pena mencionarlo. Por ejemplo, para un bibliotecario no es necesario decir que todas las adquisiciones deben catalogarse antes de agregarlas al acervo. Sin embargo, esto quizá no sea obvio para el
entrevistador y, por lo tanto, es posible que no lo tome en cuenta en los requerimientos. Las entrevistas tampoco son una técnica efectiva para adquirir conocimiento sobre los requerimientos y las restricciones de la organización, porque existen relaciones sutiles de poder entre los diferentes miembros en la organización. Las estructuras publicadas de la organización rara vez coinciden con la realidad de la toma de decisiones en una organización, pero los entrevistados quizá no deseen revelar a un extraño la estructura real, sino la teórica. En general, la mayoría de las personas
se
muestran
renuentes
a
discutir
los
conflictos
políticos
y
organizacionales que afecten los requerimientos. Los entrevistadores efectivos poseen dos características: 1. Tienen mentalidad abierta, evitan ideas preconcebidas sobre los requerimientos y escuchan a los participantes. Si el participante aparece con requerimientos sorprendentes, entonces tienen disposición para cambiar su mentalidad acerca del sistema. 2. Instan al entrevistado con una pregunta de trampolín para continuar la plática, dar una propuesta de requerimientos o trabajar juntos en un sistema de prototipo. Cuando se pregunta al individuo “dime qué quieres” es improbable que alguien consiga información útil. Encuentran mucho más sencillo hablar en un contexto definido que en términos generales. La información de las entrevistas se complementa con otra información del sistema de documentación que describe los procesos empresariales o los sistemas existentes, las observaciones del usuario, etcétera. En ocasiones, además de los documentos del sistema, la información de la entrevista puede ser la única fuente de datos sobre los requerimientos del sistema. Sin embargo, la entrevista por sí misma está expuesta a perder información esencial y, por consiguiente, debe usarse junto con otras técnicas de adquisición de requerimientos.
Prepare su entrevista: •
Defina el objetivo.
•
Establezca los temas.
•
Elija la fuente: área administrativa, persona a entrevistar.
•
Seleccione documentos.
•
Planee su entrevista: procedimiento, vigor, tiempo y material.
Conduzca su entrevista: •
Explique los siguientes puntos: identificación personal, propósito de la entrevista, cuál es el proyecto y cuál será la contribución que hará al proyecto el entrevistado.
•
Asegurarse
de
entender
correctamente
las
actividades
y
responsabilidades del entrevistado. •
Si el entrevistado toma decisiones, es importante hacer un modelo representativo (que decisiones son hechas y como interviene él).
•
Hacer preguntas específicas (cuanto) (s).
•
Evitar tecnicismos.
•
Aprender a escuchar.
•
Evitar la divagación y la desviación.
•
Buscar opciones, ideas y sugerencias.
•
Tomar nota de puntos relevantes.
•
Evitar juicios sobre el valor o impresión de los datos recibidos.
Cuestionarios Por lo general, las personas encuentran más sencillo vincularse con ejemplos reales que con descripciones abstractas. Pueden comprender y criticar un escenario sobre cómo interactuar con un sistema de software. Los ingenieros de requerimientos usan la información obtenida de esta discusión para formular los verdaderos requerimientos del sistema.
Los escenarios son particularmente útiles para detallar un bosquejo de descripción de requerimientos. Se trata de ejemplos sobre descripciones de sesiones de interacción. Cada escenario abarca comúnmente una interacción o un número pequeño de interacciones posibles. Se desarrollan diferentes formas de escenarios y se ofrecen varios tipos de información con diversos niveles de detalle acerca del sistema. Las historias que se usan en programación extrema, estudiadas en el capítulo 3, son un tipo de escenario de requerimientos. Un escenario comienza con un bosquejo de la interacción. Durante el proceso de adquisición, se suman detalles a éste para crear una representación completa de dicha interacción. En su forma más general, un escenario puede incluir: 1. Una descripción de qué esperan el sistema y los usuarios cuando inicia el escenario. 2. Una descripción en el escenario del flujo normal de los eventos. 3. Una descripción de qué puede salir mal y cómo se manejaría. 4. Información de otras actividades que estén en marcha al mismo tiempo. 5. Una descripción del estado del sistema cuando termina el escenario. Sistemas existentes Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de información que se maneja y cómo es manejada, por otro lado también es útil analizar las distintas salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas. Lluvia de ideas (Brainstorm) Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No
hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", impracticable","imposible", etc. Las reglas básicas a seguir son: Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas. Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque si no se crea un ambiente hostil que no alienta la generación de ideas. Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil. A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva. Escribir las ideas sin censura. Etnografía Los sistemas de software no existen aislados. Se usan en un contexto social y organizacional, y dicho escenario podría derivar o restringir los requerimientos del sistema de software. A menudo satisfacer dichos requerimientos sociales y organizacionales es crítico para el éxito del sistema. Una razón por la que muchos sistemas de software se entregan, y nunca se utilizan, es que sus requerimientos no consideran de manera adecuada cómo afectaría el contexto social y organizacional la operación práctica del sistema.
La etnografía es una técnica de observación que se usa para entender los procesos operacionales y ayudar a derivar requerimientos de apoyo para dichos procesos. Un analista se adentra en el ambiente laboral donde se usará el sistema. Observa el trabajo diario y toma notas acerca de las tareas existentes en que intervienen los participantes. El valor de la etnografía es que ayuda a descubrir requerimientos implícitos del sistema que reflejan las formas actuales en que trabaja la gente, en vez de los procesos formales definidos por la organización. Las personas con frecuencia encuentran muy difícil articular los detalles de su trabajo, porque es una segunda forma de vida para ellas. Entienden su trabajo, pero tal vez no su relación con otras funciones en la organización. Los factores sociales y organizacionales que afectan el trabajo, que no son evidentes para los individuos, sólo se vuelven claros cuando los percibe un observador sin prejuicios. Por ejemplo, un grupo de trabajo puede organizarse de modo que sus miembros conozcan el trabajo de los demás y se suplan entre sí cuando alguien se ausenta. Es probable que esto no se mencione durante una entrevista, pues el grupo podría no verlo como una parte integral de su función. Suchman (1987) fue una de las primeras en usar la etnografía para estudiar el trabajo en la oficina. Ella descubrió que las prácticas reales del trabajo son más ricas, más complejas y más dinámicas que los modelos simples supuestos por los sistemas de automatización administrativa. La diferencia entre el trabajo supuesto y el real fue la razón más importante por la que dichos sistemas de oficina no tenían un efecto significativo sobre la productividad. Prototipos Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no estén demasiado claros o que no se esté muy seguro de haber entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final.
Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva. El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo. Casos de Uso El modelado de casos de uso fue desarrollado originalmente por Jacobson y sus colaboradores (1993) en la década de 1990, y se incorporó en el primer lanzamiento del UML (Rumbaugh et al., 1999). Como se estudió en el capítulo 4, el modelado de casos de uso se utiliza ampliamente para apoyar la adquisición de requerimientos. Un caso de uso puede tomarse como un simple escenario que describa lo que espera el usuario de un sistema. Cada caso de uso representa una tarea discreta que implica interacción externa con un sistema. En su forma más simple, un caso de uso se muestra como una elipse, con los actores que intervienen en el caso de uso representados como figuras humanas Los diagramas de caso de uso brindan un panorama bastante sencillo de una interacción, de modo que usted tiene que ofrecer más detalle para entender lo que está implicado. Este detalle puede ser una simple descripción textual, o una descripción estructurada en una tabla o un diagrama de secuencia, como se discute a
continuación. Es posible elegir el formato más adecuado, dependiendo del caso de uso y del nivel de detalle que usted considere se requiera en el modelo. Para el autor, el formato más útil es un formato tabular estándar. Los casos de uso son una técnica para especificar el comportamiento de un sistema. El sitio en Internet wikipedia.org, define a un caso de uso como: “Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas” Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. La mayoría de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. Según el autor Sommerville, los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos. Actualmente, se han convertido en una característica fundamental de la notación UML (Lenguaje de modelado unificado), que se utiliza para describir modelos de sistemas orientados a objetos. Herramientas automatizadas para la Administración de Requerimientos En el desarrollo de software se cuenta con una ventaja proporcionada por las herramientas CASE. Las herramientas CASE (Ingeniería del Software Asistida por Computadora) se le conoce a todo aquel software que es usado para ayudar a las actividades del proceso de desarrollo del software, en donde se ubica la ingeniería de requerimientos, que se ha venido tratando en este artículo. Estas herramientas se concentran en capturar requerimientos, administrarlos y producir una especificación de requisitos.
Existen muchas y muy variadas herramientas CASE que pueden ser utilizadas por los desarrolladores de software en sus proyectos, y de la forma más conveniente para ellos. Si es importante hacer ver que estas herramientas fungen como un medio facilitador para agilizar y mejorar los procesos involucrados en todo el ciclo de vida presentado por la IR, y que en conjunto ayudan a la construcción final de un producto de software terminado. Estas herramientas permiten entre otras cosas tener un mayor control en proyectos complejos, reducir costos y retrasos en los proyectos, ayudan a determinar la complejidad y los esfuerzos necesarios. En este apartado se presentan características generales de una de las herramientas más utilizadas para este propósito: ³RequisitePro´, y recomendada sitio en Internet Rational.com. RequisitePro RequisitePro es la herramienta que ofrece Rational Software para tener un mayor control sobre los requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos de usuario que surjan durante el ciclo de vida del proyecto. En RequisitePro los requerimientos se encuentran documentados bajo un esquema organizado de documentos; estos esquemas cumplen completamente con los estándares requeridos por algunas de las instituciones a nivel mundial más reconocidas en el desarrollo de software, tales como: IEEE (Instituto de Ingenieros Eléctricos y Electrónicos), ISO, CMM (Modelo de Capacidad de Madurez) y por el RUP (Proceso Unificado Racional) Esta herramienta se integra con aplicaciones para la administración de cambios, herramientas de modelado de sistemas y con herramientas de pruebas. Esta integración asegura que los diseñadores conocen los requerimientos del usuario, del sistema y del software en el momento de su desarrollo.
El desarrollo de software es una tarea de equipo, de tal forma, es crítico que todos los miembros del equipo posean un entendimiento compartido de la visión de sus proyectos, metas, especificaciones y requerimientos; pero, ¿cómo puede conseguirse cuando los equipos se encuentran geográficamente distribuidos y funcionalmente aislados, no pudiendo comunicarse entre sí en tiempo y forma? La solución a esta necesidad es IBM Rational RequisitePro. IBM Rational RequisitePro es una solución fácil de usar, es una herramienta de administración de requerimientos que le permite al equipo crear y compartir sus requerimientos utilizando métodos familiares basados en documentos potenciados por la aplicación de las capacidades de una base de datos, tales como la trazabilidad y análisis de impacto. El resultado es una mejor comunicación y administración de requerimientos con una mayor probabilidad de completar los proyectos en tiempo, dentro del presupuesto y superando las expectativas. Los proyectos exitosos comienzan con una buena administración de requerimientos, cuanto más efectiva sea su ejecución, mayor será el resultado en calidad y satisfacción del cliente. Según la promoción hecha en Internet mediante la página Web para esta herramienta, algunas de sus ventajas son:
Un producto potente y fácil de utilizar para la gestión de requisitos y casos de uso que propicia una mejor comunicación, mejoras en el trabajo en equipo y reduce el riesgo de los proyectos.
Combina la interfaz conocida y fácil de utilizar de los documentos de Microsoft Word con potentes funciones de base de datos para conseguir la máxima eficacia en análisis y consulta de requisitos.
Proporciona a los equipos la posibilidad de comprender el impacto de los cambios.
Garantiza que todos los componentes del equipo estarán informados de los requisitos más actuales para asegurar la coherencia.
Proporciona acceso basado en Web para los equipos distribuidos.
La ventaja de utilizar herramientas como la de RequisitePro, es que el desarrollo de software se ve beneficiado de muchas maneras, y en el caso de la ingeniería de requerimientos, le ayuda notablemente, ya que como se ha venido hablando en el desarrollo de este artículo, la IR constituye una de las etapas más importantes a tomar en cuenta en el ciclo de desarrollo de software, ya que en ella se definen los requerimientos con los que debe de contar el software; e incluso, podría llegar a determinar la viabilidad de implementar ese software no es del todo posible, y poder cancelar a tiempo un desarrollo no productivo.
Linkcografia http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/415/1/Ingenieria% 20de%20requerimientos.pdf http://latindex.ucr.ac.cr/index.php/intersedes/article/viewFile/790/851 http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4 http://www.monografias.com/trabajos6/resof/resof.shtml#ixzz367g9u3Ng http://unidad2requerimientos.blogspot.com/2013/03/ingenieria-derequerimientos.html (http://es.wikipedia.org/wiki/Caso_de_uso).
Bibliografía Autor: Roger S. Pressman Ingeniería del software: Un enfoque práctico séptima edición Autor: Alejandro Peña Ayala Ingeniería de Software: Una Guía para Crear Sistemas de Información Autor: Ian Sommerville Ingeniería de Software 9 Autor: Roger S. Pressman Ingeniería del software: Un enfoque práctico quinta edición