Ingenieria de requerimientos y modelo para identificar los requerimientos. Parte # 2
Continuando con el post anterior y siguiendo con la siguiente paso etapa de elitacion del modelo para de ingeniería de requerimientos.
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 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.
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?
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.