Bogotá - Colombia
Continuando con el post anterior y siguiendo con la siguiente paso etapa de elitacion del modelo para de ingeniería de requerimientos.
Tabla de contenido
Definir las fronteras de la solución
Una vez que se ha alcanzado un acuerdo sobre el problema que se va a construir, es necesario definir un sistema que pueda ser construido para resolver el problema. Para hacer esta tarea debemos comenzar con establecer las fronteras dentro de las cuales se creará el sistema.
Una manera de acotar un sistema es ponerlo en el contexto de los elementos externos que van a interactuar con él. Los elementos externos pueden ser: humanos, elementos de hardware u otros sistemas. A estos elementos se les conoce dentro de UML como Actores.
Una herramienta que nos permite documentar las fronteras del proyecto es el diagrama de contexto. Un diagrama de contexto emplea un rectángulo para definir el proceso y utiliza figuras de palios para representar a los actores (lo cual es un estándar de UML).
Identificación de actores.
En esta actividad se da nombre a los actores y se describe brevemente sus papeles y para que utilizan el sistema.
Actores: Un actor representa un conjunto coherente de roles que usuarios o sistemas juegan cuando interactúan con el caso de uso. Son los que interactuaran con el sistema.
Tipos de Actores:
- Actor principal: Tiene objetivos de usuarios que se satisfacen mediante el uso de los servicios del sistema(un cajero). Se identifica para encontrar los objetivos de usuario, que dirigen los casos de uso.
- Actor de apoyo o secundario: Proporciona un servicio al sistema en desarrollo(servicio autorización de pagos). Se identifica para clasificar las interfaces externas y los protocolos.
- Actor pasivo: Esta interesado en el comportamiento del caso de uso pero no es principal ni de apoyo(la Agencia Tributaria.). Se identifica para asegurar que todos los intereses necesarios se han identificado y satisfecho.
Técnicas para identificación de actores
Preguntas
- Cuales son los usuarios soportados por el sistema para desarrollar su trabajo?
- Cuales usuario ejecutan funciones principales del sistema?
- El sistema interactuá con hardware externo o software?
- Quien arranca y detiene el sistema?
- Quien administra el sistema?
- Quien gestiona lo usuarios y seguridad?
- Quien usara la solucion?
- ¿quién evalúa la actividad o el rendimiento del sistema?
Identificar las restricciones del sistema
Una restricción es una reducción al grado de libertad que tenemos para generar una solución. Existen diferentes tipos de restricciones que pueden presentarse en un proyecto.
Cada restricción puede potencialmente restringir nuestra habilidad para desarrollar una solución tal y como la visualizamos. Por lo tanto cada restricción debe considerarse dentro del proceso de planeación para analizar su impacto y determinar qué estrategia se empleará para cumplirla.
Técnicas
Preguntas
Económicas
¿Qué restricciones financieras o de presupuesto son aplicables?
¿Existe alguna consideración de precios de productos?
¿Existe alguna restricción de licencias?
¿Una falla puede interrumpir o dañar las operaciones diarias críticas del negocio?
¿Puede este proyecto incurrir o causar perdidas financieras significantes?
¿Es este un esfuerzo grande (> 6 meses o $100,000 Dls.)?
Políticas
¿Existen cuestiones políticas internas o externas que puedan afectar la solución?
¿Existen problemas o cuestiones interdepartamentales que puedan afectar la solución?
¿Fallar en el proyecto puede dañar la reputación de la empresa?
¿Este problema no ha podido ser resuelto en el pasado?
¿Existe algún participante que se oponga o tenga muchas dudas del proyecto?
Existirán más de 5 personas en el equipo del proyecto o en el “Steering Comitee”?
Técnicas
¿Existe alguna restricción en la elección de la tecnología?
¿Existe alguna restricción para trabajar con las plataformas o técnicas existentes?
¿Está restringido el uso de alguna nueva tecnología?
¿Es necesario usar algún paquete de software adquirido por el cliente?
¿El producto depende de tecnología experimental?
Si lo anterior ocurre, ¿estará involucrao más de un proveedor o componente crítico?
¿Existe un alto nivel de complejidad técnica involucrado?
Sistemas
¿La solución se construirá sobre un sistema existente?
¿Se debe mantener la compatibilidad con alguna solución existente?
¿Qué sistemas operativos y ambientes deben ser soportados?
Ambientales
¿Existen restricciones regulatorias?
¿Existen requerimientos de seguridad?
¿Qué otros estándares debe respetar el proyecto?
¿Existen restricciones legales o ambientales?
¿Está involucrada más de una empresa?
¿Más de una empresa será impactada por el producto?
Calendario y Recursos
¿El calendario del proyecto está definido?
¿Se está restringido a los recursos actuales?
¿Pueden usarse externos?
¿Pueden expandirse los recursos temporal o permanentemente?
¿Este proyecto está en busca de un campeón?
¿Este proyecto está en busca de un líder o administrador?
¿El proyecto entrará en un calendario acelerado o comprometido?
¿Lo anterior representa una dificultad o problema a largo plazo?
¿Es el primer esfuerzo de esta compañía en proyectos de este tipo?
¿Algún contratista externo liderará o producirá algún entregable clave?
¿Es necesario establecer un plan o asignar responsabilidades?
¿El equipo de trabajo carece de alguna habilidad necesaria?
¿Los recursos del proyecto están administrados /controlados por más de una persona?
¿Los miembros clave del equipo se encuentran en departamentos o edificios separados?
¿Hay dudas acerca del compromiso o disponibilidad de algún recurso clave?
Una vez identificadas algunas de las restricciones se volverán requerimientos del sistema que vamos a construir, otras restricciones afectarán recursos, planes de implementación y planes del proyecto.
Es responsabilidad del analista entender las fuentes potenciales para cada restricción y determinar el impacto de cada una en el espacio de la solución del problema.
Entender las necesidades de clientes y usuarios
La solución de un problema complejo, normalmente implica satisfacer las necesidades de diversos grupos de interés. Estos grupos pueden ser divididos en clientes y usuarios: Un cliente es una persona que tiene influencia sobre los requerimientos del sistema aunque no vaya a ser un usuario del mismo, mientras que los usuarios son las personas o grupos de personas que van a interactuar directamente con el sistema.
Entender las necesidades de clientes y usuarios es una parte fundamental de la elicitación de un proyecto. Para entender las necesidades de estas personas hay que empezar por identificarlos.
Algunas preguntas que podemos hacer para ayudarnos en esta labor son:
- ¿Cuáles serán los diferentes roles organizacionales que usaran el sistema?
- ¿Quién va a pagar por el sistema?
- ¿Qué otra persona se verá afectada por las salidas que el sistema produce?
- ¿Quién es responsable de evaluar y aceptar el sistema cuando se libere?
- ¿Quién será responsable de darle mantenimiento al sistema?
Una vez que hemos identificado a los clientes y usuarios podemos aplicar varias técnicas para identificar cuáles son sus necesidades. La siguiente sección describe esas técnicas y algunas herramientas que ayudan a entender cuáles son las necesidades de los usuarios respecto al sistema que se va a construir.
Tecnicas de elicitacion
Una cuestión básica en Ingeniería de Requerimientos es cómo determinar qué es lo que el cliente y los usuarios verdaderamente necesitan. Este proceso ha demostrado en la práctica que es muy complejo y que puede fácilmente provocar el fracaso de un proyecto.
Existen varias técnicas que pueden utilizarse para la elicitación de un sistema, sin embargo, dada la naturaleza social del proceso, el uso de las mismas debe considerar no sólo los aspectos técnicos sino los aspectos sociales, políticos y culturales del proyecto.
Introspección
La introspección es el medio más obvio y comúnmente usado para entender los requerimientos de un sistema. Consiste en estudiar el ambiente del usuario para posteriormente tratar de imaginar qué es lo que me gustaría que hiciera el sistema si yo estuviera a cargo de hacer el trabajo con su ayuda.
Esta técnica es útil pero hay que considerar que la experiencia de un analista de sistemas es muy diferente que la experiencia de los usuarios potenciales del software y por lo tanto es difícil que las conclusiones del analista reflejen la experiencia de las personas que hacen la tarea día con día.
Esto se hace más evidente en el diseño de la interfaz gráfica del usuario, lo que para un analista es el comportamiento común de un software, puede resultar confuso o frustrante para un usuario. Tradicionalmente, debido a las limitaciones gráficas que anteriormente tenían las computadoras, se creaba una brecha entre el diseño de la aplicación y las necesidades de usabilidad del usuario, sin embargo debido a la evolución de los ambientes gráficos el paradigma está cambiando: La obligación del usuario no es aprender a dominar una tecnología, es la tecnología la que debe ayudar al usuario a hacer su trabajo. La explosión del Internet ha creado nuevas especialidades como “user experience” en las cuales la psicología y la sociología son las principales herramientas científicas.
La recomendación, cuando se usa la introspección, es apoyarla con la información previa que generan otras técnicas como por ejemplo la entrevista abierta. En cualquier caso es recomendable validar cualquier duda con un “experto de dominio”. Los expertos de dominio son personas con mucha experiencia en un área particular del negocio que es de interés para el sistema. Por ejemplo, en el caso de una línea de producción, el operador de alguna máquina de la línea puede ser un experto de dominio que aporte valiosa información para la automatización del proceso.
Entrevista Abierta
Una de las técnicas más importantes y más directas para obtener requerimientos es la entrevista abierta. El proceso de realizar una entrevista puede parecer trivial en muchos casos, sin embargo, debido al factor social que ya hemos mencionado y al «síndrome del usuario y el desarrollador», las entrevistas pueden presentar complicaciones.
Una de las principales consideraciones a tomar en cuenta en una entrevista es lograr que la predisposición del entrevistador no influya en el resultado de la narrativa capturada. Como proveedores de soluciones, estamos acostumbrados a identificar soluciones al mismo tiempo que escuchamos problemas, cuando hacemos esto, tendemos a influenciar las respuestas del entrevistado, provocando una mala comprensión del problema o una reducción en el grado de libertad de la solución.
Una entrevista debe considerar preguntas libres de contexto (Gausse and Weinberg, 1989), es decir, preguntas que no influencien las respuestas de los entrevistados hacia las respuestas que queremos oír. Por ejemplo:
¿Quiénes son los usuarios del sistema?
¿Qué problemas tienen actualmente?
¿Cuáles son sus necesidades respecto a la solución?
Este tipo de preguntas fuerzan al entrevistador a escuchar antes de identificar una solución potencial, así mismo permiten al entrevistado explayarse en la descripción de la problemática que enfrenta. Cuando el analista escucha lo que el usuario tiene que decir respecto a sus necesidades, se produce un mejor entendimiento del problema y por tanto una solución adecuada.
Las preguntas libres de contexto son una técnica similar a la que los profesionales de ventas utilizan como parte de la estrategia conocida como “solution selling”. En esta estrategia el vendedor pregunta para obtener información sobre la problemática del cliente antes de ofrecer un producto o un servicio. Cuando el vendedor ha obtenido una visión clara de la problemática del cliente, entonces propone algo que tiene sentido para el cliente y entonces la venta se produce más fácilmente.
Pasos para una entrevista abierta
Una entrevista abierta requiere prepararse con anterioridad. Una recomendación básica es preparar una guía con preguntas apropiadas que permitan mantener una conversación fluida a la vez que ayuden a asegurar que no se olvida tocar ningún tema importante durante la entrevista. La guía no debe seguirse al pié de la letra, simplemente es un apoyo para usarse durante la entrevista. A continuación se listan algunos pasos para preparar una entrevista.
Investigar el background del usuario y de la empresa antes de la entrevista
Revisar las preguntas antes de la entrevista
Consultar la lista de preguntas durante la entrevista para asegurarse de hacer las preguntas correctas
Al final de la entrevista, identificar los dos o tres problemas principales y repetir lo que se entendió para asegurar la comprensión
Algunos consejos que pueden ayudarnos durante una entrevista:
No hagas preguntas donde se suponga de antemano que la gente puede describir actividades complejas. En general la gente puede hacer muchas cosas que no puede describir. Cuando necesites entender una actividad compleja separa la pregunta en varias partes o utiliza otra técnica como la investigación de campo.
Haz preguntas abiertas que le permitan al usuario extenderse en sus respuestas y a ti comprender mejor su problemática.
No hagas preguntas que influencíen la respuesta del entrevistado: ¿Usted necesita una pantalla para realizar esta tarea, verdad?
No hagas preguntas para controlar la conversación: ¿Podemos regresar a la pregunta anterior?
No hagas preguntas que se respondan así mismas: ¿50 elementos en esta lista son suficientes, verdad?
Evita preguntas que empiecen con ¿Por qué?. Habitualmente estas preguntas ponen al entrevistado a la defensiva porque aparentan cuestionar la manera en que hace su trabajo.
No esperes respuestas sencillas. Cuando las obtengas sigue preguntando para descubrir más “ruinas enterradas”.
No apures al entrevistado para que responda. Si haces esto probablemente no querrá responder tu próxima pregunta.
Por último lo más importante: Escucha con atención.
Cuestionarios
Los cuestionarios son otra técnica de elicitación. Consisten en una serie de preguntas que el entrevistador hace de manera secuencial o que se entregan al entrevistado para que él mismo conteste.
Los cuestionarios tienen la deficiencia de que no utilizan los elementos de interacción de la entrevista, por lo tanto se corre el riesgo de que, dado que la persona a la que se entrevista tiene diferente historia y por lo tanto diferentes conocimientos y categorías para clasificar los conceptos, algunas preguntas se malinterpreten o resulten irrelevantes y fuera de contexto.
Grupos de Desarrollo de Aplicaciones
Consiste en involucrar a los usuarios en el proceso de desarrollo mediante talleres o workshops en los cuales se identifican los requerimientos. En los talleres pueden utilizarse diferentes técnicas para ir descubriendo requerimientos como «Casos de Uso», «Story Boards», «Modelos» o «Prototipos».
Los grupos de desarrollo tienen el inconveniente de que no son comunidades naturales, por lo tanto es difícil que los participantes compartan categorías. Otro riesgo en estos talleres es que, dadas las jerarquías que existen dentro de una empresa, alguno de los participantes puede no sentirse libre para expresar su opinión o puede sentirse obligado a dar una opinión sobre un punto que desconoce o en el que él no es experto.
Algunas recomendaciones para conducir un grupo de desarrollo son:
Da a todos la oportunidad de hablar. Esto es esencial para que el workshop se considere imparcial.
Procura que la sesión se mantenga andando. Existe una tendencia natural a que el workshop se convierta en una “sesión de quejas”. Identifica los problemas/requerimientos pero no profundices. Una vez que se ha identificado un problema/requerimiento avanza al siguiente.
Permanece alerta para recoger información y hallazgos.
Al final, resume la sesión y trabaja en generar conclusiones
Tormenta de ideas
Cuando se está conduciendo una sesión de requerimientos es necesario en ocasiones usar alguna herramienta que permita identificar y clasificar necesidades. Una herramienta muy útil para lograr esto es la «tormenta de ideas». La Tormenta de Ideas consiste en listar todas las ideas sobre un tema que se le ocurren a un auditorio determinado y posteriormente filtrarlas, desarrollarlas y priorizarlas.
Una sesión de este tipo comienza con la aclaración del objetivo. El objetivo es muy importante porque permite mantener en foco la sesión, sin embargo no debe de ser limitante para la creatividad de las ideas expresadas, es más las ideas más descabelladas pueden resultar en soluciones innovadoras. Los participantes deben de aportar ideas sin interrupción y tantas como sea posible, para lograr esto, el moderador debe crear un ambiente en el que la creatividad y la apertura de mente tengan un lugar prioritario, por ejemplo evitando críticas o debates durante la aportación de ideas.
Cuando las ideas comienzan a repetirse y los participantes empiezan a demorarse mucho tiempo entre idea e idea, es momento de suspender la sesión y pasar a filtrar, combinar, ordenar y priorizar las ideas. Al hacer esto, es necesaria la participación del grupo mediante debates y consensos. El moderador debe de evitar que la discusión se vuelva personal o que los debates se prolonguen demasiado, esto puede lograrse usando rondas de votación con prioridades, en las cuales a los miembros se les da una cantidad de puntos que deben distribuir entre las diferentes opciones, nunca asignado más del 50% de sus puntos a una opción. Al final se suman los puntos y la opción con más puntos resulta ganadora.
Storyboards
El Storyboard es una técnica tradicionalmente usada en el cine para describir una secuencia o una escena. Consiste en ilustrar o animar cómo el sistema encaja en la organización para analizar el comportamiento del mismo.
Los storyboard pueden ser tan simples como un par de trazos hechos a lápiz o tan complicados como el diseño gráfico de una página de Web. Sin embargo es recomendable mantenerlos fáciles de hacer y de cambiar, ya que en el fondo debe ser una herramienta barata que ayude a descubrir requerimientos y necesidades por lo tanto su naturaleza será cambiar. Cuando se tienen más claros los requerimientos o cuando se requiere un producto para vender una necesidad a un cliente es más recomendable usar los prototipos y los demos.
