TESIS DE MAESTRÍA EN CIENCIAS

Transcripción

1 Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Metodología para la Evaluación Personal en la Especificación de Requerimientos de Software presentada por Manuel Adrián Murillo Madera Ing. en Computación y Redes de Computadoras por la Universidad Morelos de Cuernavaca como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación Director de tesis: Dr. Máximo López Sánchez Jurado: Dr. René Santaolaya Salgado Presidente Dr. Moisés González García Secretario Dra. Olivia G. Fragoso Díaz Vocal Dr. Máximo López Sánchez Vocal Suplente Cuernavaca, Morelos, México. 3 de febrero de 2012

2

3

4 Dedicatoria A mis padres Olga y Felipe, gracias por motivarme a seguir cumpliendo mis metas y apoyarme en cada una de mis decisiones, los amo. A mi querido hermano Luis (Huicho), que siempre me has acompañado y aun con nuestras discusiones siempre nos tendremos el uno al otro. A mi novia Lorena, que a lo largo de estos años me has brindado tu amor y tu apoyo, me haces muy feliz, te amo. A mi gran amigo Rafael que siempre ha estado apoyándome, con el cual he compartido varias experiencias.

5 Agradecimientos A toda mi familia, tíos, primos, sobrinos y padrinos, cuyas palabras de aliento me ayudaron a cumplir con este logro. A la familia de mi novia, que siempre estuvo al pendiente de mis avances y metas cumplidas. A la familia Campos Leal, que siempre me estuvieron echando porras y me han hecho sentir como un miembro más de la familia. A todos mis amigos del cenidet en especial a Lucia, Cristina, Pepe y Ricardo, siempre recordare los momentos que compartimos. Al Centro Nacional de Investigación y Desarrollo Tecnológico, por brindarme las herramientas para conseguir la maestría. Al Consejo Nacional de Ciencia y Tecnología (CONACYT) cuyo apoyo económico permitió realizar mis estudios de maestría. A mi director de tesis el Dr. Máximo López Sánchez, quien me apoyo y brindo las bases para lograr avanzar en este proceso, además del apoyo recibido en la publicación de mi primer artículo. A mis revisores: Dr. Moisés González García, Dr. René Santaolaya Salgado, Dr. Olivia Fragoso Díaz, cuyas observaciones y correcciones permitieron realizar un mucho mejor trabajo. A toda la gente que me ha estado apoyando. GRACIAS.

6 Resumen La etapa de especificación de requerimientos de software (ERS) es una de las fases más importantes del desarrollo de un sistema de software. Cuando no se realiza de manera adecuada, se convierte en la causante de retrasos en la entrega de sistemas debido a un mal entendimiento de las necesidades del cliente, errores e inconsistencias en el funcionamiento deseado del software. Existen una serie de metodologías y herramientas que apoyan a la ERS, sin embargo, el esfuerzo de estos trabajos está enfocado al producto de la especificación más que al proceso personal que se lleva a cabo para su elaboración. Tener definido un proceso personal, además de herramientas que apoyen a conocer este proceso y analizarlo, permite la mejora del trabajo y como consecuencia realizarlo con una mayor calidad. Si un individuo mejora la calidad de su trabajo, el equipo y el proyecto también se verán beneficiados. En esta tesis se presenta la Metodología para la Evaluación Personal en la Especificación de Requerimientos de Software (MEPERS) cuyo objetivo es permitir al desarrollador conocer su proceso y con esto mejorar su trabajo, mediante un conjunto de procesos definidos para cada etapa de la especificación de requerimientos, que facilitan el registro de métricas acerca de su desempeño, así como del análisis y compresión de su proceso personal para la especificación de requerimientos de software. Los resultados que se obtuvieron de la tesis fueron una colección de formatos de captura de información del proceso, guías para realizar la especificación de requerimientos de software, listas de verificación para cada etapa, además de un estándar de defectos los cuales permiten conocimiento del proceso personal, así como facilitar la enseñanza de esta tarea de la ingeniería de requerimientos. Además, como producto resultante de aplicar la metodología se obtiene un documento de especificación de requerimientos de software utilizando el estándar IEEE Centro Nacional de Investigación y Desarrollo Tecnológico Página 1

7 Abstract The stage of software requirements specification (SRS) is one of the most important steps when developing a software system. When not done properly it becomes the cause of delays in the development of the system, due to poor understanding of customer needs, mistakes and inconsistencies in the desired performance of the software. There are a number of methodologies and tools that support the SRS, however, the effort of those works is focused on the product of the specification, rather than the personal process for its elaboration. Having defined a personal process enables work improvement and consequently doing it with higher quality. If an individual improves the quality of its work, the team, and the project will also benefit, This thesis present the Metodología para la Evaluación Personal en la Especificación de Requerimientos de Software (MEPERS) whose objective is to allow the developer to know his process and thereby improve his work, using a methodology that facilitates the registration of metrics about his performance, analysis and understanding of his personal process during the software requirements specification. The results obtained from the thesis was a set of elements that support the registration of the process information, guides to do the software requirement specification, checklists for each stage of the process and a defect type standard which allow the developer get knowledge of his personal process during this task also facilitate the teaching of this task of requirements engineering. In addition, as a product resulting from applying the methodology it s obtained a Software requirements specification document using IEEE standard Centro Nacional de Investigación y Desarrollo Tecnológico Página 2

8 Tabla de contenido RESUMEN... 1 ABSTRACT... 2 INTRODUCCIÓN... 8 CAPÍTULO 1 INFORMACIÓN GENERAL Antecedentes Trabajos relacionados Una Metodología para elicitación de requisitos en proyectos GSD [AVCPS2007] Metodología para la elicitación de requisitos de sistemas de software [DUBE2002] Metodología DoRCU para la ingeniería de requerimientos [BABA2001] Planteamiento del problema Objetivo de la tesis Justificación y beneficios Justificación Beneficios Alcance y límites del proyecto Alcances Limites Conclusiones del capitulo CAPÍTULO 2 MARCO CONCEPTUAL Ingeniería de software Requerimientos de software Etapas del proceso para la metodología de especificación de requerimientos de software Descripción del análisis de dominio orientado a las características FODA Metodología Proceso de software Proceso Personal Conclusiones del capitulo Centro Nacional de Investigación y Desarrollo Tecnológico Página 3

9 CAPÍTULO 3 DESARROLLO Análisis de dominio orientado a las características para el desarrollo de una metodología para la evaluación personal en la especificación de requerimientos de software Introducción Análisis de contexto (FODA) Modelado del dominio (FODA) Etapas de la metodología para la evaluación personal en la especificación de requerimientos de software Datos de entrada Planeación Desarrollo Elicitación Análisis Registro Postmortem Elementos que integran la metodología para la evaluación personal en la especificación de requerimientos de software Formatos, guías, bitácoras y estándares de la metodología Métricas Estándar de defectos propuesto Elementos de la metodología usados a través del proceso Elementos utilizados en la etapa de planeación Elementos utilizados en la etapa de desarrollo Elementos utilizados en la etapa de Postmortem Conclusiones del capitulo CAPÍTULO 4 PRUEBAS Propósito de las pruebas Ámbito de las pruebas Herramientas para las Pruebas Procedimiento de realización de las pruebas Criterios de éxito y de fracaso Casos de Prueba Caso de prueba Lectura del ejercicio a resolver Aplicar la metodología MEPERS Análisis de la información Caso de prueba Lectura de la información proporcionada por el cliente Centro Nacional de Investigación y Desarrollo Tecnológico Página 4

10 Aplicar la metodología MEPERS Análisis de la información Riesgos Conclusiones del capitulo CAPÍTULO 5 CONCLUSIONES Conclusiones generales Objetivos cumplidos Trabajo a futuro REFERENCIAS Centro Nacional de Investigación y Desarrollo Tecnológico Página 5

11 Índice de figuras Figura 1.1 Metodología RE-GSD Figura 1.2 Metodología para la elicitación de requerimientos [DUBE2002] Figura 1.3 Metodología DoRCU [BABA2001] Figura 1.4 Resultados de Proyectos "The Chaos Report" Figura 1.5 Problemas en requerimientos "The Chaos Report" Figura 2.1 Etapas de la especificación de requerimientos de software Figura 2.2 Etapas del análisis FODA [KCHNP1990] Figura 3.1 Actividades realizadas FODA Figura 3.2 Diagrama de estructura Figura 3.3 Diagrama de contexto Figura 3.4 Análisis de información Figura 3.5 Diagrama de característica Figura 3.6 Etapas de la metodología Figura 3.7 Etapas de la metodología Figura 3.8 Etapas y sus formatos Figura 3.9 Bitácora de tiempo Figura 3.10 Bitácora de defectos Figura 3.11 Formato de participantes del proyecto Figura 3.12 Formato de planeación de tareas Figura 3.13 Checklist de planeación Figura 3.14 Formato de objetivos y metas Figura 3.15 Minuta de reuniones Figura 3.16 Checklist de elicitación Figura 3.17 Formato de análisis de requerimientos Figura 3.18 Checklist de análisis Figura 3.19 Formato PIP Figura 4.1 Resumen de proyecto Caso Figura 4.2Bitácora de tiempos Caso Figura 4.3Bitácora de defectos Caso Figura 4.4 Participantes del proyecto Caso Figura 4.5 Estimación de tareas Caso Figura 4.6 Objetivos Caso Figura 4.7 Reunión Caso Figura 4.8 Requerimientos Caso Figura 4.9 Formato PIP Caso Figura 4.10 Resumen de proyecto Caso Figura 4.11Bitacora de tiempos Caso Figura 4.12 Bitácora de defectos Caso Figura 4.13Participantes del proyecto Caso Figura 4.14Estimación de tareas Caso Figura 4.15 Objetivos Caso Figura 4.16 Requerimientos Caso Figura 4.17Formato PIP Caso Centro Nacional de Investigación y Desarrollo Tecnológico Página 6

12 Índice de tablas Tabla 1.1 Tabla comparativa con los trabajos relacionados Tabla 2.1 Características de un requerimiento Tabla 3.1 Tabla comparativa de metodologías Tabla 3.2 Métricas adaptadas de PSP Tabla 3.3 Métricas propuestas por la metodología Tabla 3.4 Estándar de defectos Tabla 4.1 Herramientas de soporte para pruebas Tabla 4.2 Caso de prueba Tabla 4.3 Caso de prueba Tabla 4.4 Riesgos encontrados Abreviaturas CENIDET FODA MEPERS PSP SRS TSP Centro Nacional de Investigación y Desarrollo Tecnológico Análisis de dominio orientado a las características (Feature Oriented Domain Analysis) Metodología para la evaluación personal en la especificación de requerimientos de software Proceso personal de software (Personal Software Process) Especificación de requerimientos de software (Software Requirements Specification) Proceso de software en equipo (Team Software Process) Centro Nacional de Investigación y Desarrollo Tecnológico Página 7

13 Introducción Actualmente, la calidad en todos los ámbitos es un aspecto muy importante a considerar, en el caso del desarrollo de sistemas de software la calidad de software puede ser definida como Conformidad con los requerimientos [CROSBY1979]. De acuerdo a Humphrey, cualquier definición de calidad de software debe ser enfocada en cubrir las necesidades del usuario. [HUMPHREY1995] Teniendo estas ideas en mente podemos decir que la calidad del software tiene como base los requerimientos de software, una falta de atención en la especificación de los requerimientos ocasiona una falta de calidad en el producto final. Se pueden utilizar metodologías como apoyo a los desarrolladores para facilitar el trabajo de ingeniería de requerimientos, si no se sigue un conjunto de métodos definidos existe una mayor probabilidad de que la calidad disminuya. En el desarrollo de un sistema, la etapa de especificación de requerimientos de software influye de manera notable en etapas posteriores. Por ejemplo, cuando no se realiza de manera adecuada, se convierte en la causante de retrasos en la entrega de sistemas debido a un mal entendimiento de las necesidades del cliente, errores e inconsistencias en el funcionamiento deseado del software, lo que trae consigo no cubrir con las necesidades y por ende una mala calidad del producto. De acuerdo al estudio The Chaos Report hecho por el Standish Group en el 2009 [STANDISH2009], tan sólo el 32% los proyectos son completados con su alcance esperado, en el tiempo planificado y el presupuesto asignado. De los factores de fracaso, el 43.5% están relacionados con la etapa de requerimientos. Una atención adecuada de esta etapa brindará una notable mejora en la productividad del desarrollo del sistema. En la etapa de especificación de requerimientos de software se elabora un documento llamado especificación de requerimientos de software (SRS por sus siglas en inglés). Este documento define el sistema de software que se va a construir y por ello es importante la calidad que presente. Para que un SRS se considere de calidad debe de contribuir a realizar un proyecto exitoso, rentable y que resuelva las necesidades reales del usuario. [DAA1993]. Centro Nacional de Investigación y Desarrollo Tecnológico Página 8

14 Existen una serie de metodologías y herramientas que apoyan a la mejora de calidad de una especificación de requerimientos de software, sin embargo el esfuerzo de estos trabajos está enfocado al producto de la especificación más que al proceso personal que se lleva a cabo para su elaboración. Debido a falta de métodos definidos que ayuden a conocer al desarrollador su proceso personal de especificación de requerimientos de software, no es posible establecer un control, administración y mejora de su trabajo de especificación de requerimientos de software. Es por esto que esta tesis propone una metodología que ayuda al desarrollador a conocer su propio proceso de especificación de requerimientos y con esto mejorar su trabajo, facilitando el registro de medidas acerca de su desempeño y le permita analizar y comprender su proceso personal para la especificación de requerimientos de software. Centro Nacional de Investigación y Desarrollo Tecnológico Página 9

15 Organización del documento La organización del documento de tesis es la siguiente Capítulo 1: En este capítulo se presentan los antecedentes a este trabajo, artículos relacionados con el tema, además de la descripción del problema, objetivo, justificación y beneficios, así como el alcance y limitaciones que presenta la tesis. Capítulo 2: En este capítulo se encuentran los conceptos y definiciones más importantes, los cuales son utilizadas a lo largo del documento. Capítulo 3: En este capítulo se presenta el trabajo realizado para la elaboración de la metodología, así como el procedimiento para utilizarla. Capítulo 4: En este capítulo se presentan las pruebas y los resultados obtenidos de aplicar la metodología para 2 casos de prueba. Capítulo 5: Por ultimo en este capítulo se presentan las conclusiones. Centro Nacional de Investigación y Desarrollo Tecnológico Página 10

16 Capítulo 1 Información general En este capítulo se presentan los antecedentes de este trabajo de tesis, un análisis de algunos trabajos relacionados, así como las razones que motivaron a realizar esta investigación, se define el objetivo que se consiguió, los beneficios producidos y sus alcances y limitaciones. Centro Nacional de Investigación y Desarrollo Tecnológico Página 11

17 1.1 Antecedentes En el área de ingeniería de software del Centro Nacional en Investigación y Desarrollo Tecnológico (CENIDET) la empresa Quarksoft impartió un taller de PSP (Personal Software Process). A partir de ese momento se ha impulsado el uso de esta metodología, lo que ha ayudado a tener una preparación más completa en estudiantes y profesores, entre los cursos impartidos en el CENIDET existen 2 materias que se centran en el trabajo de esta metodología, su conocimiento y uso. Debido a que el objetivo de esta tesis es conocer el proceso personal en la especificación de requerimientos de software, lo aprendido en esos cursos sirvió como base para la metodología desarrollada. Además los trabajos que fueron desarrollados en el CENIDET y que influyen en esta tesis son los siguientes Conteo semiautomático de líneas de código en ambientes de desarrollo integrado mediante una estrategia de marcado de texto en tiempo de codificación [IDRE2008] Esta tesis fue desarrollada por Erick Leobardo Iduñate Rosales dirigido por el Dr. Máximo López Sánchez, habiéndose concluido en el año El objetivo de esta tesis fué definir una estrategia de conteo de líneas de código para estimar el tamaño de un proyecto de software, diferenciando las líneas generadas automáticamente por el IDE (Entorno de desarrollo integrado) y las escritas por un desarrollador. Esta tesis no toca la etapa de especificación de requerimientos, sin embargo trabaja con una de las métricas más importantes del PSP para la estimación del tamaño de un proyecto. Propuesta metodológica para la captura de requisitos [MARM2001] Realizado por Martin Gerardo Martínez Rangel y dirigido por el Dr. Javier Ortiz Hernández en el año El objetivo que se cumplió en esta tesis fue desarrollar una metodología para la captura de requerimientos, en la que se puede apoyar al responsable de recolectar los requerimientos y poder aclarar los deseos y necesidades del cliente. De esta tesis se analizó la estrategia utilizada para la recolección de requerimientos y ciertos puntos fueron tomados como apoyo para la metodología presentada en esta tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 12

18 SiSoProS, Modulo de interfaz de usuario [ORCA2009] Fue realizado en colaboración con el Instituto Tecnológico de Mérida, desarrollado por Alejandro de Jesús Ortiz Cervera, siendo dirigida por la M.C. Larissa Jeannette Peniche Ruiz y el Dr. Moisés González García. Su objetivo fue diseñar y desarrollar un módulo de interfaz bajo plataforma web del sistema SiSoProS, el cual es capaz de registrar y monitorear equipos de desarrollo de Software basado en el método AGD (Método de Desarrollo Arquitectónico en Grupo). El método AGD fue desarrollado por el Dr. Moisés González García, el cual es útil para el desarrollo realizado por grupos de personas con un enfoque a modelos. Este método, al igual que el PSP y el TSP, define procesos y una colección detallada de métricas en el desarrollo de un producto; contempla defectos inyectados y removidos al igual que el tamaño del producto terminado. [ORCA2009]. 1.2 Trabajos relacionados A continuación se presentan una serie de metodologías que atienden desde distintos enfoques problemas relacionados en el proceso de especificación de requerimientos de software. Se realiza una breve descripción de cada metodología y al final una tabla comparativa Una Metodología para elicitación de requisitos en proyectos GSD [AVCPS2007] La principal motivación de este trabajo es la manera en que se ha modificado el desarrollo de software, siendo ahora una actividad que puede realizarse de manera global teniendo analistas y desarrolladores en sitios remotos comunicándose entre sí con clientes y usuarios remotos. Este tipo de desarrollo se conoce como desarrollo global de software (GSD por sus siglas en inglés; Global Software Development). Este tipo de desarrollo trae consigo los siguientes problemas. La falta de comunicación cara a cara La diferencia horaria entre los sitios La gestión de información proveniente de muchas personas y sitios diferentes. La diversidad cultural El principal objetivo de esta metodología es detectar las principales fuentes de problemas en las personas involucradas en el proceso, mediante una metodología para realizar la especificación de requerimientos en proyectos de desarrollo de software global Centro Nacional de Investigación y Desarrollo Tecnológico Página 13

19 GSD tomando en cuenta aspectos tales como: un lenguaje distinto y cultura al momento de realizar la especificación de requerimientos. El nombre de esta metodología es RE-GSD (Requirement Elicitation for Global Software Development projects) Esta metodología propone estrategias para facilitar la comunicación entre personas con características diferentes sobre todo en un entorno global, para esto, utiliza una serie de formatos y guías, sin embargo no produce un SRS (Especificación de requerimientos de software) basado en algún formato estándar. En la figura 1.1 se puede apreciar las etapas que integran esta metodología. Figura 1.1 Metodología RE-GSD Metodología para la elicitación de requisitos de sistemas de software [DUBE2002] El objetivo de este trabajo fue definir una metodología que presenta las tareas a realizar, productos a obtener y las técnicas a emplear para realizar la elicitación de requerimientos, dividendo entre productos entregables (aquellos que se entregan al cliente) y no entregables (utilizados para el manejo interno del desarrollo). Esta metodología además de guiar en el proceso de especificación de requerimientos forma un SRS (Especificación de requerimientos de software por sus siglas en inglés) basado en la norma IEEE , sin embargo en comparación con la metodología que se plantea en este documento, no considera el proceso personal de especificación de requerimientos por lo que las métricas que utiliza para medir la calidad están basadas en el documento SRS que se produce. Centro Nacional de Investigación y Desarrollo Tecnológico Página 14

20 En la figura 1.2 se muestra el proceso que se lleva para lograr elaborar la especificación de requerimientos de software. Figura 1.2 Metodología para la elicitación de requerimientos [DUBE2002] Metodología DoRCU para la ingeniería de requerimientos [BABA2001] Esta es una metodología para realizar la especificación de requerimientos de software teniendo una orientación enfocada al usuario, DoRCU (Documentación de Requerimientos Centrada en el Usuario) trabaja tomando los métodos, técnicas y herramientas de otros investigadores, pero propone una serie de entregables para cada etapa que considera en la especificación de requerimientos de software (Elicitación, Análisis, Especificación y Validación), estos entregables no cuentan con un formato especifico, sólo un listado de los puntos que deben contener; además no considera el proceso personal de especificación de requerimientos y como está basado en metodologías de otros autores no utiliza formatos y guías que faciliten el proceso de especificación de requerimientos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 15

21 En la figura 1.3 se muestra el diagrama de las etapas y sus entregables de esta metodología. Figura 1.3 Metodología DoRCU [BABA2001] Tabla 1.1 Tabla comparativa con los trabajos relacionados Trabajo Una Metodología para elicitación de requisitos en proyectos GSD [AVCPS2007] Metodología para la elicitación de requisitos de sistemas de software [DUBE2002] Metodología DoRCU para la ingeniería de requerimientos [BABA2001] Metodología para la evaluación personal en la especificación de requerimientos de software(tesis) Metodología de especificación de requerimientos Enfocada a desarrollo de software global Guía en el proceso de especificación de requerimientos Toma métodos, técnicas y herramientas de distintos autores para las etapas del proceso Se utilizaran formatos, guías y métodos de evaluación para cada etapa del proceso Se forma un SRS bajo un formato estándar No (El usuario de esta metodología decide el formato a utilizar, pero no se contempla en la metodología) Si (IEEE ) No (Se menciona que el entregable es un documento de requerimientos pero no define ningún formato) Si(IEEE ) Se evalúa la calidad del proceso y producto de manera personal No No No Si Centro Nacional de Investigación y Desarrollo Tecnológico Página 16

22 1.3 Planteamiento del problema En la actualidad las empresas desarrolladoras de software buscan completar sus proyectos con éxito cumpliendo con las llamadas 3 restricciones (Alcance, costo, tiempo). En un estudio realizado por el Standish Group en el año 2009 se identificó que el 68% de los productos de software fracasan en cumplir con su alcance, costo y tiempo esperado, siendo la principal razón errores en los requerimientos con un porcentaje de 43.5%. [STANDISH2009] De este porcentaje se identificaron los siguientes 4 problemas; Requerimientos incompletos (13.1%) Falta de involucramiento del usuario (12.4%) Expectativas no realistas (9.9%) Requerimientos cambiantes (8.1%) Existen una serie de metodologías y herramientas que atienden estos problemas, sin embargo el esfuerzo de estos trabajos está enfocado al producto de la especificación y no al proceso. No se encuentran métodos definidos que permitan conocer al desarrollador su proceso personal de especificación de requerimientos; no se realiza registro de tiempos ni defectos generados en el proceso de esta especificación, tampoco se manejan métricas que permitan evaluar de manera personal este proceso. Por esta omisión el problema generado es que el desarrollador al no conocer su proceso personal no le es posible realizar un control, administración y mejora de su trabajo de especificación de requerimientos de software. 1.4 Objetivo de la tesis Ayudar al desarrollador a conocer su proceso en la especificación de requerimientos de software y con esto mejorar su trabajo, mediante una metodología que facilite el registro de métricas acerca de su desempeño, análisis y comprensión de su proceso personal. Centro Nacional de Investigación y Desarrollo Tecnológico Página 17

23 1.5 Justificación y beneficios Justificación El Standish Group realizó un estudio llamado The Chaos Report donde observó que para proyectos en el año 2009 tan solo el 32 % cumplió con las expectativas del cliente, su alcance esperado, tiempo planificado y presupuesto asignado; el 44% tuvo problemas debido a factores como un alcance menor, sobrecosto y entregados fuera de tiempo; y el 24% fue cancelado o nunca utilizado. [STANDISH2009] Resultados de proyectos en 2009 de acuerdo al estudio "The Chaos Report" Fallos 24% Completados exitosamente 32% Completados con problemas 44% Figura 1.4 Resultados de Proyectos "The Chaos Report" Dentro del estudio se realizó un análisis de los factores como problemas relacionados a los requerimientos, falta de administración de tiempos y costos del proyecto, manejo a cambios, etc. los que llevaron a que no se cumplieran de manera exitosa estos proyectos, siendo los factores relacionados a la etapa de requerimientos los que mayor impacto presentaban con un 43.5% en conjunto, dividido como se observa en la siguiente gráfica. Problemas en requerimientos 43.5% de acuerdo al estudio "The Chaos Report" Requerimientos cambiantes 19% Requerimientos incompletos 30% Expectativas no realistas 23% Falta de involucramiento del usuario 28% Figura 1.5 Problemas en requerimientos "The Chaos Report" Centro Nacional de Investigación y Desarrollo Tecnológico Página 18

24 Existen una serie de metodologías y herramientas que tratan con los problemas que se presentan en la especificación de requerimientos de software, sin embargo su esfuerzo está enfocado en entender las necesidades del cliente, verificar la calidad del documento de especificación de requerimientos de software, analizar el impacto que tiene la omisión de requerimientos en etapas posteriores y como minimizar este impacto, etc., sin embargo no consideran como factor el proceso personal de un desarrollador en la especificación de requerimientos. Es por esto que esta tesis presenta como aporte central, una metodología que permita al desarrollador conocer su proceso personal en la especificación de requerimientos de software, lo que le permitirá mejorar su trabajo en esta etapa, midiendo su proceso, determinando los puntos de fallo e introducción de defectos más comunes, mejorar sus estimaciones de tiempo y con toda esta información hacer propuestas de mejora de su propio proceso de desarrollo de una especificación de requerimientos Beneficios Permitir utilizar una serie de formatos que sirvan como apoyo a la concentración de la información requerida para realizar la especificación de requerimientos de software, estos formatos incluirán las variables más relevantes a considerar basándose en el estándar IEEE además de ideas desarrolladas en base al trabajo presentado por [AMD1993], [AVCPS2007], [BABA2001], [BOKPSP2009], [DUBE2002], [FHKMM1997], [HUMPHREY1995], [SWEBOK2004]. A lo largo del proceso se presentan guías para utilizar los elementos presentados en la metodología, además de guías para realizar el proceso de especificación de requerimientos de software. Facilitar la enseñanza del proceso de especificación de requerimientos de software. Obtener una documento de especificación de requerimientos de software (SRS, Software Requirements Specification) bajo un formato estándar (IEEE ) Definición de un estándar de tipos de defectos analizados en este proceso, para disminuir los defectos comunes que se producen en la especificación de requerimientos de software. Listas de verificación (Checklists) que permiten realizar revisiones para evitar los errores más comunes durante el proceso Plantilla de SRS que contiene los puntos básicos a incluir en el documento de especificación de requerimientos Centro Nacional de Investigación y Desarrollo Tecnológico Página 19

25 Formatos de resumen del proceso los cuales pueden ser utilizados para realizar estimaciones de esta tarea. Conocer el proceso personal de un desarrollador lo que le permita entender su trabajo y en base a esto analizar sus áreas de mejora. 1.6 Alcance y límites del proyecto Alcances Desarrollo de una metodología para la especificación de requerimientos de software basada en las prácticas que propone el PSP. Se analizará el proceso para la especificación de requerimientos de software. Se formará un documento de SRS con un formato estándar (IEEE ) Limites El documento SRS a realizar esta pensado únicamente en el estándar de la IEEE No se medirá la calidad del documento de especificación de requerimientos Se requieren nociones de PSP para trabajar de mejor manera con esta metodología. Para la especificación de requerimientos de software se consideran 3 etapas: Elicitación, Análisis, Documentación. 1.7 Conclusiones del capitulo En este capítulo se presentaron los aspectos generales de este trabajo de tesis, la metodología cumple con lo establecido de acuerdo al objetivo y beneficios acordados. En el siguiente capítulo se presentan los conceptos necesarios para comprender la investigación realizada. Centro Nacional de Investigación y Desarrollo Tecnológico Página 20

26 Capítulo 2 Marco conceptual En este capítulo se presentan los conceptos y definiciones necesarias para dar las bases teóricas que permitan familiarizarse con la metodología presentada en esta tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 21

27 2.1 Ingeniería de software La ingeniería de software es una subdisciplina de las ciencias computacionales, su principal objetivo es el desarrollo de sistemas de software de calidad mediante metodologías y técnicas de desarrollo. El proceso de desarrollo de software está integrado por una serie de etapas que conducen al software bien diseñado; la primera etapa de este proceso es la extracción de requerimientos. La ingeniería de requerimientos es la encargada de este proceso. [SOI2006] La ingeniería de requerimientos tiene como meta definir lo que se desea producir. El problema debe ser descrito con claridad y consistencia, donde se permitan expresar las necesidades de los clientes y que sirvan de mejora en los productos que se desarrollen. Se define como una subdisciplina de la ingeniería de sistemas e ingeniería de software que se ocupa por determinar las metas, funciones, restricciones de hardware y sistemas de software. [LAPLANTE2007] La parte más difícil de construir un sistema de software es decidir precisamente qué construir. No existe otra etapa del trabajo conceptual tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces para gente, máquinas y otros sistemas de software. Esta parte del trabajo afecta el sistema resultante si se hizo mal, ninguna otra parte es más difícil de rectificar después. [BROOKS1987] La importancia de esta etapa es fundamental, los requerimientos deben ser analizados, medidos, probados y relacionados para identificar las necesidades del negocio, los requerimientos deben ser definidos con el suficiente nivel de detalle para el diseño de un sistema. Esta es la razón del porqué la primera etapa en el proceso de desarrollo de un software es el análisis de requerimientos. Como productos de la ingeniería de requerimientos tenemos; Especificación de requerimientos del sistema (SyRS): Este documento tiene como propósito explicar de manera general qué es lo que debe hacer el producto en términos de las interacciones o interfaces que tiene el sistema con el ambiente exterior, este documento debe describir las entradas, salidas y relaciones que tendrá el sistema. El estándar IEEE 1233 sirve como guía para el desarrollo de este documento.[ieee 1233] Centro Nacional de Investigación y Desarrollo Tecnológico Página 22

28 Especificación de requerimientos de software (SRS): Este documento está relacionado de manera más específica con el programa a desarrollar, describe el qué debe hacer el programa pero no el cómo. Se encarga de unir al cliente que entiende cómo debe actuar el producto y el programador que entiende qué debe hacer el programa para cumplir con los requerimientos. Este documento está más enfocado al desarrollador, el estándar IEEE 830 sirve como guía para el desarrollo de este documento. [IEEE 830] Requerimientos de software Definición La IEEE define requerimiento, como una condición o capacidad que necesita el usuario para resolver un problema o alcanzar el objetivo de un sistema o componente de un sistema para satisfacer un contrato, estándar, especificación o algún otro documento formalmente impuesto. [IEEE610] Los requerimientos de un sistema de software generalmente se clasifican en requerimientos funcionales y no funcionales [SOI2006] 1. Requerimientos funcionales: Estos son los servicios que un sistema debe proveer. Cómo el sistema debe actuar a partir de ciertas entradas y cómo debe comportarse en situaciones particulares. En algunos casos los requerimientos funcionales deben definir qué es lo que el sistema no debe hacer. Estos requerimientos permiten ser medidos, mediante una serie de métricas presentada por autores como [DAA1993] 2. Requerimientos no funcionales: Estas son las restricciones en los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, restricciones en el proceso de desarrollo y estándares. Los requerimientos no funcionales generalmente aplican al sistema como un todo. Centro Nacional de Investigación y Desarrollo Tecnológico Página 23

29 Características de los requerimientos de software Existen muchas características que debe contener un requerimiento, sin embargo las más aceptadas por distintos autores son las siguientes; [AMD1993] Característica Unitario Completo Consistente Seguimiento Actual Factible Tabla 2.1 Características de un requerimiento Descripción El requerimiento atiende una sola cosa El requerimiento tiene toda la información necesaria El requerimiento no es contradictorio con otro requerimiento. El requerimiento pertenece a todo o una parte del negocio El requerimiento no se ha vuelto obsoleto por el paso de tiempo El requerimiento puede ser implementado con las restricciones del proyecto Inequívoco El requerimiento no debe poder confundirse, ni dar sentido a otras interpretaciones Obligatorio El requerimiento representa una característica necesaria cuya ausencia no puede ser aminorada. Verificable La implementación del requerimiento puede ser determinada mediante 1 de 4 posibles métodos; inspección, demostración, pruebas y análisis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 24

30 2.1.2 Etapas del proceso para la metodología de especificación de requerimientos de software Son muchos los autores que han definido las etapas del proceso de especificación de requerimientos de software, teniendo factores en común y diferencias en las etapas, sin embargo muchas coinciden en considerar como etapas base la elicitación, análisis y el registro y validación de requerimientos. [OBPRER1998] [LAPLANTE2007] [BABA2001] [SWEBOK2004] La metodología planteada en esta tesis considera como actividades base las actividades mostradas en la figura 2.1, estas actividades fueron seleccionadas porque el proceso personal del desarrollador en estas tareas tiene consecuencias directas en la elaboración de un SRS: las actividades a realizar en cada etapa están basadas en las indicaciones de [SWEBOK2004]. Debido a que la metodología planteada no evaluará la calidad del documento SRS producido la etapa de validación de esté no será considerada. Elicitacion de requerimientos: La tarea encargada de comunicarse con el cliente y usuarios para determinar cuáles son los requisitos. También se conoce como recolección de requerimientos Analisis de requerimientos: Consiste en determinar si los requerimientos son claros, incompletos, equívocos, contradictorios y resolver estos problemas. Registro de requerimientos: Los requerimientos pueden ser documentados de varias maneras, tales como documentos de lenguaje natural, casos de uso, especificación de procesos, etc. Los cuales pueden ser validados por el cliente. Figura 2.1 Etapas de la especificación de requerimientos de software Centro Nacional de Investigación y Desarrollo Tecnológico Página 25

31 2.2 Descripción del análisis de dominio orientado a las características FODA Debido a que para el trabajo de esta tesis fue necesario determinar las características indispensables que debe tener la metodología, fue utilizado FODA para detectarlas. A continuación se presenta a nivel general en que consiste este análisis. El análisis de dominio orientado a las características (FODA) tiene como principal objetivo identificar aquellas características indispensables que deberá tener un sistema dentro de un dominio específico. Estas características son aquellas que son comunes dentro del dominio, así como las diferencias entre sistemas dentro del mismo dominio. [KCHNP1990] Cada actividad del análisis de dominio provee representaciones específicas que ayudan a mostrar los resultados generados. Estas representaciones definen al alcance del dominio, características del dominio y una arquitectura para implementar soluciones. El análisis FODA consta de las siguientes etapas, figura 2.2. Análisis de contexto: en esta etapa se define el contexto del dominio describiendo su alcance, restricciones y relaciones entre otros dominios. Modelado del dominio: En base a los resultados obtenidos al realizar el análisis del contexto características comunes y diferencias son definidas. Estas características una vez analizadas producen una serie de modelos representando distintos aspectos del problema. Modelado arquitectónico: Se provee de una solución a los problemas definidos en el modelado del dominio, se desarrolla un modelo de arquitectura el cual puede ser aplicado para realizar un diseño detallado y construcción de la solución. Análisis de Dominio Análisis de contexto Modelado del dominio Modelado arquitectónico Diagrama de estructura Análisis de información Modelo de interacción del proceso Diagrama de contexto Modelado de características Grafico de la estructura del modelo Figura 2.2 Etapas del análisis FODA [KCHNP1990] Centro Nacional de Investigación y Desarrollo Tecnológico Página 26

32 2.3 Metodología Metodología puede ser definida como: Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal. [RAE] Un método se define como: Procedimiento o proceso ordenado en la ingeniería de un producto o la realización de un servicio [IEEE610] Cuando hablamos de metodología de software nos referimos al marco de trabajo utilizado para estructurar, planear y controlar el proceso de desarrollo de un sistema informático. [DHHS2008] Una metodología de software describe el como, identifica cómo se deben realizar las actividades para cada etapa, cómo representar las actividades y productos, cómo generar los productos. [LAPLANTE2007] 2.4 Proceso de software Proceso se define como: Una secuencia de pasos realizados para cumplir un propósito [IEEE610] Una serie de pasos que incluyen actividades, restricciones y recursos que producen una salida específica, usualmente un proceso involucra el uso de herramientas y técnicas. [PFLEEGER2002] En base a estas definiciones se puede decir que un proceso es el conjunto de procedimientos que deben ser realizados por una persona, haciendo uso de técnicas y herramientas para producir un producto. Cuando se habla de proceso de software, éste es el proceso que se sigue para producir software. Proceso de software puede ser definido como: Un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y herramientas, que son necesarios para concebir, desarrollar, ejecutar y mantener un producto de software. [FUGGETTA2000] Centro Nacional de Investigación y Desarrollo Tecnológico Página 27

33 Los procesos de software son complejos, como todo proceso intelectual y creativo, depende de las personas que toman decisiones y juicios [SOI2006]. Un proceso definido es una secuencia de pasos documentados para realizar un trabajo en específico, para poder realizar la definición de un proceso es necesario un trabajo que sea hecho de manera repetitiva y tenga pasos que se realizan de la misma manera cada vez que se ejecuta. Tener un proceso definido permite definir guías que ayuden a realizar el trabajo de manera correcta y completa, siguiendo una serie de pasos, realizar estimaciones y administración del proceso realizado, definir metas para cada etapa del proceso, además de un mecanismo de soporte para realizar el proyecto con calidad. 2.5 Proceso Personal El proceso personal es un conjunto definido de actividades que guía a las personas a realizar su trabajo personal [HUMPHREY2000]. Está basado en la experiencia personal y puede ser realizado tomando como base un proceso establecido y modificado de acuerdo a la persona. Tener definido un proceso personal permite la mejora de trabajo y como consecuencia realizarlo con alta calidad. Si un individuo mejora en su calidad de trabajo, como consecuencia un equipo y el proyecto también se ven beneficiados. Cuando hablamos del proceso personal para el desarrollo de software, este es el proceso de un desarrollador cuando trabaja en la creación de software. Watt S. Humphrey diseñó una metodología que puede ser utilizada por un desarrollador para conocer su proceso personal y lograr mejorar su rendimiento, el nombre de esta metodología es PSP (Personal Software Process, Proceso Personal de Software ). Centro Nacional de Investigación y Desarrollo Tecnológico Página 28

34 2.6 Conclusiones del capitulo En este capítulo se definieron los conceptos necesarios para una buena comprensión de la metodología presentada en esta tesis. Se inició estableciendo el contexto en el área de ingeniería de software específicamente en la ingeniería de requerimientos. Para el desarrollo base de la metodología presentada fue empleado el análisis de dominio orientado a las características (FODA), por lo que esta es presentada de manera general, para entender el cómo fue utilizada. Los conceptos método y metodología fueron establecidos en este capítulo, así como los conceptos de proceso de software y proceso personal. En el siguiente capítulo se muestra el desarrollo de este trabajo de tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 29

35 Capítulo 3 Desarrollo En este capítulo se presenta el desarrollo de este trabajo de investigación, este capítulo se encuentra divido en 3 partes. La primera parte consiste en presentar los resultados de aplicar el análisis de dominio orientado a las características (FODA), este análisis sirvió para establecer las bases de la metodología presentada. La segunda parte presenta las etapas y las actividades que se deben realizar en la metodología para la evaluación personal en la especificación de requerimientos de software, las actividades de estas etapas fueron establecidas en base a lo presentado en [SWEBOK2004]. Por último se presentan los elementos que son utilizados a lo largo del proceso; formatos, guías, estándares, métricas, propuesta de mejora, etc. los cuales permiten monitorear y conocer el proceso personal. Centro Nacional de Investigación y Desarrollo Tecnológico Página 30

36 3.1 Análisis de dominio orientado a las características para el desarrollo de una metodología para la evaluación personal en la especificación de requerimientos de software Introducción Se realizó un análisis FODA para detectar aquellas características indispensables para el planteamiento de una metodología, que tenga como objetivo permitir al desarrollador el conocer su proceso personal cuando realiza la etapa de especificación de requerimientos de software, Durante el capítulo 2, se mencionaron las etapas que presenta FODA, sin embargo el análisis realizado para la metodología no cubre todas las etapas que se encuentran definidas por el análisis FODA, estas actividades no realizadas son aquellas que están orientadas a la reutilización de software. Las actividades realizadas pueden ser vistas en la figura 3.1. En el Anexo 1 se presentan los resultados con mayor detalle. Análisis de Dominio Análisis de contexto Modelado del dominio Diagrama de estructura Análisis de información Diagrama de contexto Modelado de características Análisis comparativo Figura 3.1 Actividades realizadas FODA Centro Nacional de Investigación y Desarrollo Tecnológico Página 31

37 3.1.2 Análisis de contexto (FODA) En esta etapa se definió el contexto en el que la metodología presentada en esta tesis va a trabajar definiendo su alcance y relaciones con otros dominios. Para definir el alcance que tendrá la metodología se realizó una investigación de una serie de artículos que trabajan con el dominio de especificación de requerimientos de software, la definición del alcance se realiza mediante un diagrama de estructura y un diagrama de contexto además de un análisis comparativo. Diagrama de estructura El diagrama de estructura es un diagrama de bloques donde se presentan los dominios que interactúan con la metodología que se plantea, el diagrama de estructura mostrado en la figura 3.2, muestra la ubicación que tiene la metodología para la evaluación personal en la especificación de requerimientos de software respecto a otras metodologías. Como resultado de este diagrama se puede observar que de acuerdo al análisis del contexto el dominio de la metodología para la evaluación personal en la especificación de requerimientos de software, se encuentra entre el dominio de las metodologías para la especificación de requerimientos y el dominio de procesos para el desarrollo de software. Además de tener como base el estándar IEEE 830, técnicas de elaboración de metodologías e información acerca del proceso de especificación de requerimientos de software. El tener definido estos niveles permite separar las características propias que tiene la metodología con aquellas comunes de acuerdo a su dominio. Procesos de desarrollo de software PSP TSP RUP Metodología para la evaluación personal en la especificación de requerimientos de software Metodologías para la especificación de requerimientos Una Metodología para elicitación de requisitos en proyectos GSD Metodología para la elicitación de requisitos de sistemas de software Metodología DoRCU para la ingeniería de requerimientos Base de datos de la información del proceso Técnicas de elaboración de metodologías Estándar IEEE 830 Figura 3.2 Diagrama de estructura Centro Nacional de Investigación y Desarrollo Tecnológico Página 32

38 Diagrama de contexto El diagrama de contexto presenta de manera general la comunicación que deberá tener la metodología de evaluación personal en la especificación de requerimientos de software con las partes que la conformarán, este diagrama puede ser visto en la figura 3.3. Requerimientos del usuario Datos de entrada Registro de tiempos de desarrollo y defectos presentados Metodología para la evaluación personal en la especificación de requerimientos de software Almacena Procesa información Se genera Se obtiene Retroalimentación del proceso personal Manejo de métricas para la evaluación personal Especificación de requerimientos de software (SRS IEEE-830) Conocimiento del proceso personal en la especificación de requerimientos Figura 3.3 Diagrama de contexto Al analizar el diagrama que se obtuvo se observa que teniendo como entrada los requerimientos del usuario se elabora una especificación de requerimientos de software, esta metodología pretende almacenar la información acerca del desempeño del desarrollador mediante una serie de formatos de apoyo para monitorear el proceso. Como resultado de esta metodología se generará una especificación de requerimientos de software utilizando el estándar IEEE , además de obtener conocimiento acerca del proceso personal en la especificación de requerimientos de software. Teniendo los diagramas de estructura y de contexto se define el alcance que tendrá la metodología y se procede a realizar un análisis comparativo. Centro Nacional de Investigación y Desarrollo Tecnológico Página 33

39 Análisis Comparativo La actividad de análisis comparativo es la identificación de relaciones con otras metodologías que trabajan con la problemática de especificación de requerimientos, al finalizar esta etapa se obtiene una tabla comparativa de las características comunes y diferencias. Para el análisis comparativo se consideraron las siguientes características; Enfoque de aplicación, obtención de una especificación de requerimientos de software (SRS por sus siglas en inglés) bajo un formato estándar, manejo de métricas, indicadores de calidad, uso de formatos y guías, entregables en cada etapa del proceso. Esta comparativa se puede apreciar en la tabla 3.1 En esta tabla se puede observar que ninguna de las metodologías comparadas toman el proceso personal del desarrollador como factor que puede afectar la especificación de requerimientos de software, no se hace uso de herramientas como formatos y guías para facilitar el monitoreo de la especificación de requerimientos de software, ni se trabaja para realizar el documento de especificación de requerimientos bajo un formato estándar como es el IEEE Estas carencias encontradas en el análisis comparativo de los trabajos relacionados se examinaron y se evaluaron para ser integrados en la metodología presentada en esta tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 34

40 Tabla 3.1 Tabla comparativa de metodologías Características Una Metodología para elicitación de requisitos en proyectos GSD Metodología para la elicitación de requisitos de sistemas de software Metodología DoRCU para la ingeniería de requerimientos Enfoque de aplicación de la metodología de especificación de requerimientos Enfocada a desarrollo de software global. Define una guía en el proceso de especificación de requerimientos considera 3 etapas del proceso. Toma métodos, técnicas y herramientas de distintos autores para las etapas del proceso. Se obtiene un SRS bajo un formato estándar El usuario de esta metodología decide el formato a utilizar, pero no se contempla en la metodología IEEE Se menciona que el entregable es un documento de requerimientos pero no define ningún formato Se evalúa el proceso de manera personal No, solo interesa el resultado de la especificación y no el proceso. No, solo trabaja para conseguir un SRS bajo un formato estándar. No, solo considera los productos para cada etapa de especificación pero no el proceso personal. Manejo de métricas No Si, enfocadas al SRS No Indicadores de calidad No Si No Uso de formatos y guías Si, para realizar la elicitación de requerimientos Si, para definir los entregables en cada etapa No Entregables en cada etapa del proceso de especificación No, solo el resultado de la especificación se evalúa al final Si, para cada una de las etapas define una parte para el usuario y otra para el ingeniero de software. Si, para cada etapa considera un entregable distinto. Centro Nacional de Investigación y Desarrollo Tecnológico Página 35

41 3.1.3 Modelado del dominio (FODA) En esta etapa se identifican las características comunes y diferencias del dominio, produciendo una serie de modelos que representan diferentes aspectos del problema; las actividades realizadas en esta etapa son; análisis de información y análisis de características. Análisis de la información El análisis de información consiste en las siguientes partes; 1. Un diagrama entidad relación 2. Atributos de las entidades 3. Relaciones de las entidades Este diagrama con sus atributos y relaciones puede ser visto en la figura 3.4 Figura 3.4 Análisis de información Centro Nacional de Investigación y Desarrollo Tecnológico Página 36

42 Análisis de características El propósito del análisis de características es identificar las características principales que debe contener la metodología que se desea plantear, este modelo debe contener todas las características que se pudieron identificar mediante el análisis de información. Diagrama de características Diagrama que describe la descomposición de las características en sub características de manera jerárquica. Figura 3.5 Diagrama de característica En el Anexo 1 se presentan los resultados con mayor detalle. Este análisis sirvió para establecer las bases de la metodología presentada en esta tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 37

43 3.2 Etapas de la metodología para la evaluación personal en la especificación de requerimientos de software La ingeniería de requerimientos tiene como meta definir lo que se desea producir. El problema debe ser descrito con claridad, donde se permitan expresar las necesidades de los clientes y que sirvan de mejora en los productos que se desarrollen. Son muchos los autores que han definido las etapas del proceso de especificación de requerimientos de software, teniendo factores en común y diferencias en las etapas, sin embargo coinciden en considerar como etapas base: la elicitación, análisis y el registro y validación de requerimientos. [OBPRER1998] [LAPLANTE2007] [BABA2001] [SWEBOK2004] La metodología planteada considera las actividades mostradas en la figura 3.6, estas actividades fueron seleccionadas porque el proceso personal del desarrollador en estas tareas, tiene consecuencias directas en la elaboración de un SRS, las actividades a realizar en cada etapa están basadas en las indicaciones de [SWEBOK2004]. Debido a que la metodología planteada no evaluará la calidad del documento SRS producido la etapa de validación de esté no será considerada. Además de las etapas comunes en el proceso de especificación de requerimientos de software, fueron agregadas 2 nuevas etapas, la etapa de planeación y la etapa de postmortem, estas etapas son fundamentales para el trabajo con la metodología de evaluación personal en la especificación de requerimientos de software. A continuación se muestra cada una de las etapas que forman a la metodología, iniciando desde los datos de entrada que sería la petición del cliente y tener listo el formato de resumen, bitácoras y checklists, hasta la salida teniendo como producto una especificación de requerimientos de software basada en el estándar IEEE830, además de la retroalimentación del proceso realizado. Para cada una de las etapas se pondrá el objetivo de cada etapa así como una descripción de las actividades a realizar en esa etapa. Centro Nacional de Investigación y Desarrollo Tecnológico Página 38

44 Figura 3.6 Etapas de la metodología Datos de entrada Objetivos Recibir la petición del cliente para iniciar el proceso de especificación de requerimientos de software Tener preparado los elementos que serán utilizados en la metodología Descripción El primer paso en el desarrollo de la especificación de requerimientos de software, utilizando la metodología para la evaluación personal en la especificación de requerimientos de software, es utilizar la guía MEPERS 1.0. Esta guía será mostrada en la siguiente sección. Además es necesario el tener preparado el material que será usado a través del proceso, siendo este la bitácora de tiempo, la bitácora de defectos, el estándar de defectos presentado por la metodología y el formato de resumen del plan del proyecto. Teniendo estos elementos y la petición del cliente, el desarrollador inicia con los pasos mostrados en la guía MEPERS. Centro Nacional de Investigación y Desarrollo Tecnológico Página 39

45 3.2.2 Planeación Objetivos Realizar un análisis de dominio Estimar el tiempo de desarrollo Un análisis verificado mediante el Checklist de planeación Descripción Esta etapa tiene gran importancia, ya que sin una buena planeación no se puede administrar de manera correcta los tiempos de entrega y el esfuerzo requerido. La planeación tiene la gran ventaja que cada vez que se realice se puede aprender y mejorar, para con esto realizar compromisos que se puedan cumplir. Sin embargo a diferencia de la codificación de software, las estimaciones y calendarizaciones de los tiempos no está sujeta únicamente al trabajo realizado previamente. Influye un factor importante y este es tener conocimiento del dominio en el cual trabaja el software a desarrollar. Por esta razón, en esta etapa la primera actividad a realizar es un análisis de dominio o negocio, con el cual el desarrollador podrá ubicarse en el contexto del problema, entendiendo los conceptos y el vocabulario utilizado. La metodología presenta la guía de análisis de dominio para apoyar en esta tarea. Una vez realizado el análisis del dominio el desarrollador podrá realizar estimaciones y calendarizaciones más certeras. Para esto el desarrollador deberá usar el formato de estimación de tamaño. Debido a la importancia de la etapa de planeación, la metodología presenta el uso del checklist de planeación donde se podrá verificar que las tareas que se realizaron cumplen con las necesidades básicas para una buena planeación. Como cualquier etapa de la metodología, la etapa de planeación cuenta con su propia guía. Además antes de continuar con la etapa de elicitación se debe de completar el checklist de planeación. Centro Nacional de Investigación y Desarrollo Tecnológico Página 40

46 3.2.3 Desarrollo La etapa de desarrollo presentada en la metodología consiste en 3 subetapas; Elicitación, Análisis y Registro de requerimientos. La siguiente sección describe cada una de estas subetapas Elicitación Objetivos elicitación Los objetivos que se cumplen en esta etapa son Conocimiento de las fuentes de información de requerimientos Selección de técnica de elicitación de requerimientos Identificación de los requerimientos del cliente. Descripción La elicitación de requerimientos de software es el mecanismo para detectar de dónde vendrán los requerimientos de software y cómo un ingeniero de software puede recolectarlos. Esta es la primera etapa en el desarrollo de un software donde se debe entender claramente el problema a resolver. En esta actividad se identifica a las personas, usuarios o actores que trabajarán con el sistema, y se establece la relación entre el equipo de desarrollo y los involucrados. Por esto se debe tener una buena comunicación entre los usuarios y los desarrolladores de software. Las tareas que se deben realizar para cumplir con los objetivos son las siguientes 1. Identificar fuentes de requerimientos. 2. Selección de técnica de elicitación de requerimientos. Como cualquier etapa de la metodología, la etapa de elicitación cuenta con su propia guía. Además antes de continuar con la etapa de análisis se debe de completar el checklist de elicitación. Centro Nacional de Investigación y Desarrollo Tecnológico Página 41

47 Identificar fuentes de requerimientos Cuando se va a realizar la elicitación de requerimientos es de suma importancia identificar las fuentes de información, de lo contrario el sistema no cumplirá con las necesidades de la comunidad de clientes tanto lógicos como físicos. Para lograrlo se recomienda cumplir con los siguientes puntos. Identificar las metas: Las metas son los objetivos generales que debe cubrir el software, se deben identificar clasificándolas según su prioridad y un valor de medida. Conocimiento del domino: El desarrollador debe obtener y tener disponible información del dominio de aplicación del sistema. Esto le permitirá identificar los requerimientos de los involucrados de mejor manera. Actores: Se deben de identificar los actores del proceso porque con ellos se trabajará para realizar la identificación de requerimientos aplicando técnicas de elicitación de requerimientos. Ambiente operacional: Los requerimientos se obtendrán de acuerdo al ambiente donde se ejecutará, por esto se deben identificar las restricciones que impondrá el ambiente, por ejemplo para un sistema médico de cirugías el software debe trabajar en tiempo real y esta restricción debe tomarse en cuenta para cumplir con los requerimientos. Selección de técnica de elicitación de requerimientos Una vez que se identificaron las fuentes de información el desarrollador continua con la elicitación de requerimientos, se debe considerar que las personas elicitadas en muchos casos son humanas y por lo tanto, pueden surgir problemas como descripciones incompletas, omisiones de información, poca cooperación, etc. Existen muchas técnicas que se pueden emplear para realizar la elicitación, siendo las más comunes las siguientes. [SWEBOK2004] Entrevistas: Esta es la manera más común de elicitar requerimientos, es importante entender las ventajas y limitaciones de las entrevistas y cómo deben ser conducidas. Es recomendable tener habilidades de comunicación. Centro Nacional de Investigación y Desarrollo Tecnológico Página 42

48 Escenarios: Al hacer escenarios se facilita ubicar a la fuente dentro del contexto, estos permiten que el ingeniero de software provea una serie de preguntas acerca de las actividades del usuario, considerando un qué tal si sucede esto. El tipo más común de escenario son los casos de uso. Prototipos: Es una herramienta muy importante para aclarar requerimientos. Se ubica al usuario en un contexto donde es más fácil entender la información que deben proveer. Existen varias técnicas desde diseño en papel de la interfaz hasta versión beta de productos de software. Reuniones: Se debe juntar a un grupo de gente que permita alcanzar una mejor idea de los requerimientos. Pueden realizar lluvia de ideas y refinarlas, lo cual es difícil en una entrevista. Aquellos requerimientos que causen conflicto se identifican de manera sencilla, si se maneja de manera adecuada, se pueden localizar requerimientos de buena calidad. Se debe llevar un moderador que permita la comunicación correcta con el grupo. Observación: Consiste en conocer el ambiente de la organización, el ingeniero de software se involucra con las tareas del usuario y observa la manera en que interactúan. Esta técnica es cara pero permite una visión de las actividades y procesos de negocios que son difíciles de describir por los usuarios Análisis Objetivos análisis Los objetivos que se cumplen en esta etapa son Detectar y resolver conflictos entre requerimientos. Delimitar el alcance del software y como interactúa con el ambiente operacional. Descripción y clasificación precisa de los requerimientos. Descripción Posteriormente a la elicitación de requerimientos comienza esta actividad, donde se verifica si los requerimientos que fueron identificados son los adecuados o es necesario refinarlos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 43

49 Una de las técnicas que usualmente se lleva a cabo es realizar un bosquejo inicial del documento de requerimientos, a partir de este bosquejo se realiza un análisis detallado, se investiga la información necesaria para cumplir los requerimientos de los actores, se comparan con experiencias pasadas, se comparten ideas con los involucrados en el proyecto, todo esto con el fin de resaltar los problemas buscando alternativas y soluciones. Para que esta actividad se desarrolle de una manera adecuada, es importante tener comunicación con los actores, sin embargo esta tarea depende del buen juicio y experiencia de la persona encargada de la recolección de requerimientos. Al finalizar esta etapa se tendrá una representación de la información de manera detallada teniendo un formato técnico, lo cual permitirá reducir ambigüedades presentes durante la elicitación, además de facilitar la definición del futuro diseño. [OBPRER1998] Las tareas que se deben realizar para cumplir con los objetivos son las siguientes Clasificación de los requerimientos. Modelado conceptual. Resolución de conflictos. Como cualquier etapa de la metodología la etapa de análisis cuenta con su propia guía. Antes de continuar con la etapa de registro se debe completar el checklist de análisis. Clasificación de los requerimientos Los requerimientos deben ser clasificados para facilitar el análisis y detectar problemas introducidos en la elicitación. Se deben considerar las siguientes características: Diferenciar requerimientos funcionales y no funcionales. Requerimientos impuestos por los actores. Identificar si algún requerimiento debe cumplir con algún estándar. Identificar la prioridad de los requerimientos. Modelado conceptual Para realizar un correcto análisis es conveniente utilizar modelos que representen el problema en el mundo real, este modelo tiene como propósito entender el problema más que hacer el diseño de la solución. Estos modelos deben incluir las entidades, sus relaciones y dependencias. Centro Nacional de Investigación y Desarrollo Tecnológico Página 44

50 Existen muchas técnicas de modelado que se pueden emplear, por ejemplo; flujos de datos y control, estado, eventos, interacciones del usuario, modelado de objetos, modelado de datos, etc. Los factores que se deben considerar para realizar el modelado son los siguientes: La naturaleza del problema: Las características que deben cubrir los requerimientos de acuerdo a su naturaleza demandan una mayor atención, por ejemplo: en sistemas de tiempo real es conveniente utilizar un modelo de estados a diferencia de un sistema administrativo, donde el flujo de datos tiene mayor importancia. Experiencia del desarrollador: Si el desarrollador tiene experiencia trabajando con ciertas técnicas de modelado muchas veces la productividad aumenta. Requerimientos del cliente: El cliente puede definir el modelado que desee y con esto el desarrollador debe trabajar tomando en cuenta las consideraciones del cliente. Disponibilidad de métodos y herramientas. Se recomienda realizar estos modelos trabajando con técnicas que han sido aceptadas por gran parte de la industria del software como es UML (Lenguaje Unificado de Modelado). Resolución de conflictos Esta actividad consiste en arreglar los conflictos generados entre 2 o más actores, cuyos requerimientos no permiten una correcta compatibilidad, se contradicen o no se permite una correcta clasificación, el desarrollador no debe tomar esta decisión de acuerdo a la opinión de un sólo actor, por lo que se recomienda consultar con los involucrados para llegar a una decisión consensuada. Centro Nacional de Investigación y Desarrollo Tecnológico Página 45

51 Registro Objetivo Obtener un documento de especificación de requerimientos de software Descripción En esta etapa los requerimientos que fueron obtenidos y analizados proceden a ser documentados con un detalle muy apropiado y de acuerdo al público al que va dirigido, generalmente se utiliza algún estándar para facilitar esta tarea (Por ejemplo IEEE 830). La forma en que este documento se prepare afecta la solución, ocasionando problemas con su calidad, por esto es importante tener cuidado al elaborarlo. Este documento será revisado, evaluado y aprobado. La metodología planteada utilizará el estándar IEEE 830 para formar un documento de especificación de requerimientos. Como cualquier etapa de la metodología la etapa de registro cuenta con su propia guía. Para facilitar el llenado del SRS se definió una plantilla. Esta plantilla puede ser vista en el anexo1. IEEE std [IEEE830] Este documento es una descripción completa del comportamiento del sistema a ser desarrollado. Incluye un conjunto de casos de usos que describen las interacciones que tiene los usuarios con el software. Los casos de uso también son conocidos porque ayudan a representar de manera gráfica los requerimientos funcionales. También el SRS contiene los requerimientos no funcionales, los cuales definen restricciones en el diseño o implementación. La especificación de requerimientos de software permite un aseguramiento de los requerimientos antes de que el diseño inicie. Debe proveer una base real para estimar los costos, riesgos y tiempo de un producto. Centro Nacional de Investigación y Desarrollo Tecnológico Página 46

52 Las organizaciones pueden usar un documento de especificación de requerimiento de software para desarrollar sus propios planes de validación y verificación de manera más productiva, además de proveer la base para mejoramiento de software Postmortem Objetivos Los objetivos que se cumplen en esta etapa son Analizar la información del proceso de especificación de requerimientos de software Elaborar una propuesta de mejora Descripción Con esta etapa finaliza el trabajo realizado con la metodología para la evaluación personal en la especificación de requerimientos de software, esta etapa es fundamental ya que mediante esta se recibe la retroalimentación del proceso y con esto se logra conocer el proceso personal del desarrollador Toda la información del proceso será tomada de los distintos formatos y bitácoras con el fin de llenar el formato del resumen del proyecto, con esto el desarrollador podrá saber que metas cumplió y cuáles no, problemas a los que se enfrentó el desarrollo, etc. Es necesario realizar esta etapa por cada trabajo de especificación de requerimientos realizado, ya que por cada trabajo se aprende y con esto se logra mejorar. Como cualquier etapa de la metodología la etapa de postmortem cuenta con su propia guía. Centro Nacional de Investigación y Desarrollo Tecnológico Página 47

53 3.3 Elementos que integran la metodología para la evaluación personal en la especificación de requerimientos de software En esta sección se presentan los elementos que son utilizados a lo largo de las etapas de la metodología presentada en esta tesis. En la primera sección se explican los conceptos de estos elementos, su uso, así como su organización en las distintas etapas que integran la metodología. En la segunda sección se presentan las métricas empleadas para realizar el análisis del proceso En la tercera y última sección se muestran los distintos elementos clasificados de acuerdo a su orden de uso a través de las etapas de la metodología propuesta Formatos, guías, bitácoras y estándares de la metodología Para el diseño de los formatos se tomó como base los trabajos de Watts Humphrey de PSP y TSP, algunos formatos únicamente se adaptaron a la metodología presentada. [HUMPHREY1995], [HUMPHREY2000], [BOKPSP2009]. Para el desarrollo de los elementos que integran la metodología se definieron claramente las etapas de está. El diagrama de las etapas puede ser visto en la figura 3.7. Figura 3.7 Etapas de la metodología Centro Nacional de Investigación y Desarrollo Tecnológico Página 48

54 En la figura 3.8, se muestra un diagrama con las etapas, los formatos y guías que forman parte de la metodología. Figura 3.8 Etapas y sus formatos Centro Nacional de Investigación y Desarrollo Tecnológico Página 49

55 Para realizarlos se tomaron las mejores prácticas presentadas en [SWEBOK2004] y resultados de otras metodologías de especificación de requerimientos Los formatos, guías, bitácoras y estándares son la herramienta más importante de la metodología, gracias a estos la información del proceso puede ser almacenada y posteriormente analizada. Las bitácoras de tiempos y defectos serán tomadas directamente del trabajo presentado en PSP, ya que se consideran adecuadas y no es necesario hacerle ninguna adaptación para usarlas en la metodología presentada. Además se elaboró un estándar de defectos en la etapa de requerimientos tomando como base, la información presentada en [YOUNG2001] Guías A continuación una descripción general de estos elementos. Las guías son descripciones que ayudan a seguir una serie de pasos para el proceso, contienen indicaciones de que formatos, estándares, revisiones y subguías deben utilizarse. Una guía puede ser definida para todo el proceso o para una tarea en particular. Una guía contiene el propósito del proceso u objetivo, datos de entrada, pasos a seguir, consideraciones de uso, restricciones y por último los datos de salida. Formatos Los formatos son una herramienta de trabajo que ayuda a obtener y almacenar información del proceso, los formatos especifican la información requerida y donde guardarla. Pueden utilizarse los formatos en papel si no se cuenta con herramientas automatizadas para recolectar y almacenar la información. Las Checklists son formatos especializados que guían a realizar revisiones de manera personal, cada revisión verifica aspectos del producto cumpliendo con estándares o especificaciones. Los puntos que se deben considerar en la revisión son los defectos más frecuentes que suceden en el proceso personal. Estas revisiones deben realizarse concentrándose en un solo punto, a la vez que evitar que los defectos continúen a otra etapa del proceso. Centro Nacional de Investigación y Desarrollo Tecnológico Página 50

56 Bitácoras Las bitácoras son usadas para registrar y almacenar la información del proceso, en la metodología se utilizarán la bitácora de tiempo y la bitácora de defectos presentadas en PSP. Estándares Los estándares permiten un trabajo preciso y conciso, al aplicarlos correctamente permiten realizar la medición de manera confiable y consistente con el trabajo realizado, estos estándares pueden ser basados en estándares previamente establecidos, pero adaptados al proceso personal de especificación de requerimientos de software. En la presente metodología se considerara para el documento de SRS el estándar IEEE , además de proponer un estándar de defectos el cual se presenta en la sección Centro Nacional de Investigación y Desarrollo Tecnológico Página 51

57 3.3.2 Métricas A continuación se muestran las métricas que son utilizadas para realizar el análisis del proceso de especificación de requerimientos. Algunas de estas métricas fueron tomadas del trabajo desarrollado por Watts Humphrey, siendo adaptadas de acuerdo a las necesidades del proceso de especificación de requerimientos de software. Además como parte del trabajo de tesis desarrollado se proponen unas métricas para la especificación de requerimientos de software Métricas adaptadas de PSP En PSP se consideran 3 tipos de medidas básicas: tamaño, esfuerzo y defectos, a partir de estas se derivan otras métricas, para poder realizar el análisis, se toma la información almacenada en los distintos formatos y bitácoras, esta información se almacena de manera histórica para conocer el proceso. Sin embargo muchas de las métricas presentadas en PSP están enfocadas a la codificación de software y estas métricas no pueden ser utilizadas en una metodología de especificación de requerimientos. Tomando esto en cuanta, las métricas que se pudieron adaptar a la metodología se muestran en la tabla 3.2. Tabla 3.2 Métricas adaptadas de PSP Métrica Descripción Uso o utilidad Tiempo planeado de desarrollo Tiempo actual de desarrollo Tiempo planeado por etapa El tiempo total planeado en desarrollar una especificación de requerimientos de software El tiempo total actual en desarrollar una especificación de requerimientos de software El tiempo planeado por cada etapa El tener el histórico de esta información permitirá una mejor estimación y por lo tanto una mejor planeación del proceso de especificación de requerimientos de software Permite comparar el tiempo real que tomo la especificación de requerimientos de software en relación al tiempo estimado El realizar estas estimaciones se pueden tener una mejor administración del tiempo según la etapa. Centro Nacional de Investigación y Desarrollo Tecnológico Página 52

58 Tiempo actual por etapa Defectos insertados por etapa Defectos removidos por etapa El tiempo que tomo cada etapa Los defectos insertados en cada etapa Los defectos removidos en cada etapa Permite comparar el tiempo real que tomo la especificación de requerimientos de software en relación al tiempo estimado en una etapa especifica El registrar esta información permite identificar en qué etapa del proceso se introducen mayor cantidad de defectos. El registrar esta información permite identificar en qué etapa del proceso se detectan los defectos y su tipo de defecto más común. Métricas propuestas La siguiente tabla muestra las métricas que propone la metodología presentada en esta tesis, sin embargo estas aun no cuentan con la retroalimentación necesaria para considéralas útiles, siendo este un trabajo futuro, ya que se requiere un mayor número de personas analizando su proceso en distintos ejercicios y con esto validar su utilidad. Tabla 3.3 Métricas propuestas por la metodología Métrica Descripción Utilidad N de actores Número de actores afectados en el desarrollo del producto Saber el número de actores permite encontrar una posible relación entre el tiempo y los defectos N de técnicas de elicitación utilizadas N de personas elicitadas N veces que se revisaron los requerimientos con la misma persona N requerimientos antes del análisis N requerimientos funcionales Número y nombre de las técnicas utilizadas de elicitación Número de personas con las que se trabajó la elicitación de requerimientos Número de veces que se volvió a realizar una sesión de elicitación debido a problemas en los requerimientos Numero de requerimientos encontrados en la etapa elicitación y la etapa de revisión de elicitación Numero de requerimientos funcionales. encontrados en el proceso. Identificar cuáles son las técnicas más utilizadas y que mayor número de requerimientos son encontrados. Saber el número de personas que participaron en la elicitación permite encontrar una posible relación entre el tiempo y los defectos encontrados en el proceso. Identificar las causas que originaron que se repitieran sesiones de elicitación Permite identificar los requerimientos que se encontraron antes de hacer uso de las checklists Realizar estimaciones de tamaño del documento de SRS Centro Nacional de Investigación y Desarrollo Tecnológico Página 53

59 N conflictos en requerimientos N requerimientos reusados N páginas del documento de especificación de requerimientos Numero de requerimientos que presentaron conflictos, no cumplieron con el estándar de requerimientos. Numero de requerimientos reusados de proyectos previos, debido a similitudes o un análisis de sistemas anteriores Número de páginas que tuvo el documento al ser realizado Realizar un mejor análisis de los defectos y su tipo que se presentan en el proceso Para poderlos separar del esfuerzo empleado en el desarrollo de la especificación de requerimientos Realizar estimaciones de tamaño del documento de SRS Centro Nacional de Investigación y Desarrollo Tecnológico Página 54

60 3.3.3 Estándar de defectos propuesto Para definir este estándar se tomaron los puntos que deben de considerar los requerimientos de acuerdo al trabajo presentado en [MEBFN2011], [IEEE830] Tabla 4.1 Estándar de defectos Código Tipo Descripción 10 Documentación Comentarios, mensajes 20 Sintaxis Ortografía, puntuación, tipos 30 Requerimientos Cualquier tipo de error no definido en requerimientos 40 Justificado El requerimiento no tiene justificación 50 Correctitud El requerimiento no atiende una sola cosa 60 Completitud El requerimiento no tiene toda la información necesaria 70 Consistencia El requerimiento es contradictorio con otro requerimiento. 80 No ambigüedad El requerimiento se confunde o tiene sentido a otras interpretaciones 90 Factibilidad El requerimiento no puede ser implementado con las restricciones del proyecto 100 Abstracto El requerimiento no se define de manera clara, ni se plantea su propósito con claridad. 110 Seguible El requerimiento no permite conocer si pertenece a todo o una parte del negocio 120 Delimitado El requerimiento no está limitado 130 InterfazReq El requerimiento no tiene definidas sus interfaces 140 Elegible El requerimiento no puede ser identificado claramente 150 Modificable El requerimiento no puede ser modificado 160 Verificable Problemas en inspección, demostración, pruebas o análisis. 170 Priorizado El requerimiento tenía problemas con su prioridad 180 Aprobado El requerimiento no fue aprobado. Centro Nacional de Investigación y Desarrollo Tecnológico Página 55

61 3.3.4 Elementos de la metodología usados a través del proceso A continuación se muestran los elementos que serán utilizados a través del proceso de especificación de requerimientos de software, cada formato presentado cuenta con su respectiva guía. Elementos usados a lo largo de las etapas de la metodología Los siguientes elementos son empleados en cualquier etapa de la metodología, estos son: Guía MEPERS (Metodología para la evaluación personal en la especificación de requerimientos de software) Bitácora de tiempos Bitácora de defectos Estándar de defectos Guía MEPERS Esta guía presenta, a nivel general, las actividades que deberán realizarse, desde la petición del cliente para iniciar una especificación de requerimientos hasta finalizar con un documento de especificación de requerimientos, utilizando la metodología de evaluación personal en la especificación de requerimientos de software (MEPERS). Fase Propósito Guiar en el desarrollo de una especificación de requerimientos de software Criterios de entrada Descripción general del problema Formato de resumen de plan de proyecto de requerimientos 1.0 Bitácoras de tiempos y defectos Estándar de tipos de defectos Checklists 1 Planeación Realizar un análisis del dominio del problema (Guía del dominio del problema) Estimar el tiempo de desarrollo Formato de estimación de tamaño Formato de planeación de tareas Introducir los datos del plan en el formato de resumen de plan de proyecto de requerimientos 1.0 Realizar la verificación de la etapa de planeación del proceso de especificación de requerimientos, arreglando y registrando los defectos encontrados. Centro Nacional de Investigación y Desarrollo Tecnológico Página 56

62 Registro en las bitácoras de tiempos y defectos 2 Desarrollo Elicitar requerimientos Realizar la verificación de la elicitación, arreglando y registrando los defectos encontrados. Análisis de requerimientos Realizar la verificación del análisis, arreglando y registrando los defectos encontrados. Registro de requerimientos Registro en las bitácoras de tiempos y defectos 3 Postmortem Completar las tablas de tiempo y defectos Completar el resumen del plan de proyecto de requerimientos 1.0 Criterios de salida Una especificación de requerimientos de software Formato completo de resumen del plan de proyecto de requerimientos Checklists verificadas Formato PIP Bitácoras de tiempos y defectos completas Centro Nacional de Investigación y Desarrollo Tecnológico Página 57

63 Bitácora de tiempo Propósito Esta bitácora sirve para registrar el tiempo que toma en realizar cada etapa del proyecto. La información obtenida servirá para completar el formato del resumen del plan de proyecto de requerimientos Información Registrar el tiempo invertido en la especificación de requerimientos general Registrar el tiempo en minutos. Encabezado Se debe llenar lo siguiente Nombre Fecha actual Numero de proyecto Breve descripción del proyecto Fecha Registrar la fecha cuando se realiza la entrada de información Inicio Registrar la hora cuando se inicia a trabajar con una tarea Alto Registrar la hora cuando se para el trabajo con una tarea Tiempo de Registrar el tiempo consumido durante las interrupciones Interrupción Delta Tiempo Registrar el tiempo invertido en la tarea menos la diferencia del tiempo de interrupción Etapa Registrar el nombre de la etapa con la que se estaba trabajando Comentarios Registrar los comentarios que se consideren convenientes en la etapa presentada Importante Se debe registrar toda la información en la bitácora de tiempos, de no hacerlo al momento se debe tomar la mejor estimación posible Figura 4.1 Bitácora de tiempo Centro Nacional de Investigación y Desarrollo Tecnológico Página 58

64 Bitácora de defectos Propósito En este formato se registran los defectos encontrados y su corrección La información obtenida servirá para completar la forma del resumen del plan del proyecto de requerimientos. Información General Registrar los defectos encontrados en la elicitación, análisis y registro de requerimientos Registrar cada defecto de forma separada y completa. Encabezado Se debe llenar lo siguiente Nombre Fecha actual Numero de proyecto Breve descripción del proyecto Fecha Registrar la fecha de cuándo el defecto es encontrado. Número Registrar el número de defecto de manera secuencial. Tipo Registrar el tipo de defectos de acuerdo al estándar de defectos Introducido Registrar la etapa donde el defecto fue introducido Removido Registrar la etapa donde el defecto fue removido Tiempo de arreglo Registrar el tiempo que tomó realizar el arreglo del defecto Arreglo de defecto Si se introdujo el defecto mientras se arreglaba otro se debe registrar el número de defecto que ocasionó el defecto registrado. Descripción Registrar la descripción de la causa que originó el defecto y como se arregló. Figura 4.2 Bitácora de defectos Centro Nacional de Investigación y Desarrollo Tecnológico Página 59

65 Elementos utilizados en la etapa de planeación A continuación se muestran los elementos que son utilizados en la etapa de planeación del proceso de especificación de requerimientos de software, cada formato presentado cuenta con su respectiva guía, estos son: Guia de la etapa de planeación Guía del dominio del problema Formato de participantes del proyecto Formato de estimación de tamaño Formato de planeación de tareas Checklist de planeación A continuación se presentan estos elementos. Guía de la etapa de planeación El propósito de esta guía es ayudar a seguir el proceso a realizar en la fase de planeación de una especificación de requerimientos de software utilizando MEPERS. Esta guía dirige el desarrollo de las actividades de planeación iniciando con la petición del cliente, aprendizaje del dominio del problema, planeación de las actividades y estimaciones de tiempo de desarrollo. Antes de finalizar se inicia la primera verificación mediante el formato de verificación de planeación. Al finalizar, el desarrollador cuenta con conocimiento acerca del dominio del problema y la estimación de tiempo de desarrollo de la especificación de requerimientos que será invertido. Fase Propósito Guiar en la fase de planeación de una especificación de requerimientos de software utilizando MEPERS. Criterios de entrada Descripción general del problema Formato de resumen de plan de proyecto de requerimientos 1.0 Formato de planeación de tareas Bitácoras de tiempos y defectos Datos históricos del tiempo actual y estimado 1 Análisis del Realizar un análisis del dominio del problema dominio del (Guía del dominio del problema) problema 2 Estimación de En base a datos históricos realizar una estimación tamaño y tiempo de tamaño y tiempo. Centro Nacional de Investigación y Desarrollo Tecnológico Página 60

66 3 Calendarización de actividades 4 Verificación de la planeación Criterios de salida Introducir las estimaciones en el formato de resumen del plan del proyecto de especificación de requerimientos 1.0 Las actividades a realizar deben ser calendarizadas, se pueden utilizar herramientas de planeación por ejemplo los diagramas de Gantt Se sugiere utilizar el formato de planeación de tareas si no se utiliza alguna herramienta de soporte automatizada Seguir el checklist de planeación y verificar las actividades realizadas en esta etapa. Arreglar los defectos encontrados. Registro en las bitácoras de tiempos y defectos Conocimiento del dominio del problema Formato completo de estimación de tamaño Formato completo de planeación de tareas Formato completo de resumen del plan de proyecto de especificación de requerimientos con sus estimaciones de tamaño y tiempo Bitácoras de tiempos y defectos para la planeación Guía del dominio del problema Esta guía es una subguía de la guía de planeación de requerimientos de software. Fase Propósito Conocer el dominio del problema definiendo las fuentes de información, participantes del proyecto, cliente o clientes y el glosario a ser utilizado Criterios de entrada Conocer a nivel general el dominio del problema Bitácora de tiempos y defectos Formato de participantes del proyecto Plantilla del SRS 1 Recopilación de fuentes de información del dominio del problema Se debe realizar una recopilación de fuentes de información que ayudaran a entender el problema, por ejemplo; libros, artículos, revistas, páginas web, etc. Si se cuenta con un sistema actual, este debe ser analizado. 2 Definición de Se debe llenar el formato de participantes del Centro Nacional de Investigación y Desarrollo Tecnológico Página 61

67 participantes proyecto del proyecto, definiendo al grupo desarrollador, al cliente o clientes y usuarios del sistema actual. 3 Elaboración del glosario 4 Actividades para el SRS Para un mejor entendimiento del dominio es necesario realizar un glosario con el vocabulario propio del dominio. Utilizando las fuentes de información y el glosario se redacta la introducción que tendrá el SRS y se registra en la plantilla del SRS. Utilizando el formato de participantes del proyecto, los participantes se registraran en la plantilla del SRS En caso de haber realizado un análisis al sistema actual, esta información debe ser descrita como parte del SRS y registrada en la plantilla del SRS. Criterios de salida Análisis del dominio del problema Bitácora de tiempos y defectos para el análisis del dominio Además Con estas actividades, se tendrá como parte del SRS lo siguiente; 1. Introducción 2. Participantes del proyecto 3. Información del sistema actual Formato de participantes del proyecto Este formato tiene como propósito registrar a las personas participantes en el proyecto de especificación de requerimientos, toda la información registrada servirá para definir a las personas que se trabajara durante la elicitación de requerimientos Además la sección de participantes del proyecto forma parte del SRS Propósito Este formato sirve para registrar a las personas participantes en el proyecto, quienes se conocerán como actores La información obtenida servirá para definir a las personas con las que se trabajará y deberá realizarse la elicitación de requerimientos. Además la sección de participantes del proyecto forma Información general parte del SRS Registrar a todos los participantes del proyecto Como campos obligatorios es necesario el registro del Centro Nacional de Investigación y Desarrollo Tecnológico Página 62

68 Encabezado Nombre Rol Nivel profesional Responsabilidades nombre y su información de contacto. Se debe llenar lo siguiente Nombre Fecha actual Numero de ejercicio Breve descripción del ejercicio Registrar el nombre del participante del proyecto Registrar el rol que desempeña el participante del proyecto Registrar el nivel profesional del participante del proyecto Registrar las responsabilidades que tiene con el sistema el participante del proyecto Registrar información mediante la cual se le puede contactar, por ejemplo un correo electrónico o número telefónico. Información de contacto Importante Es importante registrar la mayor cantidad de personas involucradas en el proyecto para facilitar la elicitación de requerimientos y lograr identificar las fuentes de requerimientos. Además esto podrá ser utilizado como base para los diferentes casos de uso que se presenten. Figura 4.3 Formato de participantes del proyecto Centro Nacional de Investigación y Desarrollo Tecnológico Página 63

69 Formato de planeación de tareas Este formato (figura 3.12) tiene como propósito realizar una estimación acerca del tiempo requerido para cada etapa del proyecto, calcular el valor planeado de cada etapa y realizar estimaciones de fecha para cada etapa, y con esto proporcionar una herramienta de monitoreo de avances de acuerdo al calendario planeado. Propósito Este formato sirve para realizar una estimación acerca del tiempo requerido para cada etapa del proyecto Calcular el valor planeado de cada etapa Estimaciones de fecha para cada etapa y con esto proporcionar una herramienta de monitoreo del progreso de acuerdo al calendario planeado. Se recomienda combinar con un diagrama de Gantt Información Registrar todas las tareas que se consideren pertinentes general Registrar con una numeración y/o identificador que permita una mejor estructura de las tareas. Encabezado Se debe llenar lo siguiente Nombre Fecha actual Numero de proyecto Breve descripción del proyecto Tarea-Núm. Registrar el número que tendrá la tarea, este número debe ser consecutivo Tarea-Nombre Registrar el nombre de la tarea, el nombre debe ser claro y entendible para identificar a la tarea VP-Fecha Registrar la fecha en la cual se planea finalizar la tarea VP-Horas Registrar la mejor estimación posible para el tiempo que llevará realizar la tarea VP-Acumulado en Registrar la suma acumulada de las horas planeadas por cada tarea Hrs Vp-Valor planeado Para registrar este valor se deben sumar las horas planeadas considerando todas las tareas, y para cada tarea capturar el porcentaje respecto al total VP- Acumulado Registrar la suma acumulada del valor planeado por cada tarea del valor planeado VA- Fecha Registrar la fecha en la que la tarea fue completada VA- Valor ganado Registrar el valor ganado por completar la tarea VA- Valor Registrar la suma acumulada del valor ganado por cada tarea. acumulado ganado Centro Nacional de Investigación y Desarrollo Tecnológico Página 64

70 Figura 4.4 Formato de planeación de tareas Checklist de planeación Figura 4.5 Checklist de planeación Centro Nacional de Investigación y Desarrollo Tecnológico Página 65

71 Elementos utilizados en la etapa de desarrollo Para apoyar al desarrollador, la metodología presenta la siguiente guía. El propósito de esta guía es guiar en la fase de desarrollo de una especificación de requerimientos de software utilizando MEPERS. La guía muestra a nivel general las actividades que se deberán realizar, además de indicar las guías y formatos que serán utilizados en cada actividad; la guía cubre las etapas de elicitación, análisis y registro de requerimientos. Fase Propósito Guiar en la fase de desarrollo de una especificación de requerimientos de software utilizando MEPERS. Criterios de entrada Conocimiento del dominio del problema Formato de planeación de tareas y participantes del proyecto. Formato de resumen de plan de proyecto de requerimientos 1.0 con los estimados de tamaño y tiempo Bitácoras de tiempos y defectos Estándar de tipos de defectos Checklists 1 Elicitación de requerimientos Para facilitar la elicitación se utiliza la guía de elicitación de requerimientos Identificar las fuentes de información de requerimientos Selección de técnica o técnicas de elicitación de requerimientos, estas técnicas pueden ser seleccionadas de acuerdo al gusto del desarrollador Identificación de los requerimientos del cliente. Registro en las bitácoras de tiempos y defectos 2 Verificación de la elicitación de requerimientos 3 Análisis de requerimientos Seguir el checklist de elicitación de requerimientos y verificar la elicitación realizada. Arreglar los defectos encontrados. Registro en las bitácoras de tiempos y defectos Para facilitar el análisis de requerimientos se utiliza la guía de análisis de requerimientos Descripción y clasificación de los requerimientos. Modelado conceptual Detectar y resolver conflictos entre requerimientos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 66

72 4 Verificación del análisis de requerimientos 5 Registro de requerimientos Criterio de salida Seguir el checklist de análisis de requerimientos y verificar el análisis realizado. Arreglar los defectos encontrados. Registro en las bitácoras de tiempos y defectos Para facilitar el registro de requerimientos se utiliza la guía de registro de requerimientos Obtener un documento de especificación de requerimientos de software Una especificación de requerimientos de software basada en el estándar IEEE Checklists verificadas Bitácoras de tiempos y defectos completas Elementos utilizados en la etapa de elicitación A continuación se muestran los elementos que serán utilizados en la etapa de elicitación del proceso de especificación de requerimientos de software, cada formato presentado cuenta con su respectiva guía, estos son: Guía de elicitación Formato de Objetivos y metas Minuta de reuniones Checklist de elicitación A continuación se presentan estos elementos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 67

73 Guía de elicitación El propósito de esta guía es ayudar en la etapa de elicitación de requerimientos. En esta guía se inicia realizando un análisis de las posibles fuentes e requerimientos, posteriormente se selecciona una técnica de elicitación de requerimientos y por último las reuniones con los clientes con el fin de entender las necesidades y registrar sus requerimientos. Fase Propósito Guiar en la etapa de elicitación de requerimientos Criterios de entrada Conocimiento del dominio del problema Formato de planeación de tareas y participantes del proyecto. Formato de resumen de plan de proyecto de requerimientos 1.0 con los estimados de tamaño y tiempo Formato de participantes del proyecto Plantilla de SRS Bitácoras de tiempos y defectos Estándar de tipos de defectos(tabla 3.4) Checklists 1 Identificar las fuentes de información de requerimientos Para poder identificar las fuentes de requerimientos se debe cumplir con las siguientes tareas Identificar los objetivos y metas (Formato de objetivos y metas) Identificación de actores (en caso de no haber sido identificados previamente se debe actualizar el formato de participantes del proyecto) Análisis del ambiente operacional 2 Selección de técnica o técnicas de elicitación de requerimientos 3 Identificación de los requerimientos del cliente. 4 Actividades para el SRS Existen muchas técnicas que se pueden emplear para realizar la elicitación, se debe seleccionar la adecuada a partir de haber identificado las fuentes información de requerimientos Se recomienda una lectura a las técnicas sugeridas en SWEBOK Preparar las reuniones con las fuentes de información para realizar la elicitación Durante las reuniones seguir el formato de reuniones Identificar los requerimientos de software Se registran los usuarios participantes del proyecto en la plantilla del SRS, a partir del formato de Centro Nacional de Investigación y Desarrollo Tecnológico Página 68

74 participantes del proyecto revisado. A partir del formato de objetivos y metas se registra esta información en la plantilla del SRS. Al analizar la información de las reuniones aquellos requerimientos y conflictos que fueron identificados claramente se registran en la plantilla del SRS. Criterios de salida Se realizó una elicitación de requerimientos de software Bitácora de tiempos y defectos para la fase de elicitación de requerimientos Además Con estas actividades se tendrá como parte del SRS lo siguiente; 1. Participantes del proyecto (revisado) 2. Objetivos 3. Metas 4. Requerimientos (a nivel general) 5. Conflictos Centro Nacional de Investigación y Desarrollo Tecnológico Página 69

75 Formato de objetivos y metas Este formato tiene como propósito registrar los objetivos y metas que se identifiquen durante la elicitación, toda la información formará parte del SRS Propósito Este formato sirve para registrar los objetivos y metas que tendrá el proyecto La información obtenida servirá para definir los objetivos y metas que deberá tener el SRS Además la sección de participantes del proyecto forma parte del SRS Información Registrar todos los objetivos y metas que sean posible general Encabezado Se debe llenar lo siguiente Nombre Fecha actual Número de proyecto Breve descripción del proyecto Nombre Registrar el nombre de la meta u objetivo Tipo Registrar si es una meta u objetivo Medida-Planeada Registrar con algún valor de medida el resultado planeado a alcanzar Medida-Actual Registrar el valor actual que se cubrió al realizar la meta u objetivo Descripción Registrar una breve descripción de la meta u objetivo Importante Es importante registrar las metas y objetivos a alcanzar con el desarrollo del proyecto, estos servirán como base para enfocar los requerimientos a cubrir las metas y objetivos descritos en este formato. Figura 4.6 Formato de objetivos y metas Centro Nacional de Investigación y Desarrollo Tecnológico Página 70

76 Minuta de reuniones Propósito Este formato sirve para registrar los acuerdos y resultados de las reuniones que se tienen con los involucrados en el proyecto. La información obtenida servirá para llegar acuerdos con los interesados acerca del proceso de elicitación, resolución de conflictos con requerimientos y cualquier actividad que sea necesaria para elaborar el SRS. Información general Registrar toda la información que sea posible antes de la reunión Antes de iniciar la reunión se deben asignar las actividades que cada persona realizará en la reunión Encabezado Se debe llenar lo siguiente Nombre Fecha actual Presidente de la reunión Ubicación de la reunión Propósito de la Registrar cual es el propósito por el que la reunión será realizada reunión Asistentes Registrar el nombre de cada uno de los asistentes a la reunión Puesto en la reunión Para un mejor análisis del proceso se recomienda asignar puestos a los participantes de la reunión siendo los más importantes el presidente, secretario y tomador de tiempos. Agenda Registrar las actividades que se desean realizar en la reunión, así como el tiempo planeado Una vez completada la actividad se debe capturar el tiempo actual de la actividad Decisiones Registrar las decisiones, acuerdos y compromisos que se tomaron en la reunión además de registrar la fecha cuando deben cumplirse. Importante No es necesario el uso de esta forma para realizar las reuniones, sin embargo si son de gran ayuda para tener una idea clara de las actividades a cumplir en la reunión, decisiones que se tomaron, acuerdos y compromisos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 71

77 Figura 4.7 Minuta de reuniones Centro Nacional de Investigación y Desarrollo Tecnológico Página 72

78 Checklist de elicitación Figura 4.8 Checklist de elicitación Centro Nacional de Investigación y Desarrollo Tecnológico Página 73

79 Elementos utilizados en la etapa de análisis A continuación se muestran los elementos que serán utilizados en la etapa de análisis del proceso de especificación de requerimientos de software, cada formato presentado cuenta con su respectiva guía, estos son: Guía de análisis Formato de análisis de requerimientos Checklist de análisis A continuación se presentan estos elementos. Guía de análisis El propósito de esta guía es colaborar en la etapa de análisis de requerimientos. Esta guía cubre desde la clasificación de requerimientos por su tipo, prioridad y restricciones, además del modelado de estos requerimientos y por último el resolver conflictos encontrados. Fase Propósito Guiar en la fase de análisis de requerimientos de software Criterios de Conocimiento del dominio del problema entrada Formato de registro de requerimientos Formato de resumen de plan de proyecto de requerimientos 1.0 con los estimados de tamaño y tiempo Plantilla del SRS Bitácoras de tiempos y defectos Estándar de tipos de defectos Checklists Centro Nacional de Investigación y Desarrollo Tecnológico Página 74

80 1 Descripción y clasificación de los requerimientos 2 Modelado conceptual 3 Detectar y resolver conflictos entre requerimientos 4 Actividades para el SRS Criterios de salida Para facilitar el análisis, los requerimientos deben ser clasificados siguiendo el formato de registro de requerimientos se clasifican de acuerdo a lo siguiente Requerimientos funcionales y no funcionales. Requerimientos impuestos por los actores. Requerimientos que deben cumplir algún estándar Priorizar los requerimientos. Realizar un modelado para representar el problema. Incluyendo entidades, relaciones y dependencias El desarrollador puede escoger cualquier técnica de modelado sin embargo se recomienda utilizar aquellos estandarizados. Utilizando el formato de registro de requerimientos y el modelo representado, se detectan aquellos requerimientos que causan conflictos debido a la falta de compatibilidad, contradictorios, o no se pudieron clasificar adecuadamente. Se programa una reunión con los actores involucrados para llegar a una decisión. Durante las reuniones para resolver conflictos seguir el formato de reuniones Actualizar el formato de registro de requerimientos. Se registran los requerimientos en la plantilla del SRS tomando la información del formato de registro de requerimientos Se realizó un análisis de los requerimientos de software obtenidos durante la etapa de elicitación. Bitácora de tiempos y defectos para la etapa de análisis de requerimientos Además Con estas actividades, se tendrá como parte del SRS los requerimientos específicos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 75

81 Formato de análisis de requerimientos Propósito Este formato sirve para registrar los requerimientos que fueron identificados durante la elicitación La información obtenida servirá para establecer los requerimientos específicos que deberá cumplir el sistema. Esta información formará parte del SRS Información general Registrar todos los requerimientos que se consideren pertinentes Encabezado Se debe llenar lo siguiente Nombre Fecha actual Numero de proyecto Breve descripción del proyecto Numero o ID Registrar el número o id que permita identificar el requerimiento Nombre Registrar un nombre para el requerimientos Tipo Registrar si es un requerimiento o una restricción Fuente Registrar la fuente de donde procede el requerimiento Prioridad Registrar la prioridad definiendo si es Alta, Media o Baja Breve descripción Escribir una breve descripción del requerimiento o restricción Importante Se deben registrar todos los requerimientos principalmente aquellos que se consideren críticos para el desarrollo del sistema Figura 4.9 Formato de análisis de requerimientos Centro Nacional de Investigación y Desarrollo Tecnológico Página 76

82 Checklist de análisis Figura 4.10 Checklist de análisis Centro Nacional de Investigación y Desarrollo Tecnológico Página 77

83 Elementos utilizados en la etapa de registro A continuación se muestran los elementos que serán utilizados en la etapa de registro del proceso de especificación de requerimientos de software, cada formato presentado cuenta con su respectiva guía, estos son: Guía de registro Plantilla del documento SRS A continuación se presentan estos elementos. Guía de registro Lo importante de esta guía es el uso de la plantilla de SRS, en esta plantilla se encuentra la información que deberá presentar el SRS, esta plantilla puede ser utilizada incluso si no se aplica la metodología presentada. Fase Propósito Guiar en la etapa de registro de requerimientos Criterios entrada de 1 Obtener un documento de especificación de requerimientos Criterio de salida Plantilla del documento SRS Conocimiento del dominio del problema Plantilla del SRS Formato de resumen de plan de proyecto de requerimientos 1.0 con los estimados de tamaño y tiempo Bitácoras de tiempos y defectos Estándar de tipos de defectos Checklists La información obtenida en el proceso procede a ser documentada con un detalle muy apropiado y de acuerdo al público al que va dirigido. Se finalizará la plantilla del SRS; esta plantilla se basa en el estándar IEEE Una especificación de requerimientos de software basada en el estándar IEEE Bitácoras de tiempos y defectos completas para la etapa de registro de requerimientos. Esta plantilla puede ser utilizada para realizar un SRS cumpliendo con el estándar IEEE830, la plantilla puede ser vista en el anexo 2. Centro Nacional de Investigación y Desarrollo Tecnológico Página 78

84 Elementos utilizados en la etapa de Postmortem A continuación se muestran los elementos que serán utilizados en la etapa de postmortem del proceso de especificación de requerimientos de software, cada formato presentado cuenta con su respectiva guía, estos son: Guía de postmortem Formato de propuesta de mejora A continuación se presentan estos elementos. Guía de postmortem El propósito de esta guía es ayudar en la etapa de Postmortem de la metodología de especificación de requerimientos presentada. Mediante esta guía, el desarrollador puede registrar la información del proceso realizado, registrar defectos encontrados, tiempo invertido, tamaño total del producto y con esto recibir una retroalimentación acerca del proceso realizado. Fase Propósito Guiar en la etapa de PostMortem de una especificación de requerimientos de software utilizando MEPERS. Criterios de entrada Descripción general del problema Formato de resumen de plan de proyecto de requerimientos 1.0 Bitácoras de tiempos y defectos completas Plantilla completa del SRS Una especificación de requerimientos basada en el 1 Defectos introducidos estándar IEEE 830 Utilizando la información de la bitácora de defectos, introducir la información en el formato de resumen del plan de proyecto. En el campo de defectos introducidos actuales 2 Defectos removidos Utilizando la información de la bitácora de defectos, introducir la información en el formato de resumen del plan de proyecto. En el campo de defectos removidos actuales 3 Tamaño Determinar el tamaño total que presentó la Centro Nacional de Investigación y Desarrollo Tecnológico Página 79

85 especificación de requerimientos de software y registrarla en el campo del tamaño actual 4 Tiempo Utilizando la información de la bitácora de tiempos, introducir la información en el formato de resumen del plan de proyecto. En los campos de tiempo actual Criterios de salida Especificación de requerimientos de software utilizando la metodología MEPERS Formato de resumen del plan del proyecto de requerimientos completo Formato PIP completo describiendo las lecciones aprendidas y sugerencias de mejora. Bitácoras de tiempo y defectos completas. Formato de propuesta de mejora Propósito Este formato sirve para registrar los problemas que se presentaron en el proceso y plantear ideas para mejorarlos. La información obtenida servirá para realizar una retroalimentación acerca del proceso del desarrollador. Información general Registrar todas las ideas que permitan mejorar el proceso del desarrollador Registrar los problemas que se presentaron en el proceso aun sin tener una idea de solución Cualquier comentario, aun si no es mejora o problema debe ser registrado entre mayor información del proceso se tenga es mejor. Encabezado Se debe llenar lo siguiente Nombre Fecha actual Número de ejercicio Breve descripción del ejercicio Problema Registrar de manera clara; Problema encontrado Su impacto en el proceso y producto Enumerar cada problema para una mejor organización Propuesta Registrar de manera clara; Describir propuestas de mejora del proceso Proponer una propuesta de mejora para cada problema encontrado Asignar prioridades a las propuestas Enumerar cada propuesta para una mejor organización Notas y comentarios Registrar notas y comentarios que se consideren pertinentes del proceso Importante Cada proyecto debe de contar con su propuesta de mejora, esto es importante para logar una buena retroalimentación del proceso Centro Nacional de Investigación y Desarrollo Tecnológico Página 80

86 Figura 4.11 Formato PIP Centro Nacional de Investigación y Desarrollo Tecnológico Página 81

87 3.4 Conclusiones del capitulo En esta capitulo se presentaron las bases, el proceso a seguir y los elementos que participan en la metodología presentada. FODA estableció las bases, definiendo las características indispensables que, como metodología de evaluación personal en la especificación de requerimientos de software debería tener. El dividirlo en etapas y actividades permite un mejor monitoreo del proceso y establecer objetivos para cada actividad, estas etapas son apoyadas con los distintos elementos que utiliza la metodología. En el siguiente capítulo se presentan los casos de prueba con los cuales fue probada la metodología presentada en esta tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 82

88 Capítulo 4 Pruebas En este capítulo se presentan los casos de prueba y los resultados obtenidos de aplicar la metodología resultante del trabajo de tesis. Las pruebas se hicieron evaluando la utilidad de los elementos que integran a la metodología, el proceso que se lleva a cabo durante la metodología y los resultados del conocimiento personal obtenidos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 83

89 4.1 Propósito de las pruebas El propósito de las pruebas fue probar que la metodología pudiera ser utilizada para realizar una especificación de requerimientos de software y que el conocimiento del proceso personal en la especificación de requerimientos de software adquirido, pudiera ser analizado para mejorar el proceso. El documento SRS obtenido no es evaluado. 4.2 Ámbito de las pruebas Para realizar las pruebas necesarias se usaron 2 ejercicios, el primero es un ejercicio común en la enseñanza del trabajo necesario para realizar una especificación de requerimientos de software y el segundo es de un proyecto realizado por el CENIDET para un expediente clínico electrónico 4.3 Herramientas para las Pruebas Para facilitar el uso de la metodología fue utilizado el siguiente software. Tabla 4.1 Herramientas de soporte para pruebas Nombre Microsoft Word Microsoft Excel Manic Time Microsoft Visio Descripción Fue utilizado para leer los formatos y guías que se utilizan en la metodología, además de poder hacer correcciones al momento. Fue utilizado para registrar la información de los formatos y bitácoras. Facilitando mediante sus opciones de cálculo el análisis de información. Herramienta de software utilizada para medir el tiempo empleado en distintas actividades del cuatrimestre, también fue utilizado para medir el tiempo empleado en las etapas de la metodología. Utilizado como herramienta de soporte para el diseño de los casos de uso en el documento de SRS Centro Nacional de Investigación y Desarrollo Tecnológico Página 84

90 4.4 Procedimiento de realización de las pruebas Para cada una de las pruebas se siguieron los siguientes pasos a) Lectura y análisis de la información del problema a resolver. b) Utilizar la metodología para la evaluación personal en la especificación de requerimientos de software cumpliendo con todos los puntos del proceso y utilizando los distintos elementos que permiten conocer el proceso personal del desarrollador c) Realizar un análisis de la información obtenida durante el proceso y con esto, se realizan las conclusiones del proceso del desarrollador en la especificación de requerimientos de software. Es importante denotar que las pruebas fueron realizadas con la información del proceso de una sola persona, por lo que es necesario como trabajo futuro realizar estas pruebas con una mayor cantidad de personas para asegurar el éxito alcanzado en las pruebas. 4.5 Criterios de éxito y de fracaso Los criterios de éxito son: Que con la metodología presentada, el desarrollador pueda conocer su proceso durante la especificación de requerimientos de software detectando su área de mejora, la información obtenida sea entendible y permita detectar las áreas de mejora del proceso personal realizado. Los criterios de fracaso son: Que con la metodología presentada, los resultados obtenidos no sean útiles para conocer el proceso personal, los elementos que integran la metodología, como los formatos y guías, causen confusión o sean ambiguos y no sea útil para realizar una especificación de requerimientos de software. A continuación se presentan los casos de prueba, estos criterios presentados se validan al realizar el análisis de información del proceso de cada caso, si es obtenido conocimiento del proceso personal que permita mejorar el trabajo realizado durante la especificación de requerimientos de software, entonces se cumple con el criterio de éxito. Centro Nacional de Investigación y Desarrollo Tecnológico Página 85

91 4.6 Casos de Prueba Caso de prueba 1 Tabla 4.2 Caso de prueba 1 Proyecto: Administración de videoclub ID Caso de prueba: Caso1 Tipo de Pruebas: Pruebas de elementos de la metodología y pruebas de resultados de aplicar la metodología. Resumen: Se realizó un análisis de requerimientos para un videoclub que desea registrar información acerca de sus operaciones. Procedimiento: Las tareas a realizar serán las siguientes Paso 1 Se realiza la lectura del ejercicio a resolver, esta lectura del ejercicio es un ejercicio común de la ingeniería de requerimientos Paso 2 Se aplica la metodología MEPERS a través de sus etapas Paso 3 Se realiza un análisis de la información obtenida durante el proceso y se realizan las conclusiones Procedimiento Lectura del ejercicio a resolver Una tienda de alquiler de películas posee alrededor de 5000 vídeo casetes y DVD s (películas), de los cuales se requiere llevar registro. Cada uno de los vídeos tiene un número de cinta. Para cada película se necesita conocer título, duración, director y la categoría según la siguiente clasificación: drama, acción, suspenso, comedia, guerra y ciencia-ficción. Existen muchas copias de la mayoría de las películas. Se le asignó a cada película un identificador específico, y así se puede saber en qué lugar se encuentra esta película. Un vídeo puede ser tanto formato DVD o VHS. Siempre se tiene por lo menos un vídeo de cada película que se registra, y cada película es siempre copiada a un vídeo individual y específico. Algunos de los vídeos son muy largos, así que se tienen películas que ocupan múltiples vídeos. Nuestros clientes al momento de solicitar en alquiler un video, frecuentemente nos pregunta por los protagonistas de la película que quiere alquilar. Así, que se debe llevar el registro de los actores que aparecen en cada película. No todas las películas tienen actores. A los clientes les gustaría conocer el nombre real del actor, edad y estado civil. Solamente se llevan registros de actores que aparecen en las películas de la tienda. Centro Nacional de Investigación y Desarrollo Tecnológico Página 86

92 La tienda de video tiene muchos clientes y solamente alquila vídeos a personas que sean socias del vídeo club. Para que una persona pueda pertenecer al video club como socio debe afiliarse, para lo cual se le asigna un número que lo identifica y se deben registrar sus nombres y apellidos, número telefónico, dirección de residencia. Se necesita llevar el registro de qué vídeo ha alquilado cada socio en un momento determinado. Un cliente puede alquilar varios vídeos simultáneamente. Necesitamos registrar el histórico de todos los alquileres realizados. Cada vez que un cliente alquila un video, se debe registrar la fecha de alquiler, el día que regresará el video. Todos los videos deben ser regresados a la tienda a más tardar tres días después de su alquiler. En caso de no entregarse a tiempo, se cobrará una multa de $20.00 por película y día de demora. El histórico de alquiler de videos se requiere con el fin de analizar el comportamiento del alquiler de videos. Con el histórico seremos capaces de determinar cuántas cintas alquila cada cliente y cuantas veces un cliente ha regresado una cinta tarde. También necesitamos saber cuántas veces una cinta ha sido usada, y saber cuándo retirar dicha cinta. También podremos analizar las preferencias de nuestros clientes, conocer el valor en pesos recibido por el concepto de alquiler de videos y multas por demora Aplicar la metodología MEPERS Para realizar esta tarea se siguieron las guías que presenta la metodología, pasando por las actividades de planeación, desarrollo y postmortem, utilizando los distintos elementos según fuera necesario. A continuación se presentan los formatos con la información del proceso capturada. Figura 4.1 Resumen de proyecto Caso 1 Centro Nacional de Investigación y Desarrollo Tecnológico Página 87

93 Figura 4.2Bitácora de tiempos Caso 1 Figura 4.3Bitácora de defectos Caso 1 Figura 4.4 Participantes del proyecto Caso 1 Figura 4.5 Estimación de tareas Caso 1 Centro Nacional de Investigación y Desarrollo Tecnológico Página 88

94 Figura 4.6 Objetivos Caso 1 Figura 4.7 Reunión Caso 1 Centro Nacional de Investigación y Desarrollo Tecnológico Página 89

95 Figura 4.8 Requerimientos Caso 1 Figura 4.9 Formato PIP Caso 1 Centro Nacional de Investigación y Desarrollo Tecnológico Página 90

96 Análisis de la información En este ejercicio se pudo comprobar que la metodología MEPERS puede ser utilizada sin problemas para un pequeño sistema, de la información del proceso, en la figura 4.1, se observa que las estimaciones fueron incorrectas. Esto es entendible sobre todo por no tener un antecedente personal del tiempo requerido para realizar una especificación de requerimientos. Los principales requerimientos fueron identificados y se corrigieron ciertos defectos encontrados, sobretodo en la etapa de verificación de análisis de requerimientos. Sin embargo a nivel personal la mayor cantidad de errores cometidos fue de documentación y se localizaron hasta la etapa de registro de información. El formato de propuesta de mejorar (PIP) fue donde se registró esta información para lograr una mejora en los problemas encontrados en este proceso. Centro Nacional de Investigación y Desarrollo Tecnológico Página 91

97 4.6.2 Caso de prueba 2 Tabla 4.3 Caso de prueba 2 Proyecto: Sistema de expedientes clínicos electrónicos. ID Caso de prueba: Caso 2 Tipos de Pruebas: Pruebas de elementos de la metodología y pruebas de resultados de aplicar la metodología. Resumen: Se realizó una especificación de requerimientos para una clínica que desea administrar sus expedientes clínicos de manera electrónica. Para realizar la especificación se tomó en cuenta la norma NOM 168-SSA Procedimiento: Las tareas a realizar serán las siguientes Paso 1 Se leerá la información obtenida del cliente en un documento de power point. Paso 2 Se aplica la metodología MEPERS a través de sus etapas Paso 3 Se realiza un análisis de la información obtenida durante el proceso y se realizan las conclusiones Procedimiento Lectura de la información proporcionada por el cliente Expediente clínico electrónico (ECE) Conjunto de registros electrónicos que identifican las acciones realizadas a un paciente por parte del personal de salud. Los registros electrónicos están organizados como notas de atención, gráficas, imágenes, entre otros, así como registros administrativos tales como recetas e incapacidades y están integrados en un repositorio central con el propósito de contar con un ECE por paciente. Se integrarán los antecedentes de atención que haya recibido el derechohabiente por los servicios prestados de consulta externa, urgencias, hospitalización, tratamiento. Secciones de un ECE Agenda Expediente Resúmenes médicos Centro Nacional de Investigación y Desarrollo Tecnológico Página 92

98 Notas médicas Recetas Reportes Se debe trabajar con la Norma Oficial Mexicana del expediente clínico (NOM 168-SSA1-1998) Aplicar la metodología MEPERS Para realizar esta tarea se siguieron las guías que presenta la metodología, pasando por las actividades de planeación, desarrollo y postmortem, utilizando los distintos elementos según fuera necesario. A continuación se presentan los formatos con la información del proceso capturada. Figura 4.10 Resumen de proyecto Caso 2 Centro Nacional de Investigación y Desarrollo Tecnológico Página 93

99 Figura 4.11Bitacora de tiempos Caso 2 Figura 4.12 Bitácora de defectos Caso 2 Figura 4.13Participantes del proyecto Caso 2 Centro Nacional de Investigación y Desarrollo Tecnológico Página 94

100 Figura 4.14Estimación de tareas Caso 2 Figura 4.15 Objetivos Caso 2 Centro Nacional de Investigación y Desarrollo Tecnológico Página 95

101 Figura 4.16 Requerimientos Caso 2 Centro Nacional de Investigación y Desarrollo Tecnológico Página 96