1

Tabla de contenido
Tabla de contenido.............................................................................................................2 Qu es un requerimiento?................................................................................................3 Tipos de Requerimientos...............................................................................................3 Caractersticas de un Requerimiento.............................................................................3 Dificultades para definir los requerimientos.................................................................4 Ingeniera de requerimientos.............................................................................................4 Importancia de la ingeniera de requerimientos............................................................4 Actividades de la ingeniera de requerimientos.............................................................5 Extraccin (Anlisis del problema)...........................................................................5 Anlisis (Evaluacin y negociacin de los requerimientos)......................................5 Especificacin............................................................................................................5 Validacin..................................................................................................................6 Evolucin de los requerimientos...............................................................................6 Tcnicas y herramientas utilizadas en la ingeniera de requerimientos.........................7 Tcnicas utilizadas en las actividades de IR..............................................................7 Entrevistas y Cuestionarios...................................................................................7 Sistemas existentes................................................................................................7 Lluvia de ideas (Brainstorm).................................................................................7 Prototipos...............................................................................................................7 Casos de Uso.........................................................................................................8 Herramientas automatizadas para la Administracin de Requerimientos.................8 RequisitePro...........................................................................................................8 Descripcin de las tcnicas ms utilizadas en la ingeniera de requerimientos.............9 Entrevistas y Cuestionarios. .....................................................................................9 Lluvia de Ideas (Brainstorm). ................................................................................11 Encuestas.................................................................................................................13 Observacin.............................................................................................................13 Prototipos. ..............................................................................................................14 Sesiones JAD (Desarrollo participativo de aplicaciones)........................................15 Proceso de Anlisis Jerrquico (AHP)....................................................................19 Ventajas y desventajas de cada una de las tcnicas utilizadas en las etapas de la Ingeniera de Requerimientos......................................................................................19 Resumen .........................................................................................................................21

En esta unidad se tiene como objeto establecer los conceptos y fundamentos involucrados en la Ingeniera de Requerimientos donde el alumno entender: Qu es un requerimiento?; Tipos de Requerimientos; Qu es la Ingeniera de Requerimientos?, su importancia; sus actividades, sus tcnicas y herramientas.

Qu es un requerimiento?
Un requerimiento puede definirse como un atributo necesario dentro de un sistema, que puede representar una capacidad, una caracterstica 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 satisfaccin 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 segn el significado y otros aspectos segn se considere. A continuacin se presenta la definicin existente en el glosario de la IEEE de lo que es un Requerimiento: 1. Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (Std 610.12-1900, IEEE: 62) 2. Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (Std 610.12-1900, IEEE: 62) Tambin, Ian Sommerville presenta una definicin acerca de lo que es un Requerimiento: 3. Un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste. (Sommerville, 2005: 108) Analizando las definiciones anteriores, un requerimiento es una descripcin de una condicin o capacidad que debe cumplir un sistema, ya sea derivada de una necesidad de usuario identificada, o bien, estipulada en un contrato, estndar, especificacin u otro documento formalmente impuesto al inicio del proceso.

Tipos de Requerimientos
Los requerimientos de software pueden dividirse en 2 categoras: requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales son los que definen las funciones que el sistema ser capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el Qu? y no el Cmo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema. Por otra parte los requerimientos no funcionales tienen que ver con caractersticas 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, estndares, auditabilidad y otros.

Caractersticas 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 cmo se sabe si se cumpli con l o no? 3

Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin 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 redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector

Dificultades para definir los requerimientos

Durante la etapa de especificacin de requerimientos se pueden presentar muchos inconvenientes los cuales son importantes de identificar y prevenir, a continuacin se presenta un listado con los problemas ms comunes en este proceso: Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). La cantidad de requerimientos en un proyecto puede ser difcil 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 Usan el mismo trmino con distinto significado

Ingeniera de requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniera de requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. Algunos otros conceptos de ingeniera de requerimientos son: Ingeniera de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas que conducen a comprender cul ser el impacto del software sobre el negocio, qu es lo que el cliente quiere y cmo interactuarn los usuarios finales con el software. (Pressman, 2006: 155) La ingeniera de requerimientos es el proceso de desarrollar una especificacin de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. (Sommerville, 2005: 82) En sntesis, el proceso de ingeniera de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentacin y mantenimiento de los requerimientos para un producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendr a ayudar a determinar la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtencin y anlisis de requerimientos, su especificacin formal, para finalizar con el subproceso de validacin donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.

Importancia de la ingeniera de requerimientos

Segn la autora Lizka Johany Herrera en su documento de la ingeniera de requerimientos, los principales beneficios que se obtienen de la Ingeniera 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 estimacin 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, desempeo, y otros) Mejora la comunicacin entre equipos: La especificacin 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 ingeniera 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.

Actividades de la ingeniera de requerimientos

Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice que dentro de la IR existen cuatro actividades bsicas 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 especificacin y administracin adecuada de los requerimientos de los clientes o usuarios. Las cinco actividades son: extraccin, anlisis, especificacin, validacin y evolucion, y sern explicadas a continuacin cada una de ellas. Extraccin (Anlisis del problema) Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre comnmente 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 y otros. Es importante, que la extraccin sea efectiva, ya que la aceptacin del sistema depender de cun bien ste satisfaga las necesidades del cliente. Anlisis (Evaluacin y negociacin de los requerimientos) Sobre la base de la extraccin 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 anlisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptan, 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 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, se puede decir que la especificacin es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin, como la notacin UML (Lenguaje de Modelado Unificado), que es un estndar para el modelado orientado a objetos, por lo que los casos de uso y la obtencin de requerimientos basada en casos de uso se utiliza cada vez ms para la obtencin de requerimientos

Validacin La validacin 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 descripcin, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estn completos. Se puede apreciar que el proceso de ingeniera 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 especificacin de requerimientos, que es el documento final, de carcter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso nico que sea vlido de aplicar en todas las organizaciones. Cada organizacin 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 ingeniera de requerimientos. Hay muchas maneras de organizar el proceso de ingeniera de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva ms objetiva que las personas involucradas en el proceso. Evolucin de los requerimientos Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cmo los objetivos de la organizacin pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolucin es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las ms frecuentes son: Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. Porque cambi el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambi el ambiente de negocios. Porque cambi el mercado en el cual se desenvuelve el negocio. Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una caracterstica en particular, modificacin que a la vez puede tener impacto en otros requerimientos. Por esto, la administracin de cambios involucra actividades como establecer polticas, guardar histricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones. Tener versiones de los requerimientos es tan importante como tener versiones del cdigo, ya que evita tener requerimientos emparchados (Se le llama requerimiento emparchado a aqul que ha sufrido cambios excesivos en la semntica) en un proyecto Entre algunos de los beneficios que proporciona el control de versiones estn: Prevenir cambios no autorizados. Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de releases. Prevenir la modificacin simultnea a los requisitos.

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.

Tcnicas y herramientas utilizadas en la ingeniera de requerimientos

Tcnicas utilizadas en las actividades de IR Existen varias tcnicas para la IR propuestas para ingeniera de requerimientos (Herrera, 2003: 12), y de las cuales solo se abarcarn cinco de ellas. Es importante resaltar que estas tcnicas pueden ser aplicables a las distintas fases del proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las caractersticas propias del proyecto en particular que se est desarrollndose para aprovechar al mximo su utilidad. Entrevistas y Cuestionarios Las 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 de sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que sern afectados por l. El xito de esta tcnica, depende de la habilidad del entrevistador y de su preparacin para la misma. Sistemas existentes Esta tcnica consiste en analizar distintos sistemas ya desarrollados que estn relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de informacin que se maneja y cmo es manejada, por otro lado tambin es til analizar las distintas salidas que los sistemas producen (listados, consultas, y otros.), 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 intencin en su aplicacin es la de generar la mxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intencin de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irn eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", y otros. Las reglas bsicas a seguir son:

Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtencin de una cantidad mayor de ideas creativas. Conviene suspender el juicio crtico y se debe permitir la evolucin de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generacin de ideas. Por ms 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.

Prototipos Durante la actividad de extraccin de requerimientos, puede ocurrir que algunos requerimientos no estn 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, permitindonos conseguir una importante retroalimentacin en cuanto a si el sistema diseado 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 renen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y sealan reas en las que ser necesaria la profundizacin en las definiciones. Luego de esto, tiene lugar un diseo 7

rpido. El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseo rpido lleva a la construccin de un prototipo. Casos de Uso Los casos de uso son una tcnica 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 interaccin con los usuarios y/o otros sistemas (http://es.wikipedia.org/wiki/Caso_de_uso). Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o ms actores, en respuesta a un estmulo inicial proveniente de un actor, es una descripcin de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. La mayora de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. Segn el autor Sommerville, los casos de uso son una tcnica que se basa en escenarios para la obtencin de requerimientos. Actualmente, se han convertido en una caracterstica fundamental de la notacin UML (Lenguaje de modelado unificado), que se utiliza para describir modelos de sistemas orientados a objetos. Herramientas automatizadas para la Administracin de Requerimientos En el desarrollo de software se cuenta con una ventaja proporcionada por las herramientas CASE. Las herramientas CASE (Ingeniera 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 ingeniera de requerimientos, que se ha venido tratando en este artculo. Estas herramientas se concentran en capturar requerimientos, administrarlos y producir una especificacin 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 ms 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 construccin 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 caractersticas generales de una de las herramientas ms utilizadas para este propsito: 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 tcnicos 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 estndares requeridos por algunas de las instituciones a nivel mundial ms reconocidas en el desarrollo de software, tales como: IEEE (Instituto de Ingenieros Elctricos y Electrnicos), ISO, CMM (Modelo de Capacidad de Madurez) y por el RUP (Proceso Unificado Racional) Esta herramienta se integra con aplicaciones para la administracin de cambios, herramientas de modelado de sistemas y con herramientas de pruebas. Esta integracin asegura que los diseadores 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 crtico que todos los miembros del equipo posean un entendimiento compartido de la visin de sus proyectos, metas, especificaciones y requerimientos; pero, cmo puede conseguirse cuando los equipos se encuentran geogrficamente distribuidos y funcionalmente aislados, no pudiendo comunicarse 8

entre si en tiempo y forma? La solucin a esta necesidad es IBM Rational RequisitePro. IBM Rational RequisitePro es una solucin fcil de usar, es una herramienta de administracin de requerimientos que le permite al equipo crear y compartir sus requerimientos utilizando mtodos familiares basados en documentos potenciados por la aplicacin de las capacidades de una base de datos, tales como la trazabilidad y anlisis de impacto. El resultado es una mejor comunicacin y administracin 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 administracin de requerimientos, cuanto ms efectiva sea su ejecucin, mayor ser el resultado en calidad y satisfaccin del cliente. Segn la promocin hecha en Internet mediante la pgina Web para esta herramienta, algunas de sus ventajas son:

Un producto potente y fcil de utilizar para la gestin de requisitos y casos de uso que propicia una mejor comunicacin, mejoras en el trabajo en equipo y reduce el riesgo de los proyectos. Combina la interfaz conocida y fcil de utilizar de los documentos de Microsoft Word con potentes funciones de base de datos para conseguir la mxima eficacia en anlisis y consulta de requisitos. Proporciona a los equipos la posibilidad de comprender el impacto de los cambios. Garantiza que todos los componentes del equipo estarn informados de los requisitos ms 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 ingeniera de requerimientos, le ayuda notablemente, ya que como se ha venido hablando en el desarrollo de este artculo, la IR constituye una de las etapas ms 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, podra llegar a determinar la viabilidad de implementar ese software no es del todo posible, y poder cancelar a tiempo un desarrollo no productivo

Descripcin de las tcnicas ms utilizadas en la ingeniera de requerimientos.

En esta seccin se van a describir en detalle algunas de las tcnicas ms usadas en la IR. Cada tcnica puede aplicarse en una o ms actividades de esta ingeniera; en la prctica, la tcnica ms apropiada para cada actividad depender del proyecto que est desarrollndose. Entrevistas y Cuestionarios. Dentro de una organizacin, la entrevista es la tcnica ms significativa y productiva de que dispone el analista para recolectar datos. En otras palabras, la entrevista es un intercambio de informacin que se efecta cara a cara. Es un canal de comunicacin entre el analista y la organizacin; sirve para obtener informacin acerca de las necesidades y la manera de satisfacerlas, as como consejo y comprensin por parte del usuario para toda idea o mtodo nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpata con el personal usuario, lo cual es fundamental en transcurso del estudio. A. Preparacin de la Entrevista. Determinar la posicin en la organizacin del futuro entrevistado, responsabilidades, actividades, y otros (Investigacin). Preparar las preguntas que van a plantearse, y los documentos necesarios (Organizacin). Fijar un lmite de tiempo y preparar la agenda para la entrevista. (Psicologa). Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad (Psicologa). Hacer la cita con la debida anticipacin (Planeacin). B. Conduccin de la Entrevista. 9

Explicar con toda amplitud el propsito y alcance del estudio (Honestidad). Explicar la funcin propietaria como analista y la funcin que se espera conferir al entrevistado. (Imparcialidad). Hacer preguntas especficas para obtener respuestas cuantitativas (Hechos). Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares (Habilidad). Evitar el cuchicheo y las frases carentes de sentido (Claridad). Ser corts, abstenindose de emitir juicios de valores. (Objetividad). Conservar el control de la entrevista, evitando divagaciones y los comentarios al margen de la cuestin (Habilidad). Escuchar atentamente lo que se dice, guardndose de anticiparse a las respuestas (Comunicacin). C. Secuela de la Entrevista. Escribir los resultados (Documentacin). Entregar una copia al entrevistado, solicitando su conformacin, correcciones o adiciones. (Profesionalismo). Archivar los resultados de la entrevista para referencia y anlisis posteriores (Documentacin). D. Recolectar datos mediante la Entrevista. La entrevista es una forma de conversacin, no de interrogacin, al analizar las caractersticas de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no estn disponibles en ningn otra forma. En las investigaciones de sistema, las formas cualitativas y cuantitativas de la informacin son importantes. La informacin cualitativa est relacionada con opinin, poltica y descripciones narrativas de actividades o problemas, mientras que las descripciones cuantitativas tratan con nmeros frecuencia, o cantidades. A menudo las entrevistas pueden ser la mejor fuente de informacin cualitativa, los otros mtodos tiende a ser ms tiles en la recoleccin de datos cuantitativos. Son valiosas las opiniones, comentarios, ideas o sugerencia en relacin a cmo se podra hacer el trabajo; la entrevista a veces es la mejor forma para conocer las actividades de las empresas. La entrevista puede descubrir rpidamente malos entendidos, falsa expectativa o incluso resistencia potencial para las aplicaciones de desarrollo; ms an, a menudo es ms fcil calendarizar una entrevista con los gerentes de alto nivel, que pedirle que llenen un cuestionario. E. Determinacin del tipo de Entrevista. La estructura de la entrevista vara. Si el objetivo de la entrevista radica en adquirir informacin general, es conveniente elaborar una serie de preguntas sin estructura, con una sesin de preguntas y respuestas libres. El formato de respuestas para las preguntas pueden ser abierto o cerrado; las preguntas abiertas permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Pueden contestar por completo con sus propias palabras. Los analistas tambin deben dividir el tiempo entre desarrollar preguntas para entrevistas y analizar respuestas. 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, y otros. El siguiente ejemplo muestra algunos tipos de preguntas abiertas.
Del Usuario Quin es el cliente? Quin es el usuario? Son sus necesidades diferentes? Cules son sus habilidades, capacidades, ambiente? 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? Qu problemas podra causar este producto en el negocio? En qu ambiente se usar el producto?

Del Proceso

Del Producto

10

Cules son sus expectativas para los conceptos rendimiento? Qu obstculos afectan la eficiencia del sistema?

fcil

de

usar,

confiable,

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

Ejemplos de las preguntas abiertas y cerradas en la entrevista estructurada.

FORMA DE PREGUNTA ABIERTA FORMA DE PREGUNTA CERRADA Ejemplo: obtener la informacin sobre las Ejemplo: obtener la informacin sobre las caractersticas de diseo crticas para los caractersticas de diseo crticas para los empleados. empleados. "Algunos empleados han sugerido que la " La experiencia le ha proporcionado una mejor forma para hacer eficiente el amplia visin en cuanto a la forma en la que la procesamiento de pedidos es instalar un empresa maneja los pedidos..." sistema de computadora que maneje todos los clculos..." Me gustara que usted contestara algunas Bajo estas circunstancias apoyara usted el preguntas especficas en relacin en lo anterior: desarrollo de un sistema de este tipo? -Qu etapas trabajan bien? Cules no? -En donde se presenta la mayor parte del problema? - Cundo ocurre un atraso, cmo se maneja? G. Seleccin de Entrevistados. Realizar entrevistas toma tiempo; por lo tanto no es posible utilizar este mtodo para recopilar toda la informacin que se necesite en la investigacin. La entrevista se aplica en los niveles gerenciales y de empleados que puedan proporcionar la mayor parte de la informacin til para el estudio los analistas.
H.

Realizacin de Entrevista.

La habilidad del entrevistador es vital para el xito en la bsqueda de hecho por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparacin del objetivo de una entrevista especfica como de las preguntas por realizar a una persona determinada. El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de xito. A travs de la entrevista, los analistas deben aplicarse a s mismos las siguientes preguntas: Qu es lo que me est diciendo la persona? Por qu me lo est diciendo a m? Qu est olvidando? Qu espera esta persona que haga yo? 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 11

creatividad. 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. Principios de la lluvia de ideas. Aplazar el juicio y no realizar crticas, hasta que no agoten las ideas, ya que actuara como un inhibidor. Se ha de crear una atmsfera de trabajo en la que nadie se sienta amenazado. Cuantas ms ideas se sugieren, mejores resultados se conseguirn: "la cantidad produce la calidad". Las mejores ideas aparecen tarde en el periodo de produccin de ideas, ser ms fcil que encontremos las soluciones y tendremos ms variedad sobre la que elegir. La produccin de ideas en grupos puede ser ms efectiva que la individual. Tampoco debemos olvidar que durante las sesiones, las ideas de una persona, sern asociadas de manera distinta por cada miembro, y har que aparezcan otras por contacto. El equipo en una lluvia de ideas debe estar formado por:

El Director: es la figura principal y el encargado de dirigir la sesin. Debe ser un experto en pensamiento creador. Su funcin es formular claramente el problema y que todos se familiaricen con l. Cuando lo haga, debe estimular ideas y hacer que se rompa el hielo en el grupo. Es el encargado de que se cumplan las normas, no permitiendo las crticas. Debe permanecer callado e intervenir cuando se corte la afluencia de ideas, por lo que le ser til llevar ya un listado de ideas. Debe hacer que todos participen y den ideas. Adems, es la persona que concede la palabra y da por finalizada la sesin. Posteriormente, clasificar las ideas de la lista que le proporciona el secretario. El secretario: registra por escrito las ideas segn van surgiendo. Las enumera, las reproduce fielmente, las redacta y se asegura que todos estn de acuerdo con lo escrito. Por ltimo realizar una lista de ideas. Los participantes: pueden ser habituales o invitados; cualquier involucrado en el proyecto entra en esta categora. Su funcin es producir ideas. Conviene que entre ellos no haya diferencias jerrquicas.

Las personas que componen el grupo deben estar motivadas para solucionar el problema, y con un ambiente que propicie la participacin de todos. Todos pueden sentirse confiados y con la sensacin de que pueden hablar sin que se produzcan crticas. Todas las ideas en principio deben tener el mismo valor, pues cualquiera de ellas puede ser la clave para la solucin. Es necesario prestar mucha atencin a las frases que pueden coartar la produccin de ideas. Adems durante la celebracin no deben asistir espectadores. Debemos evitar todos los bloqueos que paralizan la ideacin: como son nuestros hbitos o ideas preconcebidas, el desnimo o falta de confianza en si mismo, el temor y la timidez. Las fases de aplicacin en el Brainstorm son:

Descubrir hechos. Al menos con un da de antelacin, el director comunica por escrito a los miembros del grupo sobre los temas a tratar. El director explica los principios de la Tormenta de ideas e insiste en la importancia de tenerlos en cuenta. La sesin comienza con una ambientacin de unos 10 minutos, tratando un tema sencillo y no comprometido. Es una fase especialmente importante para los miembros sin experiencia. Se determina el problema, delimitndolo, precisndolo y clarificndolo. A continuacin se plantea el problema, recogiendo las experiencias que se poseen o consultando documentacin. Cuando es complejo, conviene dividirlo en partes. Aqu es importante la utilizacin del anlisis, desmenuzando el problema en pequeas partes para conectar lo nuevo y lo desconocido. Producir ideas (es la fase de tormenta de ideas propiamente dicha). Se van aplicando alternativas. Se busca producir una gran cantidad de ideas, aplicando los principios que hemos visto. Adems, es til cuando se ha trabajado mucho, alejarse del problema, pues 12

es un buen momento para que se produzcan asociaciones. Muchas de las nuevas ideas sern ideas antiguas, mejoradas o combinadas con varias ya conocidas. Al final de la reunin, el director da las gracias a los asistentes y les ruega que no abandonen el problema, ya que al da siguiente se le pedir una lista de ideas que les puedan haber surgido. Se incorporan las ideas surgidas despus de la reunin.

Descubrir soluciones. Se elabora una lista definitiva de ideas, para seleccionar las ms interesantes. La seleccin se realiza desechando las ideas que no tienen valor y se estudia si son vlidas las que se consideran interesantes. Lo mejor es establecer una lista de criterios de conveniencia para cada idea. Se seleccionan las ideas ms tiles y si es necesario se ponderarn. Pueden realizarlo los mismos miembros del grupo o crear otros para esta tarea; la clasificacin debe hacerse por categoras (tarea que corresponde al director). Se presentan las ideas de forma atractiva, haciendo uso de soportes visuales.

Encuestas. Hoy en da la palabra "encuesta" se usa ms frecuentemente para describir un mtodo de obtener informacin de una muestra de individuos. Esta "muestra" es usualmente slo una fraccin de la poblacin bajo estudio. An as, todas las encuestas tienen algunas caractersticas en comn. A diferencia de un censo, donde se estudia a todos los miembros de la poblacin, las encuestas recogen informacin de una porcin de la poblacin de inters. En una encuesta de buena fe, la muestra no es seleccionada caprichosamente o slo de personas que se ofrecen como voluntarios para participar. La muestra es seleccionada cientficamente de manera que cada persona en la poblacin tenga una oportunidad medible de ser seleccionada. De esta manera los resultados pueden ser proyectados con seguridad de la muestra a la poblacin mayor. La informacin es recogida usando procedimientos estandarizados de manera que a cada individuo se le hacen las mismas preguntas ms o menos de la misma manera. La intencin de la encuesta no es describir los individuos particulares quienes, por azar, son parte de la muestra sino obtener un perfil compuesto de la poblacin. El estndar de la industria para todas las organizaciones respetables que hacen encuestas es que los participantes individuales nunca puedan ser identificados al reportar los hallazgos. Todos los resultados de la encuesta deben presentarse en resmenes completamente annimos, tal como tablas y grficas estadsticas. Tamao de la muestra. Muchas veces depende de los recursos profesionales y fiscales disponibles. Los analistas frecuentemente encuentran que una muestra de tamao moderado es suficiente estadstica y operacionalmente. Las encuestas pueden ser clasificadas por su mtodo de recoleccin de datos. Las encuestas por correo, telefnicas y entrevistas en persona son las ms comunes. En los mtodos ms nuevos de recoger datos, la informacin se introduce directamente a la computadora ya sea por un entrevistador adiestrado o an por la misma persona entrevistada. Las entrevistas en persona en el hogar u oficina de un participante son mucho ms caras que las encuestas telefnicas o por correo. Estas pueden ser necesarias especialmente cuando se debe recoger informacin compleja. Preocupaciones potenciales. La calidad de una encuesta es determinada en gran medida por su propsito y por la forma en que es conducida. Las encuestas deben llevarse a cabo nicamente para obtener informacin estadstica sobre algn tema. No deben ser diseadas para producir resultados predeterminados o como un artificio para mercadeo o para actividades similares. Cualquier persona a quien se le solicite que responda a una encuesta de opinin o que se preocupe por los resultados debe primero decidir si las preguntas que se hacen son justas. Observacin. Otra tcnica til para el analista en su progreso de investigacin, consiste en observar a las personas cuando efectan su trabajo. Como tcnica de investigacin, la observacin tiene amplia aceptacin cientfica. Los socilogos, siclogos e ingenieros industriales utilizan extensamente sta tcnica con el fin de estudiar a las personas en sus actividades de grupo y como miembros de la organizacin. El propsito de la organizacin es mltiple: permite al analista determinar que se est haciendo, como se est haciendo, quien lo hace, cuando se 13

lleva a cabo, cuanto tiempo toma, dnde se hace y por que se hace. Observar las operaciones le proporciona el analista hechos que no podra obtener de otra forma. Tipos de Observacin. El analista de sistemas puede observar de tres maneras bsicas. Primero, puede observar a una persona o actitud sin que el observado se d cuenta y su interaccin por aparte del propio analista. Quiz esta alternativa tenga poca importancia para el anlisis de sistemas, puesto que resulta casi imposible reunir las condiciones necesarias. Segundo, el analista puede observar una operacin sin intervenir para nada, pero estando la persona observada enteramente consciente de la observacin. Por ltimo, puede observar y a la vez estar en contacto con las personas observadas. La interaccin puede consistir simplemente en preguntar respecto a una tarea especfica, pedir una explicacin, etc. Preparacin para la observacin Determinar y definir aquella que va a observarse. Estimar el tiempo necesario de observacin. Obtener la autorizacin de la gerencia para llevar a cabo la observacin. Explicar a las personas que van a ser observadas lo que se va a hacer y las razones para ello.

Conduccin de la observacin Familiarizarse con los componentes fsicos del rea inmediata de observacin. Mientras se observa, medir el tiempo en forma peridica. Anotar lo que se observa lo ms especficamente posible, evitando las generalidades y las descripciones vagas. Si se est en contacto con las personas observadas, es necesario abstenerse de hacer comentarios cualitativos o que impliquen un juicio de valores. Observar las reglas de cortesa y seguridad.

Secuela de la observacin Documentar y organizar formalmente las notas, impresionistas, etc. Revisar los resultados y conclusiones junto con la persona observada, el supervisar inmediato y posiblemente otro de sistemas.

Prototipos. Los prototipos permiten al desarrollador crear un modelo del software que debe ser construido. Al igual que todos los enfoques al proceso de desarrollo del software, el prototipado comienza con la captura de requerimientos. Desarrolladores y clientes se renen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y sealan reas en las que ser necesaria la profundizacin en las definiciones. Luego de esto, tiene lugar un "diseo rpido". El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseo rpido lleva a la construccin de un prototipo. El prototipo es evaluado por el cliente y el usuario y utilizado para refinar los requerimientos del software a ser desarrollado. Un proceso de iteracin tiene lugar a medida que el prototipo es "puesto a punto" para satisfacer las necesidades del cliente y permitiendo al mismo tiempo una mejor comprensin del problema por parte del desarrollador. Existen principalmente dos clases de prototipos: Prototipo rpido: El prototipado rpido es un mecanismo para lograr la validacin precompromiso. Se utiliza para validar requerimientos en una etapa previa al diseo especfico. En 14

este sentido, el prototipo puede ser visto como una aceptacin tcita de que los requerimientos no son totalmente conocidos o entendidos antes del diseo y la implementacin. El prototipo rpido puede ser usado como un medio para explorar nuevos requerimientos y as ayudar a "controlar" su constante evolucin. Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida est dividido en dos fases distintas: desarrollo y mantenimiento. La experiencia ha demostrado que esta distincin es arbitraria y va en contra de la realidad ya que la mayor parte del costo del software ocurre despus de que el producto se ha entregado. El punto de vista evolutivo del ciclo de vida del software considera a la primera entrega como un prototipo inicial en el campo. Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos ms maduros. Este proceso contina hasta que se haya desarrollado el producto final. La adopcin de esta ptica elimina la distincin arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad que afecta las estrategias para la estimacin de costos, enfoques de desarrollo y adquisicin de productos. Sesiones JAD (Desarrollo participativo de aplicaciones) La tcnica Joint Application Development (JAD) o desarrollo participativo de aplicaciones tiene como objetivo central facilitar la cooperacin entre usuarios y analistas durante el desarrollo de sistemas. Al trabajar aplicando los procedimientos de JAD, los analistas de sistemas y los representantes funcionales realizan reuniones de trabajo con los usuarios directos para discutir las caractersticas de los sistemas objeto de estudio y, sobre la marcha de las mismas discusiones, se van trazando los modelos que permitirn definir los requerimientos funcionales de esos sistemas. Las sesiones de JAD son de dos tipos: de adiestramiento y de trabajo. A su vez, las sesiones de trabajo se cumplen, normalmente, en tres etapas: revisin, formalizacin y validacin Las Sesiones JAD de Adiestramiento Las sesiones JAD de adiestramiento tienen como objetivo fundamental orientar a los usuarios que participarn en los ejercicios JAD en el uso de las herramientas y tcnicas de modelaje de procesos y datos y demostrar cmo el uso de esas herramientas y tcnicas facilitarn la comunicacin precisa de sus requerimientos. As pues, la sesin JAD de adiestramiento se hace con el fin de que los usuarios puedan participar productivamente en la elaboracin y revisin de los modelos que se desarrollarn en las subsiguientes sesiones

Las Sesiones JAD de Trabajo Durante las sesiones JAD de trabajo se cumplen tareas de anlisis y diseo de aplicaciones, con participacin activa de usuarios y analistas de sistemas. En cada sesin de trabajo, a medida que van discutindose diferentes aspectos del sistema objeto de estudio, se van elaborando modelos de procesos y datos en borrador, haciendo uso de un pizarrn o de rotafolios, con el fin de que los participantes puedan confirmar, al equipo de desarrollo, si los modelos representan razonablemente bien los puntos por ellos expuestos. Dentro de una sesin de trabajo JAD, despus de concluida la reunin con los usuarios, los modelos borrador se "ponen en limpio"; normalmente, el vehculo ms adecuado para ello es una herramienta CASE, ya que sta permitir ir haciendo el trabajo de integracin de los modelos y, adems, permitir detectar las posibles discrepancias o inconsistencias que puedan existir entre uno o ms grupos de usuarios Una sesin de trabajo JAD concluye con la revisin de los modelos puestos en limpio o procesados por el CASE, con el fin de permitir que el usuario confirme la validez de stos o rectifique aquellos puntos que no se ajustan a la realidad. 15

Participantes de las Sesiones JAD En trminos generales, los participantes de una sesin JAD son los siguientes: El moderador Analista de sistemas Representantes funcionales Usuarios directos Profesionales o expertos El Moderador Antes de las sesiones JAD, el moderador o coordinador se encarga de hacer los recordatorios necesarios, con la debida anticipacin, para asegurar que todos los invitados asistan puntualmente a las reuniones. Durante la realizacin de las sesiones, el moderador tiene la responsabilidad de estimular la participacin de todos los invitados, asegurar que se haga un uso productivo del tiempo de todos los participantes, evitar la discusin repetitiva de conceptos y detener cualquier debate improductivo. Normalmente, ser deseable que algn representante funcional en el proyecto acte como moderador de las sesiones de trabajo. El moderador debe abstenerse de tomar partido en las discusiones que puedan presentarse y se asegurar de que, en caso de que haya varias alternativas u opiniones, cada una de ellas se esquematice en el pizarrn y sea discutida con objetividad, dndole al grupo la oportunidad de llegar a conclusiones de consenso. Analista de Sistemas El analista de sistemas tiene la responsabilidad de preguntarles a los usuarios participantes acerca de su trabajo y requerimientos, con el fin de ir tomando notas y dibujando en el pizarrn modelos parciales, tanto de datos como de procesos, que representen las afirmaciones hechas por los usuarios. Al terminar las sesiones de trabajo, el analista tambin se encargar de integrar los modelos parciales trazados durante el da al conjunto de especificaciones elaboradas para el proyecto. Asi mismo, una vez puestos los modelos en limpio, se encargar de presentarlos y validarlos con los usuarios que hayan participado en la sesin de trabajo. Usuarios En las sesiones JAD deben participar tanto los representantes funcionales del proyecto como gerentes, supervisores y usuarios directos que estn en capacidad de aportar elementos de relevancia para el tema a discutir en las sesiones de trabajo y que, dadas sus experiencias, puedan enriquecer el estudio que se realiza.

Profesionales o Expertos Dependiendo del tema a discutir en una sesin de trabajo JAD y, especialmente, en reuniones donde el inters se centre en diseo ms que en anlisis, puede resultar sumamente conveniente invitar a especialistas como, por ejemplo, al diseador de bases de datos, al consultor de telecomunicaciones, y otros. La participacin de estos especialistas puede ayudar a realizar preguntas ms concretas que las que pudiese hacer el analista de sistemas. El Ciclo de JAD Por lo general, la aplicacin de la tcnica JAD sigue los siguientes pasos: Planificacin de las sesiones Publicacin del calendario de reuniones Adiestramiento de participantes Sesiones de trabajo JAD

16

Planificacin de las Sesiones Todo el conjunto de sesiones JAD que se llevarn a cabo para un proyecto deben ser cuidadosamente planificadas. En un primer paso se elaborar un plan inicial, en el cual se establecer cuntas reuniones se realizarn, que reas del negocio o del sistema se discutirn en cada una de ellas, quines son las personas ms calificadas para la discusin de cada tema, cuntas sesiones de adiestramiento habr que realizar, durante qu perodo debern realizarse. Con este plan inicial se proceder a contactar a los invitados y a reservar las facilidades necesarias para llevar a cabo las reuniones. Una vez confirmados los participantes y los recursos, se elaborar el calendario de todas las reuniones. Normalmente, la responsabilidad de las tareas de planificacin de las sesiones JAD recae en el coordinador o moderador.

17

Elaboracin del Calendario de Reuniones Una vez preparado el calendario de cada una de las sesiones, ste debe hacerse pblico, enviando una copia a cada uno de los invitados, con el fin de que recuerden las fechas en que su presencia ser necesaria Adiestramiento de Participantes De acuerdo con las fechas fijadas en el calendario de sesiones JAD, se irn cumpliendo las sesiones de entrenamiento. En estas sesiones se orientar a los usuarios que participarn en los ejercicios JAD en el uso de las herramientas y tcnicas de modelaje de procesos y datos y se demostrar cmo el uso de esas herramientas y tcnicas facilitar la comunicacin precisa de sus requerimientos. En estas sesiones se les enfatizar a los invitados la necesidad de venir a las sesiones JAD de trabajo debidamente preparados con copias de cada documento o reporte utilizado, manuales de procedimientos y cualquier otro material pertinente al tema que ser discutido. Normalmente, las sesiones de entrenamiento las dirige el analista de sistemas, haciendo uso del material didctico (transparencias y notas) preparados para tal fin Sesiones de Trabajo JAD Durante las sesiones JAD de trabajo se cumplirn las tareas de anlisis y diseo planificadas, con la participacin activa de los usuarios y dems invitados. En estas sesiones, a medida que van cubrindose diferentes aspectos, se irn elaborando modelos de procesos y datos en borrador en el pizarrn o en los rotafolios; cada uno de estos pequeos modelos deber ser confirmado y validado por los participantes. Despus de concluida la reunin con los usuarios, los modelos en borrador se pondrn en limpio, preferiblemente con la herramienta CASE (si se dispone de ella), ya que sta permitir ir haciendo el trabajo de integracin de los modelos y, adems, permitir detectar las posibles discrepancias o inconsistencias que puedan existir entre uno o ms grupos de usuarios. La sesin de trabajo JAD concluir con la revisin de los modelos puestos en limpio o procesados por el CASE, con el fin de permitir que los participantes puedan confirmar la validez de stos o rectificar aquellos puntos que presenten inconsistencias o discrepancias. Normalmente, una sesin de trabajo JAD se inicia temprano en la maana, con la etapa de discusin, la cual se termina a media tarde, para que el equipo de desarrollo pueda poner "en limpio" las conclusiones de la reunin. Se concluye a primera hora del siguiente da, con la etapa de validacin que, normalmente, resulta una reunin bastante corta (menos de 1 hora).

Beneficios de la Tcnica JAD La tcnica JAD elimina o, por lo menos, minimiza la necesidad de realizar entrevistas individuales a los usuarios directos. En sistemas de mediana o gran envergadura, cuando la definicin de requerimientos se hace a travs de entrevistas directas se invierte una cantidad enorme de tiempo, resulta muy difcil validar los modelos con cada entrevistado, algunas entrevistas resultan improductivas por cuanto no aaden nada adicional a lo aportado por otros entrevistados, y resulta complejo conciliar las discrepancias o diferencias que puedan existir entre las afirmaciones hechas por diferentes usuarios. Dado que es fundamentalmente una tcnica de trabajo en equipos, la tcnica JAD elimina todas las desventajas de la entrevista individual y proporciona una gran cantidad de ventajas, entre las cuales se deben citar las siguientes: Reduce el tiempo de anlisis o diseo, pues en una sola sesin pueden participar todos los interesados en una misma rea Mejora las comunicaciones, pues todos los modelos derivados trazados en las sesiones de trabajo se validan con sus participantes. 18

 Crea sentido de consenso y participacin, pues, durante las sesiones de trabajo, el usuario directo tiene la oportunidad de presentar y discutir sus puntos de vista y problemas. Facilita la identificacin de problemas o inconsistencias, pues cualquier discrepancia entre opiniones puede aclararse en las propias reuniones de trabajo. Mejora la calidad de los productos, pues ser posible definir en forma ms completa los verdaderos requerimientos de los usuarios. Requerimientos para el Uso de la Tcnica JAD Las sesiones JAD, si bien permiten reducir la duracin de las etapas de anlisis y diseo, requieren una excelente planificacin, de tal forma que los diferentes usuarios sean avisados de las reuniones con la debida anticipacin y asistan a stas con todos los materiales necesarios (muestras de formularios, de reportes, y otros). Asimismo, dado que el objetivo fundamental de las sesiones JAD es agilizar el proceso, en cada sesin de trabajo debe existir un moderador o facilitador de la reunin que estimule el uso productivo del tiempo y evite repeticin de conceptos o debates improductivos. El objetivo central de la tcnica JAD es utilizar en la forma ms eficiente posible los recursos disponibles para el diseo de sistemas; la sola aplicacin de la tcnica, sin embargo, no garantiza que tales objetivos se cumplan; para ello es necesario que se cumplan ciertas condiciones en la realizacin de las sesiones, como son Debe cumplirse con la sesin de entrenamiento, con el fin de asegurar que todos los participantes entiendan su rol. Debe contarse con las facilidades de reunin: saln de reuniones, pizarrn, y otros. Deben minimizarse las interrupciones, con el fin de que pueda aprovecharse el tiempo de todos los participantes.

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.

Ventajas y desventajas de cada una de las tcnicas utilizadas en las etapas de la Ingeniera de Requerimientos.
Tcnica Ventajas Mediante ellas se obtiene una gran cantidad de informacin correcta a travs del usuario. Desventajas La informacin obtenida al principio puede ser redundante o incompleta. 19

Tcnica Entrevistas y Cuestionarios

Ventajas Pueden ser usadas para obtener un pantallazo del dominio del problema. Son flexibles. Permiten combinarse con otras tcnicas. Los diferentes puntos de vista y las confusiones en cuento a terminologa, son aclaradas por expertos. Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto. Ayudan a validar y desarrollar nuevos requerimientos. Permite comprender aquellos requerimientos que no estn muy claros y que son de alta volatilidad.

Desventajas Si el volumen de informacin manejado es alto, requiere mucha organizacin de parte del analista, as como la habilidad para tratar y comprender el comportamiento de todos los involucrados. Es necesaria una buena compenetracin del grupo participante.

Lluvia de Ideas

Prototipos

Anlisis Jerrquico

Casos de Uso

JAD

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. Representan los requerimientos desde el punto de vista del usuario. Permiten representar ms de un rol para cada afectado. Identifica requerimientos estancados, dentro de un conjunto de requerimientos. Reduce el tiempo de anlisis o diseo, pues en una sola sesin pueden participar todos los interesados en una misma rea Mejora las comunicaciones, pues todos los modelos derivados trazados en las sesiones de trabajo se validan con sus participantes. Crea sentido de consenso y participacin, pues, durante las sesiones de trabajo, el usuario directo tiene la oportunidad de presentar y discutir sus puntos de vista y problemas.

El cliente puede llegar a pensar que el prototipo es una versin del software que ser desarrollado. A menudo, el desarrollador hace compromisos de implementacin con el objetivo de acelerar la puesta en funcionamiento del prototipo Debe construirse un estndar claro de evaluacin, que incluya la participacin del cliente.

En sistemas grandes, toma mucho tiempo definir todos los casos de uso. El anlisis de calidad depende de la calidad con que se haya hecho la descripcin inicial.

Debe cumplirse con la sesin de entrenamiento, con el fin de asegurar que todos los participantes entiendan su rol. Debe contarse con las facilidades de reunin: saln de reuniones, pizarrn, y otros. Deben minimizarse las interrupciones, con el fin de que pueda aprovecharse el tiempo de todos los participantes.

20

Tcnica

Ventajas Facilita la identificacin de problemas o inconsistencias, pues cualquier discrepancia entre opiniones puede aclararse en las propias reuniones de trabajo. Mejora la calidad de los productos, pues ser posible definir en forma ms completa los verdaderos requerimientos de los usuarios.

Desventajas

Resumen
Es muy importante mencionar que el poder formular una especificacin de requerimientos completa y consistente, es un paso muy importante para evitar cometer errores en la definicin de los requerimientos, ya que los mismos pueden resultar muy caros de corregir una vez desarrollado el sistema. De ah, la vital importancia que tiene la ingeniera de requerimientos en generar una adecuada especificacin que contemple claramente y sin ambigedades los requerimientos del sistema a desarrollar, con el fin primordial de evitar que los proyectos fracasen debido a una mala elaboracin de la definicin y especificacin de requerimientos. El proceso de la Ingeniera de Requerimientos sirve para recopilar la informacin necesaria para establecer la funcionalidad que se quiere alcanzar con el sistema. Para ello, se debe de contar con buenos mtodos y tcnicas para hacerlo, adems de una comunicacin fluida y constante con el cliente, ya que los requerimientos deben reflejar las necesidades reales que el cliente quiere satisfacer. Las revisiones deben involucrar al cliente y al staff de contratistas para validar los requerimientos del sistema. Como proceso, la administracin de requerimientos es fundamental en todo proyecto de desarrollo de software, ya que se debe de contar con una especificacin clara y completa desde las fases inciales para no tener problemas posteriores que implican un retraso en el cronograma, un presupuesto errneo, o hasta la posible cancelacin del proyecto. Es importante que el documento que se obtenga de esta etapa sea un reflejo real del acuerdo de las partes involucradas. Hay que notar el aporte que ha venido a proporcionar la utilizacin de tcnicas como la especificacin, la luvia de ideas y el desarrollo de prototipos, que ayudan a definir requerimientos de una manera concisa y real. Tambin es necesario resaltar y dar a conocer que alrededor del mundo existen estndares enfocados en el mejoramiento de los procesos de desarrollo de software, citando entre ellos a los estndares propuestos por la IEEE (Instituto de Ingenieros Elctricos y Electrnicos), el SEI (que propone el modelo de capacidad de madurez, mejor conocido como CMM), el PMI (Project Management Institute, que ofrece certificaciones para el rea de administracin del proyectos) y las ya conocidas normas ISO, en cuyas normas tambin se involucran apartados referentes al desarrollo de software. Finalizando Quienes hacen Ingeniera de Requerimientos? Es Muy difcil encontrar a una persona..?. Que sepa entrevistar, escuchar, cuestionar (pensamiento crtico), modelar, analizar, facilitar discusiones y negociaciones, observar, comunicar de manera verbal y escrita, relacionarse con gente, innovar,... Que tenga experiencia en el dominio del problema y de la solucin Existen? En mi opinin se puede formar

21

Bibliografa y enlaces recomendados

Pressman, Roger S. 2006, Ingeniera del Software: Un enfoque prctico, Sexta edicin, Mxico DF, Editorial McGraw Hill. Sommerville Ian, 2005, Ingeniera del Software, Stima edicin, Mxico DF, Editorial Pearson. http://standards.ieee.org/reading/ieee/std_public/description/se/610.121990_desc.html Herrera J., Lizka Johany (2003) Ingeniera de Requerimientos, Ingeniera de Software, Recuperado el 25 de mayo de 2006 en:http://www.monografias.com/trabajos6/resof/resof.shtml Montes Meyhuay Magno, Ingeniera de Requerimientos, recuperado el 25 de mayo de 2006 en: www.proamazonia.gob.pe/bpa/ingenieria_requerimientos.htm Racional RequisitePro, recuperado el 30 de mayo de 2006 en: http://www.rational.com.ar/herramientas/requisitepro.html

22

Unidad I Requerimientos de Software Unidad Curricular Ingeniera de Software II; Modulo: FUNDAMENTOS DE INGENIERA DE REQUISITOS Y ANLISIS

MINISTERIO POPULAR PARA LA EDUCACION SUPERIOR UNIVERSIDAD POLITECNICA MARACAIBO MARACAIBO EDO. ZULIA DEPARTAMENTO DE INFORMATICA. UNIDAD CURRICULAR: INGENIERIA DE REQUERIMIENTOS MDULO: FUNDAMENTOS DE INGENIERIA DE REQUISITOS Y ANALISIS

GUIA DE LA UNIDAD I REQUERIMIENTOS DE SOFTWARE

PROFESOR: ALFONSO R. GALEA BRACHO