Ingeniería del software: un enfoque práctico

Taller # 5: Ingeniería de requisitos[pic 1]

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.

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

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

1. ¿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.

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

1. 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?

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

1. Desarrolle un caso de uso completo para uno de las actividades siguientes:

1. Hacer un retiro de efectivo en un cajero automático

Rta en la página siguiente.[pic 2]

[pic 3]

1. ¿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).

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

...