Analisis y Tecnicas de Recoleccion de Datos

5/10/2018 Analisis y Tecnicas de Recoleccion de Datos - slidepdf.com

http://slidepdf.com/reader/full/analisis-y-tecnicas-de-recoleccion-de-datos-55a0c70b3a889

Unidad I Requerimientos de SoftwareUnidad Curricular Ingeniería de Software II; Modulo: FUNDAMENTOS DE INGENIERÍA DE REQUISITOS Y ANÁLISIS

Tabla de contenido

Tabla de contenido ............................................................................................................. 1

¿Qué es un requerimiento? ................................................................................................2Tipos de Requerimientos ............................................................................................... 2

Características de un Requerimiento .............................................................................2

Dificultades para definir los requerimientos ................................................................. 3

Ingeniería de requerimientos .............................................................................................3

Importancia de la ingeniería de requerimientos ............................................................ 3

Actividades de la ingeniería de requerimientos ............................................................. 4

Extracción (Análisis del problema) ...........................................................................4

Análisis (Evaluación y negociación de los requerimientos) ...................................... 4

Especificación ............................................................................................................ 4

Validación .................................................................................................................. 5

Evolución de los requerimientos ...............................................................................5Técnicas y herramientas utilizadas en la ingeniería de requerimientos ......................... 6

Técnicas utilizadas en las actividades de IR .............................................................. 6

Entrevistas y Cuestionarios ................................................................................... 6

Sistemas existentes ................................................................................................6

Lluvia de ideas (Brainstorm) .................................................................................6

Prototipos ............................................................................................................... 6

Casos de Uso ......................................................................................................... 7

Herramientas automatizadas para la Administración de Requerimientos .................7

RequisitePro ...........................................................................................................7

Descripción de las técnicas más utilizadas en la ingeniería de requerimientos.............8Entrevistas y Cuestionarios. ..................................................................................... 8

Lluvia de Ideas (Brainstorm). ................................................................................10

Encuestas................................................................................................................. 12

Observación.............................................................................................................12

Prototipos. ..............................................................................................................13

Sesiones JAD (Desarrollo participativo de aplicaciones) ........................................14

Proceso de Análisis Jerárquico (AHP) .................................................................... 18

Ventajas y desventajas de cada una de las técnicas utilizadas en las etapas de la

Ingeniería de Requerimientos......................................................................................18

Resumen ......................................................................................................................... 20

1




En esta unidad se tiene como objeto establecer los conceptos y fundamentos involucrados enla Ingeniería de Requerimientos donde el alumno entenderá: ¿Qué es un requerimiento?;Tipos de Requerimientos; ¿Qué es la Ingeniería de Requerimientos?, su importancia; susactividades, sus técnicas y herramientas.

¿Qué es un requerimiento?

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

A continuación se presenta 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 desistema para satisfacer un contrato, estándar, especificación u otro documento formal”. (Std610.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 quedebe proporcionar el sistema o una restricción de éste”. (Sommerville, 2005: 108)

Analizando las definiciones anteriores, un requerimiento es una descripción de una condición ocapacidad que debe cumplir un sistema, ya sea derivada de una necesidad de usuarioidentificada, o bien, estipulada en un contrato, estándar, especificación u otro documentoformalmente impuesto al inicio del proceso.

Tipos de Requerimientos

Los requerimientos de software pueden dividirse en 2 categorías: requerimientos funcionales yrequerimientos no funcionales. Los requerimientos funcionales son los que definen lasfunciones que el sistema será capaz de realizar, describen las transformaciones que el sistemarealiza sobre las entradas para producir salidas. Es importante que se describa el ¿Qué? y no

el ¿Cómo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanzael proyecto de software se convierten en los algoritmos, la lógica y gran parte del código delsistema. Por otra parte los requerimientos no funcionales tienen que ver con características quede una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo yespacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo),mantenimiento, seguridad, portabilidad, estándares, auditabilidad y otros.

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ómose sabe si se cumplió con él o no?

2




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 muchosinconvenientes los cuales son importantes de identificar y prevenir, a continuación se presentaun 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

• Usan el mismo término con distinto significado

Ingeniería de requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para unsistema es llamado ingeniería de requerimientos. La meta de la ingeniería de requerimientos

(IR) es entregar una especificación de requisitos de software correcta y completa. Algunosotros conceptos de ingeniería de requerimientos son:

“Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor elproblema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen acomprender cuál será el impacto del software sobre el negocio, qué es lo que el clientequiere y cómo interactuarán los usuarios finales con el software”. (Pressman, 2006: 155)

“La ingeniería de requerimientos es el proceso de desarrollar una especificación desoftware. Las especificaciones pretender comunicar las necesidades del sistema delcliente a los desarrolladores del sistema”. (Sommerville, 2005: 82)

En síntesis, el proceso de ingeniería de requerimientos se utiliza para definir todas las

actividades involucradas en el descubrimiento, documentación y mantenimiento de losrequerimientos para un producto de software determinado, donde es muy importante tomar encuenta que el aporte de la IR vendrá a ayudar a determinar la viabilidad de llevar a cabo elsoftware (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso deobtención y análisis de requerimientos, su especificación formal, para finalizar con elsubproceso de validación donde se verifica que los requerimientos realmente definen elsistema que quiere el cliente.

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):

3




• Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividadde 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 demantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

•Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un maldesarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisionestomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo dedesarrollo 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 unconjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, yotros)

• Mejora la comunicación entre equipos: La especificación de requerimientos representa

una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, elproyecto no será exitoso.

• Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente aconsiderar 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 ingeniería de requerimientos

Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice que dentrode la IR existen cuatro actividades básicas que se tienen que llevar a cabo para completar elproceso. Estas actividades ayudan a reconocer la importancia que tiene para el desarrollo deun proyecto de software realizar una especificación y administración adecuada de losrequerimientos de los clientes o usuarios. Las cinco actividades son: extracción, análisis,especificación, validación y evolucion, y serán explicadas a continuación cada una de ellas.

Extracción (Análisis del problema)

Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado alas actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí,los analistas de requerimientos deben trabajar junto al cliente para descubrir el problemaque el sistema debe resolver, los diferentes servicios que el sistema debe prestar, lasrestricciones que se pueden presentar y otros. Es importante, que la extracción sea efectiva, yaque la aceptación del sistema dependerá de cuán bien éste satisfaga las necesidades delcliente.

Análisis (Evaluación y negociación de los requerimientos)

Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfocaen 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 derequerimientos; 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 ysoluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos

Especificación

En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiadode detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puededecir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicandotécnicas y/o estándares de documentación, como la notación UML (Lenguaje de ModeladoUnificado), que es un estándar para el modelado orientado a objetos, por lo que los casos deuso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para laobtención de requerimientos

4




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 asegurarseque representan una descripción, por lo menos, aceptable del sistema que se debeimplementar. Esto implica verificar que los requerimientos sean consistentes y que esténcompletos. 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 unmantenimiento adecuado al documento de especificación de requerimientos, que es eldocumento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar queno existe un proceso único que sea válido de aplicar en todas las organizaciones. Cadaorganizació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 personasinvolucradas en la ingeniería de requerimientos. Hay muchas maneras de organizar el procesode ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir aconsultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas enel proceso.

Evolución de los requerimientos

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de

los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, es esencial

planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado.

La actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del

proyecto.

Los requerimientos cambian por diferentes razones. Las más 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

característica en particular, modificación que a la vez puede tener impacto en otros

requerimientos. Por esto, la administración de cambios involucra actividades como establecer

políticas, guardar históricos 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 código, ya

que evita tener requerimientos emparchados (Se le llama requerimiento emparchado a aquélque ha sufrido cambios excesivos en la semántica) en un proyecto

Entre algunos de los beneficios que proporciona el control de versiones están:

• Prevenir cambios no autorizados.

• Guardar revisiones de los documentos de requerimientos.

• Recuperar versiones previas de los documentos.

• Administrar una estrategia de “releases”.

• Prevenir la modificación simultánea 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.

5




Técnicas y herramientas utilizadas en la ingeniería de requerimientos

Técnicas utilizadas en las actividades de IR

Existen varias técnicas para la IR propuestas para ingeniería de requerimientos (Herrera, 2003:12), y de las cuales solo se abarcarán cinco de ellas. Es importante resaltar que estas técnicaspueden 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 y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas ode grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionarioconsiste en una serie de preguntas relacionadas con varios aspectos de un sistema

Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potenciade sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datospara el sistema propuesto o que serán afectados por él. El éxito de esta técnica, depende de lahabilidad del entrevistador y de su preparación para la misma.

Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionadoscon 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énes ú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 intención en su aplicación es la degenerar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerseen pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en unaprimera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como,por ejemplo, "caro", "impracticable", "imposible", y otros. 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 ideascreativas.

• Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de lasideas, porque sino 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, porqueluego 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 extracción de requerimientos, puede ocurrir que algunos requerimientosno estén demasiado claros o que no se esté muy seguro de haber entendido correctamente losrequerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficazdel sistema final. Entonces, para validar los requerimientos hallados, se construyen prototipos.Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuariofinal, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistemadiseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo demanera eficiente y efectiva. El desarrollo del prototipo comienza con la captura derequerimientos. 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 queserá necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño

6




rápido”. El diseño rápido se centra en una representación de aquellos aspectos del softwareque serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápidolleva a la construcción de un prototipo.

Casos de Uso

Los casos de uso son una técnica para especificar el comportamiento de un sistema. El sitio enInternet wikipedia.org, define a un caso de uso como:

“Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema enrespuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos deuso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante suinteracción 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 elsistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es unadescripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicialdesde un actor hacia el sistema. La mayoría de los requerimientos funcionales, sino todos, sepueden 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 hanconvertido en una característica fundamental de la notación UML (Lenguaje de modeladounificado), 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 herramientasCASE. Las herramientas CASE (Ingeniería del Software Asistida por Computadora) se leconoce a todo aquel software que es usado para ayudar a las actividades del proceso dedesarrollo del software, en donde se ubica la ingeniería de requerimientos, que se ha venidotratando en este artículo. Estas herramientas se concentran en capturar requerimientos,

administrarlos y producir una especificación de requisitos. Existen muchas y muy variadasherramientas CASE que pueden ser utilizadas por los desarrolladores de software en susproyectos, y de la forma más conveniente para ellos. Si es importante hacer ver que estasherramientas fungen como un medio facilitador para agilizar y mejorar los procesosinvolucrados en todo el ciclo de vida presentado por la IR, y que en conjunto ayudan a laconstrucción final de un producto de software terminado. Estas herramientas permiten entreotras cosas tener un mayor control en proyectos complejos, reducir costos y retrasos en losproyectos, ayudan a determinar la complejidad y los esfuerzos necesarios. En este apartado sepresentan características generales de una de las herramientas más utilizadas para estepropósito: RequisitePro, y recomendada sitio en Internet Rational.com.

RequisitePro

RequisitePro es la herramienta que ofrece Rational Software para tener un mayor control sobrelos requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevosrequerimientos de usuario que surjan durante el ciclo de vida del proyecto. En RequisitePro losrequerimientos se encuentran documentados bajo un esquema organizado de documentos;estos esquemas cumplen completamente con los estándares requeridos por algunas de lasinstituciones 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 deMadurez) y por el RUP (Proceso Unificado Racional) Esta herramienta se integra conaplicaciones para la administración de cambios, herramientas de modelado de sistemas y conherramientas de pruebas. Esta integración asegura que los diseñadores conocen losrequerimientos del usuario, del sistema y del software en el momento de su desarrollo. Eldesarrollo de software es una tarea de equipo, de tal forma, es crítico que todos los miembrosdel equipo posean un entendimiento compartido de la visión de sus proyectos, metas,

especificaciones y requerimientos; pero, ¿cómo puede conseguirse cuando los equipos seencuentran geográficamente distribuidos y funcionalmente aislados, no pudiendo comunicarse

7




entre si en tiempo y forma? La solución a esta necesidad es IBM Rational RequisitePro. IBMRational RequisitePro es una solución fácil de usar, es una herramienta de administración derequerimientos que le permite al equipo crear y compartir sus requerimientos utilizandométodos familiares basados en documentos potenciados por la aplicación de las capacidadesde una base de datos, tales como la trazabilidad y análisis de impacto. El resultado es unamejor comunicación y administración de requerimientos con una mayor probabilidad de

completar los proyectos en tiempo, dentro del presupuesto y superando las expectativas. Losproyectos exitosos comienzan con una buena administración de requerimientos, cuanto másefectiva sea su ejecución, mayor será el resultado en calidad y satisfacción del cliente. Segúnla promoción hecha en Internet mediante la página Web para esta herramienta, algunas de susventajas son:

• Un producto potente y fácil de utilizar para la gestión de requisitos y casos de uso quepropicia una mejor comunicación, mejoras en el trabajo en equipo y reduce el riesgo de losproyectos.

• 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 yconsulta 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 seve beneficiado de muchas maneras, y en el caso de la ingeniería de requerimientos, le ayudanotablemente, ya que como se ha venido hablando en el desarrollo de este artículo, la IRconstituye una de las etapas más importantes a tomar en cuenta en el ciclo de desarrollo desoftware, ya que en ella se definen los requerimientos con los que debe de contar el software; eincluso, podría llegar a determinar la viabilidad de implementar ese software no es del todoposible, y poder cancelar a tiempo un desarrollo no productivo

Descripción de las técnicas más utilizadas en la ingeniería de requerimientos.

En esta sección se van a describir en detalle algunas de las técnicas más usadas en la IR.Cada técnica puede aplicarse en una o más actividades de esta ingeniería; en la práctica, latécnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose.

Entrevistas y Cuestionarios.

Dentro de una organización, la entrevista es la técnica más significativa y productiva de quedispone el analista para recolectar datos. En otras palabras, la entrevista es un intercambio deinformación que se efectúa cara a cara. Es un canal de comunicación entre el analista y la

organización; sirve para obtener información acerca de las necesidades y la manera desatisfacerlas, así como consejo y comprensión por parte del usuario para toda idea o métodonuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad paraestablecer una corriente de simpatía con el personal usuario, lo cual es fundamental entranscurso del estudio. A. Preparación de la Entrevista.

Determinar la posición en la organización del futuro entrevistado, responsabilidades,actividades, y otros (Investigación). Preparar las preguntas que van a plantearse, y losdocumentos necesarios (Organización). Fijar un límite de tiempo y preparar la agenda para laentrevista. (Psicología). Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad (Psicología). Hacer la cita con la debida anticipación (Planeación).

B. Conducción de la Entrevista.

8




Explicar con toda amplitud el propósito y alcance del estudio (Honestidad). Explicar la funciónpropietaria como analista y la función que se espera conferir al entrevistado. (Imparcialidad).Hacer preguntas específicas para obtener respuestas cuantitativas (Hechos). Evitar laspreguntas que exijan opiniones interesadas, subjetividad y actitudes similares (Habilidad).Evitar el cuchicheo y las frases carentes de sentido (Claridad). Ser cortés, absteniéndose deemitir juicios de valores. (Objetividad). Conservar el control de la entrevista, evitando

divagaciones y los comentarios al margen de la cuestión (Habilidad). Escuchar atentamente loque se dice, guardándose de anticiparse a las respuestas (Comunicación).

C. Secuela de la Entrevista.

Escribir los resultados (Documentación). Entregar una copia al entrevistado, solicitando suconformación, correcciones o adiciones. (Profesionalismo). Archivar los resultados de laentrevista para referencia y análisis posteriores (Documentación).

D. Recolectar datos mediante la Entrevista.

La entrevista es una forma de conversación, no de interrogación, al analizar las característicasde los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el

sistema, los analistas pueden conocer datos que no están disponibles en ningún otra forma. En las investigaciones de sistema, las formas cualitativas y cuantitativas de la información sonimportantes. La información cualitativa está relacionada con opinión, política y descripcionesnarrativas de actividades o problemas, mientras que las descripciones cuantitativas tratan connúmeros frecuencia, o cantidades. A menudo las entrevistas pueden ser la mejor fuente deinformación cualitativa, los otros métodos tiende a ser más útiles en la recolección de datoscuantitativos. Son valiosas las opiniones, comentarios, ideas o sugerencia en relación a cómo se podríahacer el trabajo; la entrevista a veces es la mejor forma para conocer las actividades de lasempresas. La entrevista puede descubrir rápidamente malos entendidos, falsa expectativa oincluso resistencia potencial para las aplicaciones de desarrollo; más aún, a menudo es más

fácil calendarizar una entrevista con los gerentes de alto nivel, que pedirle que llenen uncuestionario.

E. Determinación del tipo de Entrevista.

La estructura de la entrevista varía. Si el objetivo de la entrevista radica en adquirir informacióngeneral, es conveniente elaborar una serie de preguntas sin estructura, con una sesión depreguntas 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. Puedencontestar por completo con sus propias palabras. Los analistas también deben dividir el tiempoentre desarrollar preguntas para entrevistas y analizar respuestas. Con frecuencia, se utilizanpreguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para

explorar un proceso o problema. Este tipo de preguntas son siempre apropiadas, además queayudan a entender la perspectiva del afectado y no están influenciadas por el conocimiento dela solución.

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 ¿Quién es el cliente?¿Quién es el usuario?¿Son sus necesidades diferentes?¿Cuáles son sus habilidades, capacidades, ambiente?

Del Proceso ¿Cuál es la razón por la que se quiere resolver este problema?¿Cuál es el valor de una solución exitosa?¿Cómo usted resuelve el problema actualmente?

¿Qué retrasos ocurren o pueden ocurrir?Del Producto ¿Qué problemas podría causar este producto en el negocio?

¿En qué ambiente se usará el producto?

9




¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable,rendimiento?¿Qué obstáculos afectan la eficiencia del sistema?

El éxito de esta técnica combinada, depende de la habilidad del entrevistador y de supreparación para la misma. Los analistas necesitan ser sensibles las dificultades que algunosentrevistados crean durante la entrevista y saber cómo tratar con problemas potenciales.Asimismo, necesitan considerar no sólo la información que adquieren a través del cuestionarioy la entrevista, sino también, 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 información sobre lascaracterísticas de diseño críticas para losempleados.

"Algunos empleados han sugerido que lamejor forma para hacer eficiente el

procesamiento de pedidos es instalar unsistema de computadora que maneje todoslos cálculos..."

Bajo estas circunstancias ¿apoyaría usted eldesarrollo de un sistema de este tipo?

Ejemplo: obtener la información sobre lascaracterísticas de diseño críticas para losempleados.

" La experiencia le ha proporcionado unaamplia visión en cuanto a la forma en la que la

empresa maneja los pedidos..."

Me gustaría que usted contestara algunaspreguntas específicas en relación en lo anterior:

-¿Qué etapas trabajan bien? ¿Cuáles no?-¿En donde se presenta la mayor parte delproblema?- ¿Cuándo ocurre un atraso, cómo se maneja?

G. Selección de Entrevistados.

Realizar entrevistas toma tiempo; por lo tanto no es posible utilizar este método para recopilar toda la información que se necesite en la investigación. La entrevista se aplica en los nivelesgerenciales y de empleados que puedan proporcionar la mayor parte de la información útil parael estudio los analistas.

H. Realización de Entrevista.

La habilidad del entrevistador es vital para el éxito en la búsqueda de hecho por medio de laentrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de lapreparación del objetivo de una entrevista específica como de las preguntas por realizar a unapersona determinada. El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a

asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidadde éxito. A través de la entrevista, los analistas deben aplicarse a sí mismos las siguientespreguntas:

¿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 método comenzó en el ámbito de las empresas, aplicándose a temas tan variados como laproductividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del

mercado, encontrar nuevos métodos que desarrollen el pensamiento creativo a todos losniveles, etc. Pero pronto se extendió a otros ámbitos, incluyendo el mundo de desarrollo desistemas; básicamente se busca que los involucrados en un proyecto desarrollen su

10




creatividad. A esta técnica se le conoce también como torbellino de ideas, tormenta de ideas,desencadenamiento de ideas, movilización verbal, bombardeo de ideas, sacudidas decerebros, promoción de ideas, tormenta cerebral, avalancha de ideas, tempestad en el cerebroy tempestad de ideas, entre otras.

Principios de la lluvia de ideas.

Aplazar el juicio y no realizar críticas, hasta que no agoten las ideas, ya que actuaría como uninhibidor. Se ha de crear una atmósfera de trabajo en la que nadie se sienta amenazado.Cuantas más ideas se sugieren, mejores resultados se conseguirán: "la cantidad produce lacalidad". Las mejores ideas aparecen tarde en el periodo de producción de ideas, será másfácil que encontremos las soluciones y tendremos más variedad sobre la que elegir. Laproducción de ideas en grupos puede ser más efectiva que la individual. Tampoco debemosolvidar que durante las sesiones, las ideas de una persona, serán asociadas de manera distintapor 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 sesión. Debe ser un experto enpensamiento creador. Su función es formular claramente el problema y que todos sefamiliaricen con él. Cuando lo haga, debe estimular ideas y hacer que se rompa el hielo enel grupo. Es el encargado de que se cumplan las normas, no permitiendo las críticas. Debepermanecer callado e intervenir cuando se corte la afluencia de ideas, por lo que le será útilllevar ya un listado de ideas. Debe hacer que todos participen y den ideas. Además, es lapersona que concede la palabra y da por finalizada la sesión. Posteriormente, clasificarálas ideas de la lista que le proporciona el secretario.

• El secretario: registra por escrito las ideas según van surgiendo. Las enumera, lasreproduce fielmente, las redacta y se asegura que todos están 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 categoría. Su función es producir ideas. Conviene que entre ellos nohaya diferencias jerárquicas.

Las personas que componen el grupo deben estar motivadas para solucionar el problema, ycon un ambiente que propicie la participación de todos. Todos pueden sentirse confiados y conla sensación de que pueden hablar sin que se produzcan críticas. Todas las ideas en principiodeben tener el mismo valor, pues cualquiera de ellas puede ser la clave para la solución. Esnecesario prestar mucha atención a las frases que pueden coartar la producción de ideas.Además durante la celebración no deben asistir espectadores. Debemos evitar todos losbloqueos que paralizan la ideación: como son nuestros hábitos o ideas preconcebidas, eldesánimo o falta de confianza en si mismo, el temor y la timidez.

Las fases de aplicación en el Brainstorm son:

• Descubrir hechos. Al menos con un día de antelación, el director comunica por escrito alos miembros del grupo sobre los temas a tratar. El director explica los principios de laTormenta de ideas e insiste en la importancia de tenerlos en cuenta. La sesión comienzacon una ambientación de unos 10 minutos, tratando un tema sencillo y no comprometido.Es una fase especialmente importante para los miembros sin experiencia. Se determina elproblema, delimitándolo, precisándolo y clarificándolo. A continuación se plantea elproblema, recogiendo las experiencias que se poseen o consultando documentación.Cuando es complejo, conviene dividirlo en partes. Aquí es importante la utilización delanálisis, desmenuzando el problema en pequeñas partes para conectar lo nuevo y lodesconocido.

• 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 quehemos visto. Además, es útil cuando se ha trabajado mucho, alejarse del problema, pues

11




es un buen momento para que se produzcan asociaciones. Muchas de las nuevas ideasserán ideas antiguas, mejoradas o combinadas con varias ya conocidas. Al final de lareunión, el director da las gracias a los asistentes y les ruega que no abandonen elproblema, ya que al día siguiente se le pedirá una lista de ideas que les puedan haber surgido. Se incorporan las ideas surgidas después de la reunión.

• Descubrir soluciones. Se elabora una lista definitiva de ideas, para seleccionar las másinteresantes. La selección se realiza desechando las ideas que no tienen valor y seestudia si son válidas las que se consideran interesantes. Lo mejor es establecer una listade criterios de conveniencia para cada idea. Se seleccionan las ideas más útiles y si esnecesario se ponderarán. Pueden realizarlo los mismos miembros del grupo o crear otrospara esta tarea; la clasificación debe hacerse por categorías (tarea que corresponde aldirector). Se presentan las ideas de forma atractiva, haciendo uso de soportes visuales.

Encuestas.

Hoy en día la palabra "encuesta" se usa más frecuentemente para describir un método deobtener información de una muestra de individuos. Esta "muestra" es usualmente sólo unafracción de la población bajo estudio. Aún así, todas las encuestas tienen algunas

características en común.A diferencia de un censo, donde se estudia a todos los miembros de la población, lasencuestas recogen información de una porción de la población de interés. En una encuesta debuena fe, la muestra no es seleccionada caprichosamente o sólo de personas que se ofrecencomo voluntarios para participar. La muestra es seleccionada científicamente de manera quecada persona en la población tenga una oportunidad medible de ser seleccionada. De estamanera los resultados pueden ser proyectados con seguridad de la muestra a la poblaciónmayor. La información es recogida usando procedimientos estandarizados de manera que acada individuo se le hacen las mismas preguntas más o menos de la misma manera. Laintención de la encuesta no es describir los individuos particulares quienes, por azar, son partede la muestra sino obtener un perfil compuesto de la población.El estándar de la industria para todas las organizaciones respetables que hacen encuestas esque los participantes individuales nunca puedan ser identificados al reportar los hallazgos.

Todos los resultados de la encuesta deben presentarse en resúmenes completamenteanónimos, tal como tablas y gráficas estadísticas.

Tamaño de la muestra. Muchas veces depende de los recursos profesionales y fiscalesdisponibles. Los analistas frecuentemente encuentran que una muestra de tamaño moderadoes suficiente estadística y operacionalmente. Las encuestas pueden ser clasificadas por sumétodo de recolección de datos. Las encuestas por correo, telefónicas y entrevistas en personason las más comunes. En los métodos más nuevos de recoger datos, la información seintroduce directamente a la computadora ya sea por un entrevistador adiestrado o aún por lamisma persona entrevistada. Las entrevistas en persona en el hogar u oficina de unparticipante son mucho más caras que las encuestas telefónicas o por correo. Estas puedenser necesarias especialmente cuando se debe recoger información compleja.

Preocupaciones potenciales. La calidad de una encuesta es determinada en gran medida por su propósito y por la forma en que es conducida. Las encuestas deben llevarse a caboúnicamente para obtener información estadística sobre algún tema. No deben ser diseñadaspara producir resultados predeterminados o como un artificio para mercadeo o para actividadessimilares. Cualquier persona a quien se le solicite que responda a una encuesta de opinión oque se preocupe por los resultados debe primero decidir si las preguntas que se hacen son justas.

Observación.

Otra técnica útil para el analista en su progreso de investigación, consiste en observar a laspersonas cuando efectúan su trabajo. Como técnica de investigación, la observación tieneamplia aceptación científica. Los sociólogos, sicólogos e ingenieros industriales utilizan

extensamente ésta técnica con el fin de estudiar a las personas en sus actividades de grupo ycomo miembros de la organización. El propósito de la organización es múltiple: permite alanalista determinar que se está haciendo, como se está haciendo, quien lo hace, cuando se

12




lleva a cabo, cuanto tiempo toma, dónde se hace y por que se hace. Observar las operacionesle proporciona el analista hechos que no podría obtener de otra forma.

Tipos de Observación.

El analista de sistemas puede observar de tres maneras básicas.

•

Primero, puede observar a una persona o actitud sin que el observado se dé cuenta y suinteracción por aparte del propio analista. Quizá esta alternativa tenga poca importanciapara el análisis de sistemas, puesto que resulta casi imposible reunir las condicionesnecesarias.

• Segundo, el analista puede observar una operación sin intervenir para nada, pero estandola persona observada enteramente consciente de la observación.

• Por último, puede observar y a la vez estar en contacto con las personas observadas. Lainteracción puede consistir simplemente en preguntar respecto a una tarea específica,pedir una explicación, etc.

Preparación para la observación

• Determinar y definir aquella que va a observarse.

• Estimar el tiempo necesario de observación.• Obtener la autorización de la gerencia para llevar a cabo la observación.

• Explicar a las personas que van a ser observadas lo que se va a hacer y las razones paraello.

Conducción de la observación

• Familiarizarse con los componentes físicos del área inmediata de observación.

• Mientras se observa, medir el tiempo en forma periódica.

• Anotar lo que se observa lo más específicamente posible, evitando las generalidades y lasdescripciones 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 cortesía y seguridad.

Secuela de la observación

• 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 reúnen y definen los objetivosglobales del software, identifican todos los requerimientos que son conocidos, y señalan áreasen 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 delsoftware que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). Eldiseño rápido lleva a la construcción de un prototipo. El prototipo es evaluado por el cliente y elusuario y utilizado para refinar los requerimientos del software a ser desarrollado. Un procesode iteración tiene lugar a medida que el prototipo es "puesto a punto" para satisfacer lasnecesidades del cliente y permitiendo al mismo tiempo una mejor comprensión del problemapor parte del desarrollador.

Existen principalmente dos clases de prototipos:

Prototipo rápido: El prototipado rápido es un mecanismo para lograr la validación pre-compromiso. Se utiliza para validar requerimientos en una etapa previa al diseño específico. En

13




este sentido, el prototipo puede ser visto como una aceptación tácita de que los requerimientosno son totalmente conocidos o entendidos antes del diseño y la implementación. El prototiporápido puede ser usado como un medio para explorar nuevos requerimientos y así ayudar a"controlar" su constante evolución.

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 ymantenimiento. La experiencia ha demostrado que esta distinción es arbitraria y va en contrade la realidad ya que la mayor parte del costo del software ocurre después de que el productose ha entregado. El punto de vista evolutivo del ciclo de vida del software considera a laprimera entrega como un prototipo inicial en el campo. Modificaciones y mejoras subsecuentesresultan en nuevas entregas de prototipos más maduros. Este proceso continúa hasta que sehaya desarrollado el producto final. La adopción de esta óptica elimina la distinción arbitrariaentre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad queafecta las estrategias para la estimación de costos, enfoques de desarrollo y adquisición deproductos.

Sesiones JAD (Desarrollo participativo de aplicaciones)

La técnica Joint Application Development (JAD) o desarrollo participativo de aplicaciones tienecomo objetivo central facilitar la cooperación entre usuarios y analistas durante el desarrollo desistemas. Al trabajar aplicando los procedimientos de JAD, los analistas de sistemas y losrepresentantes funcionales realizan reuniones de trabajo con los usuarios directos para discutir las características de los sistemas objeto de estudio y, sobre la marcha de las mismasdiscusiones, se van trazando los modelos que permitirán definir los requerimientos funcionalesde esos sistemas.

Las sesiones de JAD son de dos tipos: de adiestramiento y de trabajo. A su vez, las sesionesde trabajo se cumplen, normalmente, en tres etapas: revisión, formalización y validación

Las Sesiones JAD de AdiestramientoLas sesiones JAD de adiestramiento tienen como objetivo fundamental orientar a los usuariosque participarán en los ejercicios JAD en el uso de las herramientas y técnicas de modelaje deprocesos y datos y demostrar cómo el uso de esas herramientas y técnicas facilitarán lacomunicación precisa de sus requerimientos. Así pues, la sesión JAD de adiestramiento sehace con el fin de que los usuarios puedan participar productivamente en la elaboración yrevisión de los modelos que se desarrollarán en las subsiguientes sesiones

Las Sesiones JAD de Trabajo

Durante las sesiones JAD de trabajo se cumplen tareas de análisis y diseño de aplicaciones,con participación activa de usuarios y analistas de sistemas. En cada sesión de trabajo, amedida que van discutiéndose diferentes aspectos del sistema objeto de estudio, se vanelaborando modelos de procesos y datos en borrador, haciendo uso de un pizarrón o derotafolios, con el fin de que los participantes puedan confirmar, al equipo de desarrollo, si losmodelos representan razonablemente bien los puntos por ellos expuestos.

Dentro de una sesión de trabajo JAD, después de concluida la reunión con los usuarios, losmodelos borrador se "ponen en limpio"; normalmente, el vehículo más adecuado para ello esuna herramienta CASE, ya que ésta permitirá ir haciendo el trabajo de integración de losmodelos y, además, permitirá detectar las posibles discrepancias o inconsistencias que puedanexistir entre uno o más grupos de usuarios

Una sesión de trabajo JAD concluye con la revisión de los modelos puestos en limpio oprocesados por el CASE, con el fin de permitir que el usuario confirme la validez de éstos orectifique aquellos puntos que no se ajustan a la realidad.

14




Participantes de las Sesiones JAD

En términos generales, los participantes de una sesión 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 recordatoriosnecesarios, con la debida anticipación, para asegurar que todos los invitados asistanpuntualmente a las reuniones. Durante la realización de las sesiones, el moderador tiene laresponsabilidad de estimular la participación de todos los invitados, asegurar que se haga unuso productivo del tiempo de todos los participantes, evitar la discusión repetitiva de conceptosy detener cualquier debate improductivo. Normalmente, será deseable que algún representantefuncional en el proyecto actúe como moderador de las sesiones de trabajo.

El moderador debe abstenerse de tomar partido en las discusiones que puedan presentarse yse asegurará de que, en caso de que haya varias alternativas u opiniones, cada una de ellas seesquematice en el pizarrón y sea discutida con objetividad, dándole al grupo la oportunidad dellegar a conclusiones de consenso.

Analista de SistemasEl analista de sistemas tiene la responsabilidad de preguntarles a los usuarios participantesacerca de su trabajo y requerimientos, con el fin de ir tomando notas y dibujando en el pizarrónmodelos parciales, tanto de datos como de procesos, que representen las afirmaciones hechaspor los usuarios. Al terminar las sesiones de trabajo, el analista también se encargará deintegrar los modelos parciales trazados durante el día 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 sesión de trabajo.

UsuariosEn las sesiones JAD deben participar tanto los representantes funcionales del proyecto comogerentes, supervisores y usuarios directos que estén en capacidad de aportar elementos derelevancia para el tema a discutir en las sesiones de trabajo y que, dadas sus experiencias,puedan enriquecer el estudio que se realiza.

Profesionales o ExpertosDependiendo del tema a discutir en una sesión de trabajo JAD y, especialmente, en reuniones

donde el interés se centre en diseño más que en análisis, puede resultar sumamenteconveniente invitar a especialistas como, por ejemplo, al diseñador de bases de datos, alconsultor de telecomunicaciones, y otros. La participación de estos especialistas puede ayudar a realizar preguntas más concretas que las que pudiese hacer el analista de sistemas.

El Ciclo de JAD

Por lo general, la aplicación de la técnica JAD sigue los siguientes pasos:

• Planificación de las sesiones

• Publicación del calendario de reuniones

• Adiestramiento de participantes

• Sesiones de trabajo JAD

15




Planificación de las Sesiones

Todo el conjunto de sesiones JAD que se llevarán a cabo para un proyecto deben ser cuidadosamente planificadas. En un primer paso se elaborará un plan inicial, en el cual seestablecerá cuántas reuniones se realizarán, que áreas del negocio o del sistema se discutiránen cada una de ellas, quiénes son las personas más calificadas para la discusión de cadatema, cuántas sesiones de adiestramiento habrá que realizar, durante qué período deberánrealizarse. Con este plan inicial se procederá a contactar a los invitados y a reservar lasfacilidades necesarias para llevar a cabo las reuniones. Una vez confirmados los participantes ylos recursos, se elaborará el calendario de todas las reuniones. Normalmente, laresponsabilidad de las tareas de planificación de las sesiones JAD recae en el coordinador omoderador.

16




Elaboración del Calendario de Reuniones

Una vez preparado el calendario de cada una de las sesiones, éste debe hacerse público,enviando una copia a cada uno de los invitados, con el fin de que recuerden las fechas en quesu presencia será necesaria

Adiestramiento de Participantes

De acuerdo con las fechas fijadas en el calendario de sesiones JAD, se irán cumpliendo lassesiones de entrenamiento. En estas sesiones se orientará a los usuarios que participarán enlos ejercicios JAD en el uso de las herramientas y técnicas de modelaje de procesos y datos yse demostrará cómo el uso de esas herramientas y técnicas facilitará la comunicación precisade sus requerimientos.En estas sesiones se les enfatizará a los invitados la necesidad de venir a las sesiones JAD detrabajo debidamente preparados con copias de cada documento o reporte utilizado, manualesde procedimientos y cualquier otro material pertinente al tema que será discutido.Normalmente, las sesiones de entrenamiento las dirige el analista de sistemas, haciendo usodel material didáctico (transparencias y notas) preparados para tal fin

Sesiones de Trabajo JAD

Durante las sesiones JAD de trabajo se cumplirán las tareas de análisis y diseño planificadas,con la participación activa de los usuarios y demás invitados. En estas sesiones, a medida quevan cubriéndose diferentes aspectos, se irán elaborando modelos de procesos y datos enborrador en el pizarrón o en los rotafolios; cada uno de estos pequeños modelos deberá ser confirmado y validado por los participantes. Después de concluida la reunión con los usuarios,los modelos en borrador se pondrán en limpio, preferiblemente con la herramienta CASE (si sedispone de ella), ya que ésta permitirá ir haciendo el trabajo de integración de los modelos y,además, permitirá detectar las posibles discrepancias o inconsistencias que puedan existir entre uno o más grupos de usuarios.

La sesión de trabajo JAD concluirá con la revisión de los modelos puestos en limpio o

procesados por el CASE, con el fin de permitir que los participantes puedan confirmar la validezde éstos o rectificar aquellos puntos que presenten inconsistencias o discrepancias.

Normalmente, una sesión de trabajo JAD se inicia temprano en la mañana, con la etapa dediscusión, la cual se termina a media tarde, para que el equipo de desarrollo pueda poner "enlimpio" las conclusiones de la reunión. Se concluye a primera hora del siguiente día, con laetapa de validación que, normalmente, resulta una reunión bastante corta (menos de 1 hora).

Beneficios de la Técnica JAD

La técnica 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 ladefinición de requerimientos se hace a través de entrevistas directas se invierte una cantidadenorme de tiempo, resulta muy difícil validar los modelos con cada entrevistado, algunasentrevistas resultan improductivas por cuanto no añaden nada adicional a lo aportado por otrosentrevistados, y resulta complejo conciliar las discrepancias o diferencias que puedan existir entre las afirmaciones hechas por diferentes usuarios.

Dado que es fundamentalmente una técnica de trabajo en equipos, la técnica JAD eliminatodas 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 análisis o diseño, pues en una sola sesión pueden participar todoslos interesados en una misma área

• Mejora las comunicaciones, pues todos los modelos derivados trazados en lassesiones de trabajo se validan con sus participantes.

17




• Crea sentido de consenso y participación, pues, durante las sesiones de trabajo, elusuario directo tiene la oportunidad de presentar y discutir sus puntos de vista y problemas.

• Facilita la identificación de problemas o inconsistencias, pues cualquier discrepanciaentre opiniones puede aclararse en las propias reuniones de trabajo.

• Mejora la calidad de los productos, pues será posible definir en forma más completa losverdaderos requerimientos de los usuarios.

Requerimientos para el Uso de la Técnica JAD

Las sesiones JAD, si bien permiten reducir la duración de las etapas de análisis y diseño,requieren una excelente planificación, de tal forma que los diferentes usuarios sean avisadosde las reuniones con la debida anticipación y asistan a éstas con todos los materialesnecesarios (muestras de formularios, de reportes, y otros). Asimismo, dado que el objetivofundamental de las sesiones JAD es agilizar el proceso, en cada sesión de trabajo debe existir un moderador o facilitador de la reunión que estimule el uso productivo del tiempo y evite

repetición de conceptos o debates improductivos.

El objetivo central de la técnica JAD es utilizar en la forma más eficiente posible los recursosdisponibles para el diseño de sistemas; la sola aplicación de la técnica, sin embargo, nogarantiza que tales objetivos se cumplan; para ello es necesario que se cumplan ciertascondiciones en la realización de las sesiones, como son

• Debe cumplirse con la sesión de entrenamiento, con el fin de asegurar que todos losparticipantes entiendan su rol.

• Debe contarse con las facilidades de reunión: salón de reuniones, pizarrón, y otros.

• Deben minimizarse las interrupciones, con el fin de que pueda aprovecharse el tiempo detodos los participantes.

Proceso de Análisis Jerárquico (AHP)

Esta técnica tiene por objetivo resolver problemas cuantitativos, para facilitar el pensamiento

analítico y las métricas. 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 fácilmente a una cantidad pequeña de requerimientos, sin

embargo, para un volumen grande, esta técnica no es la más adecuada.

Ventajas y desventajas de cada una de las técnicas utilizadas en las etapas de laIngeniería de Requerimientos.

Técnica Ventajas Desventajas• Mediante ellas se obtiene una

gran cantidad de información

correcta a través del usuario.

• La información obtenida al

principio puede ser redundante o

incompleta.

18




Técnica Ventajas Desventajas

Entrevistas y

Cuestionarios

• Pueden ser usadas para

obtener un pantallazo del

dominio del problema.

• Son flexibles.

• Permiten combinarse con

otras técnicas.

• Si el volumen de información

manejado es alto, requiere

mucha organización de parte del

analista, así como la habilidad

para tratar y comprender el

comportamiento de todos losinvolucrados.

Lluvia de Ideas

• Los diferentes puntos de vista

y las confusiones en cuento a

terminología, son aclaradas por

expertos.

• Ayuda a desarrollar ideas

unificadas basadas en la

experiencia de un experto.

•

• Es necesaria una buena

compenetración del grupo

participante.

Prototipos

• Ayudan a validar y

desarrollar nuevos

requerimientos.• Permite comprender aquellos

requerimientos que no están muy

claros y que son de alta

volatilidad.

• El cliente puede llegar a

pensar que el prototipo es una

versión del software que serádesarrollado.

• A menudo, el desarrollador

hace compromisos de

implementación con el objetivo

de acelerar la puesta en

funcionamiento del prototipo

Análisis Jerárquico • Permite determinar el grado

de importancia de cada

requerimiento.

• Ayuda a identificar conflictos

en los requerimientos.

• Muestra el orden en quedeben ser implementados los

requerimientos.

• Debe construirse un estándar

claro de evaluación, que incluya

la participación del cliente.

Casos de Uso

• Representan los

requerimientos desde el punto de

vista del usuario.

• Permiten representar más de

un rol para cada afectado.

• Identifica requerimientos

estancados, dentro de un

conjunto de requerimientos.

• En sistemas grandes, toma

mucho tiempo definir todos los

casos de uso.

• El análisis de calidad

depende de la calidad con que se

haya hecho la descripción inicial.

JAD • Reduce el tiempo de análisis o

diseño, pues en una sola sesiónpueden participar todos losinteresados en una misma área

• Mejora las comunicaciones,pues todos los modelos derivadostrazados en las sesiones detrabajo se validan con susparticipantes.

• Crea sentido de consenso yparticipación, pues, durante lassesiones de trabajo, el usuario

directo tiene la oportunidad depresentar y discutir sus puntos devista y problemas.

• Debe cumplirse con la sesión de

entrenamiento, con el fin deasegurar que todos losparticipantes entiendan su rol.

• Debe contarse con las facilidadesde reunión: salón de reuniones,pizarrón, y otros.

• Deben minimizarse lasinterrupciones, con el fin de quepueda aprovecharse el tiempo detodos los participantes.

19




Técnica Ventajas Desventajas

• Facilita la identificación deproblemas o inconsistencias, puescualquier discrepancia entreopiniones puede aclararse en las

propias reuniones de trabajo.

• Mejora la calidad de losproductos, pues será posibledefinir en forma más completa losverdaderos requerimientos de losusuarios.

Resumen

Es muy importante mencionar que el poder formular una especificación de requerimientoscompleta y consistente, es un paso muy importante para evitar cometer errores en la definiciónde los requerimientos, ya que los mismos pueden resultar muy caros de corregir una vezdesarrollado el sistema. De ahí, la vital importancia que tiene la ingeniería de requerimientos engenerar una adecuada especificación que contemple claramente y sin ambigüedades losrequerimientos del sistema a desarrollar, con el fin primordial de evitar que los proyectosfracasen debido a una mala elaboración de la definición y especificación de requerimientos.

El proceso de la Ingeniería de Requerimientos sirve para recopilar la información necesariapara establecer la funcionalidad que se quiere alcanzar con el sistema. Para ello, se debe decontar con buenos métodos y técnicas para hacerlo, además de una comunicación fluida yconstante con el cliente, ya que los requerimientos deben reflejar las necesidades reales que elcliente quiere satisfacer. Las revisiones deben involucrar al cliente y al staff de contratistas para

validar los requerimientos del sistema. Como proceso, la administración de requerimientos esfundamental en todo proyecto de desarrollo de software, ya que se debe de contar con unaespecificación clara y completa desde las fases iníciales para no tener problemas posterioresque implican un retraso en el cronograma, un presupuesto erróneo, o hasta la posiblecancelación del proyecto. Es importante que el documento que se obtenga de esta etapa seaun reflejo real del acuerdo de las partes involucradas. Hay que notar el aporte que ha venido aproporcionar la utilización de técnicas como la especificación, la luvia de ideas y el desarrollode prototipos, que ayudan a definir requerimientos de una manera concisa y real.

También es necesario resaltar y dar a conocer que alrededor del mundo existen estándaresenfocados en el mejoramiento de los procesos de desarrollo de software, citando entre ellos alos estándares propuestos por la IEEE (Instituto de Ingenieros Eléctricos y Electrónicos), 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 administración del proyectos)y las ya conocidas normas ISO, en cuyas normas también se involucran apartados referentes aldesarrollo de software.

Finalizando ¿Quienes hacen Ingeniería de Requerimientos? ¿Es Muy difícil encontrar a unapersona..?. Que sepa entrevistar, escuchar, cuestionar (pensamiento crítico), 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 lasolución ¿Existen? En mi opinión se puede formar…

20




Bibliografía y enlaces recomendados

Pressman, Roger S. 2006, “Ingeniería del Software: Un enfoque práctico”, Sexta edición,México DF, Editorial McGraw Hill.

Sommerville Ian, 2005, “Ingeniería del Software”, Sétima edición, México DF, EditorialPearson. http://standards.ieee.org/reading/ieee/std_public/description/se/610.121990_desc.html Herrera J., Lizka Johany (2003) “Ingeniería de Requerimientos, Ingeniería de Software”,Recuperado el 25 de mayo de 2006 en:http://www.monografias.com/trabajos6/resof/resof.shtml Montes Meyhuay Magno, “Ingeniería de Requerimientos”, recuperado el 25 de mayo de 2006en: 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

21

http://standards.ieee.org/reading/ieee/std_public/description/se/610.121990_desc.html

http://www.monografias.com/trabajos6/resof/resof.shtm

http://www.proamazonia.gob.pe/bpa/ingenieria_requerimientos.htm

http://www.rational.com.ar/herramientas/requisitepro.html

http://standards.ieee.org/reading/ieee/std_public/description/se/610.121990_desc.html

http://www.monografias.com/trabajos6/resof/resof.shtm

http://www.proamazonia.gob.pe/bpa/ingenieria_requerimientos.htm

http://www.rational.com.ar/herramientas/requisitepro.html




MINISTERIO POPULAR PARA LA EDUCACION SUPERIORUNIVERSIDAD POLITECNICA MARACAIBOMARACAIBO EDO. ZULIADEPARTAMENTO DE INFORMATICA.UNIDAD CURRICULAR: INGENIERIA DE REQUERIMIENTOS

MÓDULO: FUNDAMENTOS DE INGENIERIA DE REQUISITOS Y ANALISIS

GUIA DE LA UNIDAD IREQUERIMIENTOS DE SOFTWARE

PROFESOR: ALFONSO R. GALEA BRACHO

Analisis y Tecnicas de Recoleccion de Datos

Documents

Transcript of Analisis y Tecnicas de Recoleccion de Datos