Taller # 5 - Ing de Requisitos

Taller # 5: Ingeniería de requisitos Ingeniería del software: un enfoque práctico Por Jeancarlo Fontalvo 1. ¿Por qué muchos desarrolladores de software no ponen atención suficiente a la ingeniería de requerimientos? ¿Existen algunas circunstancias que puedan ignorarse? Rta: Existen muchas razones para que los desarrolladores tomen esta decisión que casi siempre se debe a que los requisitos son dinámicos, entonces al menos que se utilice un enfoque eficiente y ágil que haga al equipo versátil en esta tarea. Otra, puede ser que es una actividad que requiere de un alto grado de análisis, lo que demanda tiempo, es preferible solo tomar los requisitos que afectaran directamente al negocio y avanzar en las próximas iteraciones. También se piensa que retrasa la etapa más divertida que es el modelado y la codificación del proceso de software, pero se sabe que es fundamental. 2. El lector tiene la responsabilidad de indagar los requerimientos de un cliente que dice estar demasiado ocupado para tener una reunión. ¿Qué debe hacer? Rta:  Debe prepararse con la información pertinente del negocio  Tratar de solicitar una persona auxiliar que conozca el negocio, su funcionamiento, y tenga una idea más técnica de las necesidades del cliente, como un Product Owner  Procurar de tener una visión del proyecto que satisfaga dichos requisitos 3. Analice algunos de los problemas que ocurren cuando los requerimientos deben indagarse para tres o cuatro clientes distintos Rta: Muchos de los problemas que nos enfrentaremos como Ingenieros de software es la indagación de requisitos conflictivos. Estos problemas se dan en primera por la oposición o “conflicto” de algunos participantes del negocio. Si bien esto puede parecer un problema en primera, también brinda sutilmente una riqueza “visual” al proyecto, por la accesibilidad de varios puntos de vistas. Ahora, lo ideal para tal situación es hacer una retroalimentación con el grupo conflictivo e implementar la

negociación de requisitos, y obtener la mejor estrategia para el proyecto. 4. ¿Por qué se dice que el modelo de requerimientos representa una fotografía instantánea del sistema en el tiempo? Rta: Considero, que constituye una visión de lo que será el proyecto ya que se identifican las ideas, y se concibe el software de manera rápida, para suponer lo que yacerá a largo plazo el proyecto. 5. Suponga que ha convencido al cliente (es usted muy buen vendedor) para que esté de acuerdo con todas las demandas que usted hace como desarrollador. ¿Eso lo convierte en un gran negociador? ¿Por qué? Rta: La verdad, es relativo. Si en esa situación el cliente también se dispone convencido y acepta con entusiasmo, además de que siente que gana, durante dicha tarea; entonces se puede decir que soy un gran negociador. Mas sin embargo, si el cliente quedo en dudas o se siente desplazado de la negociación, entonces estaré siendo egoísta, y no cumpliría con uno de los principios del manifiesto ágil, por tanto sería un pésimo negociador. 6. Desarrolle al menos tres “preguntas libres de contexto” adicionales que podría plantear a un participante durante la concepción. Rta:  ¿Por qué nace la idea de hacer e implementar un proyecto de software en la empresa?  ¿Qué espera(n) usted(s) del proyecto a desarrollar?  ¿Cómo cree que afectará el software al negocio? 7. Desarrolle un “kit” para recabar requerimientos. Debe incluir un conjunto de lineamientos a fin de llevar a cabo la reunión para recabar requerimientos y los materiales que pueden emplearse para facilitar la creación de listas y otros objetos que ayuden a definir los requerimientos. Rta: Especificación de JRC2 Kit: - Lineamientos:  Simpleza y puntualidad: Antes que todo, se debe representar una buena imagen laboral ante el cliente, es fundamental la puntualidad a la hora de llegar a citas de intercambio de información.



-

Indagación del Negocio a través de la preparación: Es preferible saber de forma razonable, conceptos y términos del negocio, ya que facilita mucho la comunicación.  Apoyarse en el uso de las TIC: La obtención tradicional de los requisitos, se podía plasmar en lápiz y papel, pero eso ha cambiado; como actualizados que somos, debemos hacer uso de herramientas que mejoren y optimicen dicha actividad a través de las TICS.  Disponibilidad de facilitadores: Un facilitador evita la tensión entre los participantes, y sirve de interfaz para el flujo de información entre el cliente y el equipo. Herramientas:  Si se prefiere el uso del lápiz y papel, se puede, aunque se debe pensar en TIC en un futuro.  Tablero y videobeam para presentar lógicas del negocio por parte del cliente.  Cámara de video y fotográfica.

8. Desarrolle un caso de uso completo para uno de las actividades siguientes: a) Hacer un retiro de efectivo en un cajero automático Rta en la página siguiente.

9. 9. ¿Qué representan las “excepciones” en un caso de uso? Rta: Son situaciones que inducen comportamientos ajenos al flujo normal o “feliz” de uso, en el sistema. Aunque no correspondan al flujo normal, se deben evaluar, analizar, validad e implementar (controlar y satisfacer). 10. Describa con sus propias palabras lo que es un patrón de análisis. Rta: Como su nombre lo indica, surgieren la solución parcial o completa de una situación, problemática, dominio o modelos y análisis de requisitos que se comportan como patrones o se han vivido y solucionada parcial o totalmente anteriormente. 11. Con el formato presentado en la sección 5.5.2, sugiera uno o varios patrones de análisis para los siguientes dominios de aplicación: a) Software de contabilidad. b) Software de correo electrónico. c) Navegadores de internet. d) Software de procesamiento de texto. e) Software para crear un sitio web. f) El dominio de aplicación que diga su profesor Rta: Escojo en primera a los navegadores web, que tienen que modelar siempre un protocolo de comunicación, por el que se comunican con los servidores y permiten al usuario navegar en internet por peticiones y respuestas. 

Nombre del patrón: Protocolito



 

  

Intención: El patrón trata de modelar la interacción, y flujo que se da en el protocolo de comunicación HTTP que debe satisfacer el navegador web. La motivación: Servir de interfaz en una solicitud de cliente (petición) y respuesta de servidor. Solución: Definir un conjunto de pasos que modelen el protocolo. Dicho modelo debe poseer por lo menos dos identificadores (cliente y servidor) implementados en clases. Los objetos deben proveer métodos de comunicación e interfaces para la transmisión y transporte de Hipertexto y Archivos. Consecuencias: El patrón facilita la tarea de modelar el protocolo, apoyándose en las clases de cliente y servidor. Diseño: Uso del patrón de diseño Comando y Visitante Los usos conocidos: Todos los navegadores, lo deben implementar como requisito.

12. ¿Qué significa ganar-ganar en el contexto de una negociación durante la actividad de ingeniería de los requerimientos? Rta: Que tanto el cliente y el equipo, se ven beneficiados por un conjunto de negociaciones, que permiten la satisfacción del cliente y condiciones buenas de trabajo para el equipo.

13. ¿Qué piensa que pasa cuando la validación de los requerimientos detecta un error? ¿Quién está involucrado en su corrección? Rta: Por obviedad se debe corregir. Se puede hacer por medio de la retroalimentación conjunta que se hace con el cliente que es quien que realiza la aclaración y corrección indirecta del requerimiento.