===================================================== Fase 3 - Diseño del Proceso de Captura de Requisitos ===================================================== Introducción ============= Una de las tareas más delicadas a la hora de ejecutar un proceso de Ingeniería de Requisitos es el correcto diseño del proceso de captura de requisitos. Este proceso implica dos actividades complementarias: (1) la identificación de las fuentes que se utilizarán para extraer requisitos; y, (2) la selección y planificación de las estrategias de captura de requisitos que se utilizarán para extraer la información adecuada de las fuentes seleccionadas anteriormente. Un proceso de Ingeniería de Requisitos se puede definir de manera general como la transformación o materialización de una serie de ideas vagas y difusas en una serie de instrucciones precisas y concretas. Para realizar dicha transformación necesitamos trabajar con personas, documentos o sistemas que nos ayuden a identificar dichas ideas y refinarlas. Es decir, necesitamos fuentes para la captura de requisitos. Si dichas fuentes no son fiables o no disponen de la información suficiente para nuestros intereses, nuestro proceso de Ingeniería de Requisitos probablemente fracasará, por muy bien que lo ejecutemos. Valga como ejemplo el siguiente símil. Si uno está en una ciudad de turismo y desea saber cómo llegar a una cierta calle, un habitante de dicha ciudad le proporcionará probablemente mejores indicaciones que otro turista. Por tanto, si estamos en Estocolmo y queremos llegar a la calle *Apelbergsgatan*, es mucho mejor preguntárselo a alguien rubio, alto y de ojos claros antes que a alguien bajito y de tez morena; ya que hay ciertos factores que parecen indicar que el primero es oriundo del lugar mientras que el segundo probablemente sea foráneo. Por tanto, el primer gran objetivo de esta práctica es aprender a identificar correctamente aquellas fuentes para la captura de requisitos que nos puedan proporcionar una información más precisa, fiable y completa. Tras la selección de las fuentes de requisitos, se deben seleccionar aquellas estrategias que se utilizarán para extraer los requisitos de dichas fuentes. Estas estrategias deberán adaptarse tanto a las características de las fuentes seleccionadas como a las limitaciones de tiempo y coste que nos imponga nuestro proyecto. Por tanto, el segundo gran objetivo de esta práctica es aprender a seleccionar de manera adecuada estrategias de captura de requisitos, atendiendo a las limitaciones de tiempo y coste del proyecto. Además, cada actividad debe estar correctamente planificada, ya que, como bien diría un gallego, las actividades que no se planifican pueden salir bien o pueden salir mal, siendo lo normal, si no están planificadas, que salgan mal. El que una actividad se desarrolle bien o mal dependerá de varios factores tales como la habilidad y veteranía de las personas responsables de llevar a cabo tal acción; o la existencia de un clima favorable para el desarrollo de la acción, entre otros asuntos. Aunque todo actividad suele estar sometida a una componente nada despreciable de azar, es labor de un buen ingeniero tratar de reducir todo lo posible dicho azar para procurar crear un ambiente adecuado para el desarrollo de la actividad. Para ello, es fundamental que tanto el proceso completo de captura de requisitos como cada actividad estén perfectamente planificados, tratando de dejar el menor número posible de elementos al azar. Por tanto, el tercer gran objetivo de esta práctica es aprender a planificar adecuadamente tanto procesos de captura de requisitos como actividades concretas de captura de requisitos. Para poder alcanzar los tres grandes objetivos mencionados, se deberán satisfacer los objetivos concretos que se detallan en la siguiente sección. Objetivos ========== Los objetivos de esta práctica son: #. Ser capaz de identificar potenciales fuentes de requisitos. #. Ser capaz de seleccionar fuentes de requisitos en función de su relevancia. #. Ser capaz de seleccionar las estrategias de captura de requisitos que resulten más adecuada para extraer información de las fuentes de requisitos identificadas, teniendo en cuenta las características de cada fuente, la información que se espera obtener de ella y las limitaciones de tiempo y coste de cada proyecto. #. Ser capaz de asegurar que un proceso de captura de requisito es completo, cubriendo de manera adecuada todos aquellos elementos del contexto de un sistema que resulten relevantes para su desarrollo. #. Ser capaz de planificar a alto nivel actividades de captura de requisitos. #. Ser capaz de secuenciar actividades para la captura de requisitos, teniendo en cuenta la disponibilidad de los recursos y las dependencias entre actividades. La siguiente sección describe las actividades que se deberán realizar para la consecución de estos objetivos. Actividades ============ Para diseñar un proceso de captura de requisitos se deberán llevar a cabo las siguientes actividades: #. Ejecutar el procedimiento propuesto por Klaus Pohl en la Sección 21.4 de su libro *Requirements Engineering*. #. Ordenar las fuentes identificadas en el punto anterior en función de su relevancia. NOTA: A la hora de ejecutar estos dos primeros puntos, se pueden introducir actividades complementarias tanto para fomentar la creatividad durante la propuesta de potenciales de requisitos fuentes como para llevar a cabo su priorización. #. Seleccionar estrategias de captura de requisitos para las fuentes de mayor relevancia hasta asegurar que los elementos del contexto del sistema que sean de relevancia para su desarrollo están adecuadamente cubiertos. #. Especificar, por cada miembro del equipo de trabajo, una de las actividades creadas en el punto anterior, de manera individual y completa y utilizando para ello la plantilla proporcionada. #. Secuenciar las actividades que hayan sido especificadas, de forma que se ordenen temporalmente sobre un calendario, teniendo en cuenta los recursos disponibles. Como recursos se puede contar con los miembros de cada equipo, más una sala de reuniones, que por comodidad, podemos considerar que no estará ocupada por otros proyectos. Igualmente, se puede considerar que los recursos externos, como personas para entrevistar, estarán también disponibles para nosotros. Para la elaboración del calendario puede considerarse como inicio del proceso de captura de requisitos el 1 de Marzo del año que corresponda. Para elaborar el documento con el proceso de captura se proporciona: #. :download:`La plantilla para la definición del proceso de captura de requisitos ` #. :download:`Un ejemplo de especificación de un proceso de captura de requisitos ` Elementos a Entregar y Aclaraciones ======================================= Se deberán entrega para su evaluación un único documento con la identificación de las fuentes de requisitos y el diseño del proceso de captura de requisitos. Este documento se entregará a través de la plataforma moodle siguiendo las instrucciones en ella proporcionadas y dentro de las fechas establecidas. La entrega de dichos documentos fuera de dichas fechas o un formato diferente al solicitado supondrá una calificación de cero. Cada documento se evaluará y calificará conforme a los criterios especificados en la siguiente sección. Criterios de Evaluación ========================= La calificación del *documento con el proceso de captura de requisitos* vendrá determinada por la ponderación de las calificaciones de los siguientes apartados: #. Completitud (2.5 puntos). #. Elección de Actividades (2.5 puntos). #. Descripción de las Actividades (3 puntos). #. Secuenciación de las Actividades (1 punto). #. Ortografía, Gramática y Maquetación (1 punto). Todos los apartados tendrán una calificación común a todo el grupo, a excepción del apartado *Descripción de las Actividades* será evaluado individualmente. *Ortografía, Gramática y Maquetación* se evaluará conforme a los criterios establecidos para ello en el correspondiente apartado de la sección de elementos transversales. El resto de elementos se calificará mediante el procedimiento y los criterios a continuación proporcionados. Completitud ------------ Para calificar la completitud del proceso de identificación de fuentes, se verificará el grado de satisfacción de los siguientes elementos: #. Por cada elemento del contexto del dominio que potencialmente tenga relación con el sistema existe al menos una fuente que pueda proporcionar información sobre dicho elemento. #. Existe un número amplio de potenciales fuentes identificadas, con independencia de que dichas fuentes finalmente se utilicen o no se utilicen. #. No se ha obviado ninguna fuente de requisitos que pueda considerarse como fácilmente identificable. #. La ordenación por relevancia de las fuentes no es fácilmente rebatible. Para poder obtener una calificación de aprobado en este apartado todos los elementos del contexto del sistema deberán quedar cubiertos por alguna fuente, y deben estar identificadas todas aquellas fuentes que se consideren como básicas u obvias. A partir de este punto, cuanto más extensa y correcta sea la lista de fuentes identificadas, mayor será la calificación de este apartado. Elección de Actividades ------------------------ Para evaluar este apartado se verificará que todas las actividades elegidas sean adecuadas para el tipo de fuente o fuentes a procesar y para la información a obtener. Además, estas actividades deberán tener un coste razonable para los resultados esperados. Para poder obtener una calificación de aprobado en este apartado, más de la mitad de las actividades elegidas deben ser correctas. Además, para las actividades que fuesen incorrectas, no deben haberse cometidos fallos graves consecuencia de la existencia de errores conceptuales importantes. .. Poner ejemplo de error conceptual grave Descripción de las Actividades ------------------------------- Para calificar la descripción de las actividades, se verificará el grado de satisfacción de los siguientes elementos: #. Cada actividad tiene un identificador asignado. #. La estrategia a seguir en cada actividad está claramente definida. #. Los participantes son adecuados y contribuyen a la consecución del objetivo de la actividad, siendo la selección de participantes no fácilmente rebatible. #. El objetivo de la actividad especifica claramente el propósito concreto de la actividad, incluyendo una breve descripción de por qué se sigue exactamente la estrategia seleccionada. #. La información a obtener indica claramente los artefactos que se generarán tras ejecutar la actividad, así como la forma concreta que tendrán esos artefactos. #. La duración es realista y adecuada, e indica el tiempo total de ejecución de la actividad. En el caso de los cuestionarios, dicho tiempo reflejará tanto el tiempo de ejecución de un cuestionario individual, como todo el tiempo que estarán realizando los cuestionarios. #. El lugar donde realizar la actividad es adecuado y su elección no es fácilmente rebatible. En el caso de cuestionarios *online*, el lugar será la web o sistema web donde se aloje el cuestionario. #. Los recursos asociados a la actividad no son fácilmente rebatibles, no conteniendo carencias obvias ni excesos evidentes. #. El coste de los recursos es realista, no pecando de excesos ni defectos claros. En este sentido, hay que tener en cuenta, por ejemplo, que para pagar una comida, hay un punto intermedio entre un menú del día de 9.50€ en un bar de estudiantes y un menú degustación de 120€ en un restaurante con estrellas Michelín. A modo de guía, se adjunta una tabla de costes en el Apéndice A. #. Las horas asignadas a la preparación y procesamiento de la actividad son adecuadas, no pecando de defectos ni excesos. A este respecto cabe destacar que cuando se trabaja no se trata de hacer carreras de velocidad, sino de mantener un ritmo normal y sostenible de trabajo. Es decir, aunque un diagrama UML pudiese hacerse en algún momento en dos horas, o alguien alguna vez lo hiciese en una hora, su duración debe ser la de hacerlo relajado y sin prisas. #. La forma de contacto da una idea clara de cómo encontrar a los participantes en un actividad y cómo contactar con ellos. En caso de que las actividades se realicen sobre sistemas o documentos, en este apartado se deberá indicar cómo puede acceder al sistema o dónde puedo encontrar un documento. Por ejemplo, podría proporcionar una URL al sistema o documento. #. La información proporcionada en los comentarios adicionales es de utilidad y contribuye a entender mejor la descripción de la actividad, no siendo fácilmente prescindible. .. Poner criterios mínimos. Secuenciación de las Actividades ---------------------------------- #. Cada actividad descrita está incluida en el calendario. #. La duración de cada actividad es consistente con los tiempos de preparación, ejecución y procesamiento proporcionadas en la correspondiente descripción de la actividad. #. Los hitos importantes de cada actividad, como el día de ejecución de una entrevista, están correctamente resaltados en el calendar io. #. Las personas y recursos involucradas en cada actividad están claramente identificados. #. No se producen utilizaciones simultáneas de recursos, ya sean humanos o materiales. #. Se respetan las dependencias entre tareas. .. Poner criterios mínimos. Apéndice A. Tablas de Costes ================================ ====================== ========= Concepto Precio ====================== ========= Hora Ingeniero Senior 130€ Hora Ingeniero Junior 80€ Dietas Comida 70€ Dietas Alojamiento 120€ ====================== =========