Semana_4_ Unidad_2_Tema_1_2 by gris rodriguez

Fundamentos de Ingeniería de Software

Educación a distancia

Ingeniería en Sistemas Computacionales Fundamentos de Ingeniería de Software

Semana 4. Unidad 2. Ingeniería de requisitos. 2.1. Tareas de la Ingeniería de Requisitos 2.2. Técnicas de la Ingeniería de Requisitos

Antología realizada por: M.C. Gricelda Rodríguez Robledo

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

C ONTENIDO

Tema 2.1

Tareas de la Ingeniería de Requisitos ..................................................................................... 2

2.1.1 Los Requerimientos ....................................................................................................................... 2 2.1.1.1 Tipos de Requerimientos ........................................................................................................ 3 2.1.1.2 Características de un Requerimiento ...................................................................................... 3 2.1.1.3 Dificultades para definir los requerimientos .......................................................................... 3 2.1.2 Ingeniería de requerimientos ......................................................................................................... 4 2.1.2.1 Importancia de la ingeniería de requerimientos .................................................................... 5 2.1.2.2 Tareas o Actividades de Ingeniería de Requisitos ................................................................. 5 2.1.2.3 Evolución de los requerimientos ............................................................................................ 7 2.1.2.4 Dificultades para definir los requerimientos ......................................................................... 8

2.2 Técnicas de la Ingeniería de Requisitos ...................................................................................... 8 2.2.1 Técnicas y Herramientas utilizadas en las actividades de Ingeniería de Requerimientos: ........ 8 Referencias ............................................................................................................................................... 26

Semana 4

Educación a distancia

Competencia específica a desarrollar Desarrollar las habilidades para  identificar las diferentes técnicas que se aplican para la obtención de  requerimientos de software.

Semana 4

Fundamentos de Ingeniería de Software

Intención didáctica. Elaborar un mapa mental de la Ingeniería de requisitos. Investigar las diferentes tareas que se realizan en la ingeniería de requerimientos para la documentación de proyectos de desarrollo.

Educación a distancia

Fundamentos de Ingeniería de Software

T EMA 2.1 T AREAS DE LA I NGENIERÍA DE R EQUISITOS

2.1.1 L OS R EQUERIMIENTOS Un requerimiento puede definirse como un atributo necesario dentro de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales. A nivel general los requerimientos pueden clasificarse como requerimientos indicados o reales. Los requerimientos indicados son los entregados por el usuario al comienzo del proyecto, en tanto que los requerimientos reales son aquellos que reflejan la satisfacción de las necesidades del usuario en un sistema en particular. El proceso para convertir los requerimientos indicados en requerimientos reales consisten en un proceso de filtrado según el significado y otros aspectos según se considere. A continuación se presenta la definición existente en el glosario de la IEEE de lo que es un “Requerimiento”: “Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo”. (Std 610.12-1900, IEEE) “Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal”. (Std 610.12-1900, IEEE) También, Ian Sommerville presenta una definición acerca de lo que es un “Requerimiento”: “Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste”. (Sommerville, 2005) Analizando las definiciones anteriores, un requerimiento es una descripción de una condición o capacidad que debe cumplir un sistema, ya sea derivada de una necesidad de usuario identificada, o bien, estipulada en un contrato, estándar, especificación u otro documento formalmente impuesto al inicio del proceso.

Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia 2.1.1.1 T I P O S

R E QU E R I M I E N T O S

Los requerimientos de software pueden dividirse en 2 categorías: requerimientos funcionales 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 ¿Cómo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte del código del sistema. Por otra parte los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, auditabilidad y otros.

2.1.1.2 C A R A CT E R Í ST I C A S

DE UN

R E Q U E R I M I E NT O

Es importante no perder de vista que un requerimiento debe ser: Especificado por escrito: Como todo contrato o acuerdo entre dos partes. Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe si se cumplió con él o no? Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector

2.1.1.3 D I FI CU LT A D E S

P A R A D E F I N I R L OS R E Q U E R I M I E NT O S

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

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

2.1.2 I NGENIERÍA

DE REQUERI MIENTOS

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema 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. Algunos otros conceptos de ingeniería de requerimientos son: “Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software”. (Pressman, 2006) “La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema”. (Sommerville, 2005)

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 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 obtención y análisis de requerimientos, su especificación formal, para finalizar con el subproceso de validación donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.

Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia 2.1.2.1 I M P OR T A N CI A

D E LA I N G E N I E R Í A D E R E Q U E R I M I E NT O S

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): Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, y otros) Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso. Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

2.1.2.2 T A R E A S

A CT I V I D A D E S

I NG E NI E R Í A

R E QU I SI T OS

El proceso de la ingeniería de requisitos se lleva a cabo a través de cuatro distintas funciones; extracción, análisis, especificación, validación y evolución,. Están dirigidas a definir lo que el cliente quiere, y todas sirven para establecer una base solida respecto al diseño y la construcción que obtendrá el cliente.

E X T R A C C I Ó N (A N Á L I S I S D E L P R O B L E M A ) Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar y otros. Es

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuán bien éste satisfaga las necesidades del cliente.

A N Á L I SI S (E V A L U A C I Ó N Y N E G O C I A C I Ó N D E L O S R E QU E R I M I E NT O S ) Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos

E SP E C I F I C A C I Ó N En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientos

VALIDACIÓN La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos. Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificación de requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso.

Semana 4

Educación a distancia

2.1.2.3 E V O LU CI ÓN

Fundamentos de Ingeniería de Software

D E LO S R E QU E R I M I E NT O S

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuario 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él que 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.

Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia 2.1.2.4 D I FI CU LT A D E S

P A R A D E FI N I R L OS R E Q U E R I M I E NT O S

Durante la etapa de especificación de requerimientos se pueden presentar muchos inconvenientes los cuales son importantes de identificar y prevenir, a continuación se presenta un listado con los problemas más comunes en este proceso: Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles de expresar en palabras (el lenguaje es ambiguo). La cantidad de requerimientos en un proyecto puede ser difícil de manejar. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. El usuario no puede explicar lo que hace Tiende a recordar lo excepcional y olvidar lo rutinario Hablan de lo que no funciona Los usuarios tienen distinto vocabulario que los desarrolladores Usan el mismo término con distinto significado

2.2 T ÉCNICAS DE LA I NGENIERÍA DE R EQUISITOS Existen varias técnicas para efectuar la ingeniería de requerimientos (Herrera, 2003). Es importante resaltar que estas técnicas pueden ser aplicables a las distintas fases del proceso, 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.

2.2.1 T É CN I CA S R E QU E R I M I E N T O S :

HERRAMIENTAS

UTILIZADAS

LA S

A CT I V I D A D E S

I NG E N I E R Í A

Entrevistas y cuestionarios Sistemas existentes Grabaciones de video y de audio Brainstorming (tormenta de ideas) Arqueología de documentos Aprendiz. Observación Run Use Case WorkShop (talleres de trabajo basados en los Casos de Uso) Prototipos Análisis FODA (Fortalezas, Oportunidades, Debilidades y Amenazas) Cadena de valor Modelo de clase conceptual, Diagrama Conceptual, Diagrama de Clases Conceptual Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Diagrama de pescado (Ishikawa Diagram, Cause-and-Effect o Fishbone Diagram) Glosario Diagrama de actividad Documento ESRE, Casos de uso Lista de requerimientos Casos de uso Casa de calidad o QFD (Quality Function Deployment) Checklist (lista de verificación)

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, la técnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose.

E N T R E V I ST A S Y C U E S T I O N A R I O S . Dentro de una organización, la entrevista es la técnica más significativa y productiva de que dispone el analista para recolectar datos. En otras palabras, la entrevista es un intercambio de informació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 de satisfacerlas, así como consejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso 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 los documentos necesarios (Organización). Fijar un límite de tiempo y preparar la agenda para la entrevista. (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. Explicar con toda amplitud el propósito y alcance del estudio (Honestidad). Explicar la función propietaria como analista y la función que se espera conferir al entrevistado. (Imparcialidad). Hacer preguntas específicas para obtener respuestas cuantitativas (Hechos). Evitar las preguntas que exijan opiniones Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

interesadas, subjetividad y actitudes similares (Habilidad). Evitar el cuchicheo y las frases carentes de sentido (Claridad). Ser cortés, absteniéndose de emitir juicios de valores. (Objetividad). Conservar el control de la entrevista, evitando divagaciones y los comentarios al margen de la cuestión (Habilidad). Escuchar atentamente lo que 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 su conformación, correcciones o adiciones. (Profesionalismo). Archivar los resultados de la entrevista 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ísticas de 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 son importantes. La información cualitativa está relacionada con opinión, política y descripciones narrativas de actividades o problemas, mientras que las descripciones cuantitativas tratan con números frecuencia, o cantidades. A menudo las entrevistas pueden ser la mejor fuente de información cualitativa, los otros métodos tiende a ser más útiles en la recolección de datos cuantitativos. Son valiosas las opiniones, comentarios, ideas o sugerencia en relación a cómo se podría hacer el trabajo; la entrevista a veces es la mejor forma para conocer las actividades de las empresas. La entrevista puede descubrir rápidamente malos entendidos, falsa expectativa o incluso 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 un cuestionario. E. Determinación del tipo de Entrevista. La estructura de la entrevista varía. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de preguntas sin estructura, con una sesión 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 también 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 Semana 4

Fundamentos de Ingeniería de Software

Educación a distancia

tipo de preguntas son siempre apropiadas, además que ayudan a entender la perspectiva del afectado y no están influenciadas por el conocimiento de la 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? ¿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 su preparación para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados 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 cuestionario y 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 las Ejemplo: obtener la información sobre las características de diseño críticas para los características de diseño críticas para los empleados. empleados. " La experiencia le ha proporcionado una amplia "Algunos empleados han sugerido que la mejor visión en cuanto a la forma en la que la empresa forma para hacer eficiente el procesamiento de maneja los pedidos..." pedidos es instalar un sistema de computadora que maneje todos los cálculos..." Me gustaría que usted contestara algunas preguntas Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Bajo estas circunstancias ¿apoyaría usted el específicas en relación en lo anterior: desarrollo de un sistema de este tipo? -¿Qué etapas trabajan bien? ¿Cuáles no? -¿En donde se presenta la mayor parte del problema? - ¿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 niveles gerenciales y de empleados que puedan proporcionar la mayor parte de la información útil para el 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 la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación del objetivo de una entrevista específica 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 través 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 método comenzó en el ámbito de las empresas, aplicándose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos métodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se extendió a otros ámbitos, incluyendo el mundo de desarrollo de sistemas; básicamente se busca que los involucrados en un proyecto desarrollen su creatividad. A esta técnica se le conoce también como torbellino de ideas, tormenta de ideas, desencadenamiento de ideas, Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

movilización verbal, bombardeo de ideas, sacudidas de cerebros, promoción 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 críticas, hasta que no agoten las ideas, ya que actuaría como un inhibidor. 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 la calidad". Las mejores ideas aparecen tarde en el periodo de producción de ideas, será más fácil que encontremos las soluciones y tendremos más variedad sobre la que elegir. La producción de ideas en grupos puede ser más efectiva que la individual. Tampoco debemos olvidar que durante las sesiones, las ideas de una persona, serán 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 sesión. Debe ser un experto en pensamiento creador. Su función 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 críticas. 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. Además, es la persona 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, las reproduce 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 no haya diferencias jerárquicas. Las personas que componen el grupo deben estar motivadas para solucionar el problema, y con un ambiente que propicie la participación de todos. Todos pueden sentirse confiados y con la sensación de que pueden hablar sin que se produzcan críticas. Todas las ideas en principio deben tener el mismo valor, pues cualquiera de ellas puede ser la clave para la solución. Es necesario 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 los bloqueos que paralizan la ideación: como son nuestros hábitos o ideas preconcebidas, el desánimo o falta de confianza en si mismo, el temor y la timidez.

Las fases de aplicación en el Brainstorm son: Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Descubrir hechos. Al menos con un día de antelación, 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 sesión comienza con 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 el problema, delimitándolo, precisándolo y clarificándolo. A continuación se plantea el problema, recogiendo las experiencias que se poseen o consultando documentación. Cuando es complejo, conviene dividirlo en partes. Aquí es importante la utilización del análisis, desmenuzando el problema en pequeñas 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. Además, es útil cuando se ha trabajado mucho, alejarse del problema, pues es un buen momento para que se produzcan asociaciones. Muchas de las nuevas ideas serán ideas antiguas, mejoradas o combinadas con varias ya conocidas. Al final de la reunión, el director da las gracias a los asistentes y les ruega que no abandonen el problema, 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ás interesantes. La selección se realiza desechando las ideas que no tienen valor y se estudia si son válidas las que se consideran interesantes. Lo mejor es establecer una lista de criterios de conveniencia para cada idea. Se seleccionan las ideas más útiles y si es necesario se ponderarán. Pueden realizarlo los mismos miembros del grupo o crear otros para esta tarea; la clasificación debe hacerse por categorías (tarea que corresponde al director). Se presentan las ideas de forma atractiva, haciendo uso de soportes visuales.

E N C U E ST A S . Hoy en día la palabra "encuesta" se usa más frecuentemente para describir un método de obtener información de una muestra de individuos. Esta "muestra" es usualmente sólo una fracción de la población bajo estudio. Aún así, todas las encuestas tienen algunas características en común. La información es recogida usando procedimientos estandarizados de manera que a cada individuo se le hacen las mismas preguntas más o menos de la misma manera. La intención de la encuesta no es describir los individuos particulares quienes, por azar, son parte de 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 es que los participantes individuales nunca puedan ser identificados al reportar los hallazgos. Todos los resultados

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

de la encuesta deben presentarse en resúmenes completamente anónimos, tal como tablas y gráficas estadísticas. Tamaño de la muestra. Muchas veces depende de los recursos profesionales y fiscales disponibles. Los analistas frecuentemente encuentran que una muestra de tamaño moderado es suficiente estadística y operacionalmente. Las encuestas pueden ser clasificadas por su método de recolección de datos. Las encuestas por correo, telefónicas y entrevistas en persona son las más comunes. En los métodos más nuevos de recoger datos, la información se introduce directamente a la computadora ya sea por un entrevistador adiestrado o aún por la misma persona entrevistada. Las entrevistas en persona en el hogar u oficina de un participante son mucho más caras que las encuestas telefónicas o por correo. Estas pueden ser 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ñadas 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 opinión o que se preocupe por los resultados debe primero decidir si las preguntas que se hacen son justas.

O B SE R V A C I Ó N . Otra técnica útil para el analista en su progreso de investigación, consiste en observar a las personas cuando efectúan su trabajo. Como técnica de investigación, la observación tiene amplia 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 y como miembros de la organización. El propósito de la organización es múltiple: permite al analista determinar que se está haciendo, como se está haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, dónde se hace y por que se hace. Observar las operaciones le 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 su interacción por aparte del propio analista. Quizá esta alternativa tenga poca importancia para el análisis de sistemas, puesto que resulta casi imposible reunir las condiciones necesarias. Segundo, el analista puede observar una operación sin intervenir para nada, pero estando la persona observada enteramente consciente de la observación. Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Por último, puede observar y a la vez estar en contacto con las personas observadas. La interacció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 para ello. 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 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 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 objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un "diseño rápido". El diseño rápido se centra en una representación de aquellos aspectos del software que serán Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción 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 iteración tiene lugar a medida que el prototipo es "puesto a punto" para satisfacer las necesidades del cliente y permitiendo al mismo tiempo una mejor comprensión del problema por 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 este sentido, el prototipo puede ser visto como una aceptación tácita de que los requerimientos no son totalmente conocidos o entendidos antes del diseño y la implementación. El prototipo rá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 y mantenimiento. La experiencia ha demostrado que esta distinción es arbitraria y va en contra de la realidad ya que la mayor parte del costo del software ocurre después 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 más maduros. Este proceso continúa hasta que se haya desarrollado el producto final. La adopción de esta óptica elimina la distinción arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad que afecta las estrategias para la estimación de costos, enfoques de desarrollo y adquisición de productos.

S E S I O N E S JAD (D E S A R R O L L O P A R T I C I P A T I V O D E AP L I C AC I O NE S ) La técnica Joint Application Development (JAD) o desarrollo participativo de aplicaciones tiene como objetivo central facilitar la cooperación 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 características de los sistemas objeto de estudio y, sobre la marcha de las mismas discusiones, se van trazando los modelos que permitirán 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: revisión, formalización y validación

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

Las Sesiones JAD de Adiestramiento Las sesiones JAD de adiestramiento tienen como objetivo fundamental orientar a los usuarios que participarán en los ejercicios JAD en el uso de las herramientas y técnicas de modelaje de procesos y datos y demostrar cómo el uso de esas herramientas y técnicas facilitarán la comunicación precisa de sus requerimientos. Así pues, la sesión JAD de adiestramiento se hace con el fin de que los usuarios puedan participar productivamente en la elaboración y revisió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, a medida que van discutiéndose diferentes aspectos del sistema objeto de estudio, se van elaborando modelos de procesos y datos en borrador, haciendo uso de un pizarrón 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 sesión de trabajo JAD, después de concluida la reunión con los usuarios, los modelos borrador se "ponen en limpio"; normalmente, el vehículo más adecuado para ello es una herramienta CASE, 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 Una sesión de trabajo JAD concluye con la revisión 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. 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

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

El Moderador Antes de las sesiones JAD, el moderador o coordinador se encarga de hacer los recordatorios necesarios, con la debida anticipación, para asegurar que todos los invitados asistan puntualmente a las reuniones. Durante la realización de las sesiones, el moderador tiene la responsabilidad de estimular la participación de todos los invitados, asegurar que se haga un uso productivo del tiempo de todos los participantes, evitar la discusión repetitiva de conceptos y detener cualquier debate improductivo. Normalmente, será deseable que algún representante funcional 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 y se asegurará de que, en caso de que haya varias alternativas u opiniones, cada una de ellas se esquematice en el pizarrón y sea discutida con objetividad, dándole 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 pizarrón modelos parciales, tanto de datos como de procesos, que representen las afirmaciones hechas por los usuarios. Al terminar las sesiones de trabajo, el analista también se encargará de integrar 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. Usuarios En las sesiones JAD deben participar tanto los representantes funcionales del proyecto como gerentes, supervisores y usuarios directos que estén 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 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 sumamente conveniente invitar a especialistas como, por ejemplo, al diseñador de bases de datos, al consultor 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. Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

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

Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

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 se establecerá cuántas reuniones se realizarán, que áreas del negocio o del sistema se discutirán en cada una de ellas, quiénes son las personas más calificadas para la discusión de cada tema, cuántas sesiones de adiestramiento habrá que realizar, durante qué período deberán 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 planificación de las sesiones JAD recae en el coordinador o moderador. 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 que su presencia será necesaria Adiestramiento de Participantes De acuerdo con las fechas fijadas en el calendario de sesiones JAD, se irán cumpliendo las sesiones de entrenamiento. En estas sesiones se orientará a los usuarios que participarán en los ejercicios JAD en el uso de las herramientas y técnicas de modelaje de procesos y datos y se demostrará cómo el uso de esas herramientas y técnicas facilitará la comunicación 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 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 que van cubriéndose diferentes aspectos, se irán elaborando modelos de procesos y datos en borrador 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 se dispone 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. Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

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 validez de é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 de discusión, la cual se termina a media tarde, para que el equipo de desarrollo pueda poner "en limpio" las conclusiones de la reunión. Se concluye a primera hora del siguiente día, con la etapa 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 la definición de requerimientos se hace a través de entrevistas directas se invierte una cantidad enorme de tiempo, resulta muy difícil validar los modelos con cada entrevistado, algunas entrevistas resultan improductivas por cuanto no añaden 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 técnica de trabajo en equipos, la técnica 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 análisis o diseño, pues en una sola sesión 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 participación, pues, durante las sesiones de trabajo, el usuario directo tiene la oportunidad de presentar y discutir sus puntos de vista y problemas. Facilita la identificación 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 más completa los verdaderos 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 avisados de las reuniones con la debida anticipación y asistan a éstas con todos los materiales necesarios (muestras de formularios, de Semana 4

Educación a distancia

Fundamentos de Ingeniería de Software

reportes, y otros). Asimismo, dado que el objetivo fundamental 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 recursos disponibles para el diseño de sistemas; la sola aplicación de la técnica, sin embargo, no garantiza que tales objetivos se cumplan; para ello es necesario que se cumplan ciertas condiciones en la realización de las sesiones, como son Debe cumplirse con la sesión de entrenamiento, con el fin de asegurar que todos los participantes 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 de todos 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 la Ingeniería de Requerimientos. Técnica

Entrevistas Semana 4

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.

 Pueden ser usadas para obtener un pantallazo del dominio del problema.



Si el volumen de información manejado es alto, requiere mucha organización de parte 23

Fundamentos de Ingeniería de Software

Educación a distancia Técnica Cuestionarios

Ventajas

Desventajas

 Son flexibles.  Permiten combinarse técnicas.

Lluvia de Ideas

con

del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados.

otras

 Los diferentes puntos de vista y las confusiones en cuento a terminología, son aclaradas por expertos.

 Es

necesaria una buena compenetración del grupo participante.



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



Debe construirse un estándar claro de evaluación, que incluya la participación del cliente.

 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 están muy claros y que son de alta volatilidad.

Prototipos

Análisis Jerárquico

Casos de Uso

Semana 4



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.



En sistemas grandes, toma mucho tiempo definir todos los casos de uso.



Permiten representar más de un rol para cada afectado.



Identifica

El análisis de calidad depende de la calidad con que se haya hecho la

requerimientos

Fundamentos de Ingeniería de Software

Educación a distancia Técnica

Ventajas

Desventajas estancados, dentro de conjunto de requerimientos.

JAD

descripción inicial.



Reduce el tiempo de análisis o  diseño, pues en una sola sesión pueden participar todos los interesados en una misma área

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



Mejora las comunicaciones, pues  todos los modelos derivados trazados en las sesiones de trabajo se validan con sus participantes.  Crea sentido de consenso y participación, pues, durante las sesiones de trabajo, el usuario directo tiene la oportunidad de presentar y discutir sus puntos de vista y problemas.

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



Semana 4



Facilita la identificación 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 más completa los verdaderos requerimientos de los usuarios.

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

Educación a distancia

Fundamentos de Ingeniería de Software

R EFERENCIAS Alfonso R. Galea Bracho (s.f). Guia de la Unidad I de Requerimientos De Software. Universidad Politécnica Maracaibo 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, Editorial Pearson. Consultado en Enero del 2010 en: 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”. Consultado en Enero del 2012 en en:http://www.monografias.com/trabajos6/resof/resof.shtml Montes Meyhuay Magno, “Ingeniería de Requerimientos”. Consultado en Enero del 2012 en: www.proamazonia.gob.pe/bpa/ingenieria_requerimientos.htm Racional RequisitePro. Consultado en Enero del 2012 en: http://www.rational.com.ar/herramientas/requisitepro.html

Semana 4