TESIS DE MAESTRÍA EN CIENCIAS - CENIDET · 2014-02-13 · Departamento de Ciencias Computacionales...
Transcript of TESIS DE MAESTRÍA EN CIENCIAS - CENIDET · 2014-02-13 · Departamento de Ciencias Computacionales...
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
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.
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 1
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 830-1998.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 2
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 830-1998
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 3
Tabla de contenido
RESUMEN ............................................................................................................................ 1
ABSTRACT .......................................................................................................................... 2
INTRODUCCIÓN ................................................................................................................ 8
CAPÍTULO 1 INFORMACIÓN GENERAL ................................................................ 11
1.1 Antecedentes .................................................................................................................................. 12
1.2 Trabajos relacionados.................................................................................................................... 13 1.2.1 “Una Metodología para elicitación de requisitos en proyectos GSD” [AVCPS2007] .................... 13 1.2.2 “Metodología para la elicitación de requisitos de sistemas de software” [DUBE2002] ................. 14 1.2.3 “Metodología DoRCU para la ingeniería de requerimientos” [BABA2001] ................................. 15
1.3 Planteamiento del problema .......................................................................................................... 17
1.4 Objetivo de la tesis ......................................................................................................................... 17
1.5 Justificación y beneficios ............................................................................................................... 18 1.5.1 Justificación ................................................................................................................................ 18 1.5.2 Beneficios ................................................................................................................................... 19
1.6 Alcance y límites del proyecto ....................................................................................................... 20 1.6.1 Alcances ...................................................................................................................................... 20 1.6.2 Limites ........................................................................................................................................ 20
1.7 Conclusiones del capitulo .............................................................................................................. 20
CAPÍTULO 2 MARCO CONCEPTUAL ...................................................................... 21
2.1 Ingeniería de software ................................................................................................................... 22 2.1.1 Requerimientos de software ......................................................................................................... 23 2.1.2 Etapas del proceso para la metodología de especificación de requerimientos de software ............. 25
2.2 Descripción del análisis de dominio orientado a las características FODA ................................. 26
2.3 Metodología .................................................................................................................................... 27
2.4 Proceso de software ....................................................................................................................... 27
2.5 Proceso Personal ............................................................................................................................ 28
2.6 Conclusiones del capitulo .............................................................................................................. 29
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 4
CAPÍTULO 3 DESARROLLO ...................................................................................... 30
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 ............................................. 31 3.1.1 Introducción ................................................................................................................................ 31 3.1.2 Análisis de contexto (FODA)....................................................................................................... 32 3.1.3 Modelado del dominio (FODA) ................................................................................................... 36
3.2 Etapas de la metodología para la evaluación personal en la especificación de requerimientos de
software ....................................................................................................................................................... 38 3.2.1 Datos de entrada .......................................................................................................................... 39 3.2.2 Planeación ................................................................................................................................... 40 3.2.3 Desarrollo .................................................................................................................................... 41
3.2.3.1 Elicitación ........................................................................................................................... 41 3.2.3.2 Análisis ............................................................................................................................... 43 3.2.3.3 Registro .............................................................................................................................. 46
3.2.4 Postmortem ................................................................................................................................. 47
3.3 Elementos que integran la metodología para la evaluación personal en la especificación de
requerimientos de software ........................................................................................................................ 48 3.3.1 Formatos, guías, bitácoras y estándares de la metodología ........................................................... 48 3.3.2 Métricas ...................................................................................................................................... 52 3.3.3 Estándar de defectos propuesto .................................................................................................... 55 3.3.4 Elementos de la metodología usados a través del proceso ............................................................ 56
3.3.4.1 Elementos utilizados en la etapa de planeación ................................................................... 60 3.3.4.2 Elementos utilizados en la etapa de desarrollo ..................................................................... 66 3.3.4.3 Elementos utilizados en la etapa de Postmortem .................................................................. 79
3.4 Conclusiones del capitulo .............................................................................................................. 82
CAPÍTULO 4 PRUEBAS ................................................................................................ 83
4.1 Propósito de las pruebas ................................................................................................................ 84
4.2 Ámbito de las pruebas ................................................................................................................... 84
4.3 Herramientas para las Pruebas ..................................................................................................... 84
4.4 Procedimiento de realización de las pruebas ................................................................................ 85
4.5 Criterios de éxito y de fracaso ....................................................................................................... 85
4.6 Casos de Prueba ............................................................................................................................. 86 4.6.1 Caso de prueba 1 ......................................................................................................................... 86
4.6.1.1 Lectura del ejercicio a resolver ............................................................................................ 86 4.6.1.2 Aplicar la metodología MEPERS ........................................................................................ 87 4.6.1.3 Análisis de la información ................................................................................................... 91
4.6.2 Caso de prueba 2 ......................................................................................................................... 92 4.6.2.1 Lectura de la información proporcionada por el cliente ....................................................... 92
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 5
4.6.2.2 Aplicar la metodología MEPERS ........................................................................................ 93 4.6.2.3 Análisis de la información ................................................................................................... 97
4.7 Riesgos ............................................................................................................................................ 98
4.8 Conclusiones del capitulo .............................................................................................................. 98
CAPÍTULO 5 CONCLUSIONES .................................................................................. 99
5.1 Conclusiones generales ................................................................................................................ 100
5.2 Objetivos cumplidos .................................................................................................................... 101
5.3 Trabajo a futuro .......................................................................................................................... 101
REFERENCIAS................................................................................................................ 102
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 6
Índice de figuras
Figura 1.1 Metodología RE-GSD ............................................................................................................... 14 Figura 1.2 Metodología para la elicitación de requerimientos [DUBE2002] ............................................ 15 Figura 1.3 Metodología DoRCU [BABA2001] ........................................................................................... 16 Figura 1.4 Resultados de Proyectos "The Chaos Report" ........................................................................ 18 Figura 1.5 Problemas en requerimientos "The Chaos Report" ............................................................... 18 Figura 2.1 Etapas de la especificación de requerimientos de software ..................................................... 25 Figura 2.2 Etapas del análisis FODA [KCHNP1990] ................................................................................ 26 Figura 3.1 Actividades realizadas FODA .................................................................................................. 31 Figura 3.2 Diagrama de estructura ............................................................................................................ 32 Figura 3.3 Diagrama de contexto ............................................................................................................... 33 Figura 3.4 Análisis de información ............................................................................................................ 36 Figura 3.5 Diagrama de característica ....................................................................................................... 37 Figura 3.6 Etapas de la metodología .......................................................................................................... 39 Figura 3.7 Etapas de la metodología .......................................................................................................... 48 Figura 3.8 Etapas y sus formatos ............................................................................................................... 49 Figura 3.9 Bitácora de tiempo .................................................................................................................... 58 Figura 3.10 Bitácora de defectos ................................................................................................................ 59 Figura 3.11 Formato de participantes del proyecto .................................................................................. 63 Figura 3.12 Formato de planeación de tareas ........................................................................................... 65 Figura 3.13 Checklist de planeación .......................................................................................................... 65 Figura 3.14 Formato de objetivos y metas ................................................................................................. 70 Figura 3.15 Minuta de reuniones ............................................................................................................... 72 Figura 3.16 Checklist de elicitación ........................................................................................................... 73 Figura 3.17 Formato de análisis de requerimientos .................................................................................. 76 Figura 3.18 Checklist de análisis ................................................................................................................ 77 Figura 3.19 Formato PIP ............................................................................................................................ 81 Figura 4.1 Resumen de proyecto Caso 1 .................................................................................................... 87 Figura 4.2Bitácora de tiempos Caso 1 ....................................................................................................... 88 Figura 4.3Bitácora de defectos Caso 1 ....................................................................................................... 88 Figura 4.4 Participantes del proyecto Caso 1 ............................................................................................ 88 Figura 4.5 Estimación de tareas Caso 1 ..................................................................................................... 88 Figura 4.6 Objetivos Caso 1 ....................................................................................................................... 89 Figura 4.7 Reunión Caso 1 ......................................................................................................................... 89 Figura 4.8 Requerimientos Caso 1 ............................................................................................................. 90 Figura 4.9 Formato PIP Caso 1.................................................................................................................. 90 Figura 4.10 Resumen de proyecto Caso 2 .................................................................................................. 93 Figura 4.11Bitacora de tiempos Caso 2 ..................................................................................................... 94 Figura 4.12 Bitácora de defectos Caso 2 .................................................................................................... 94 Figura 4.13Participantes del proyecto Caso 2 ........................................................................................... 94 Figura 4.14Estimación de tareas Caso 2 .................................................................................................... 95 Figura 4.15 Objetivos Caso 2 ..................................................................................................................... 95 Figura 4.16 Requerimientos Caso 2 ........................................................................................................... 96 Figura 4.17Formato PIP Caso 2 ................................................................................................................. 97
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 7
Índice de tablas
Tabla 1.1 Tabla comparativa con los trabajos relacionados ..................................................................... 16 Tabla 2.1 Características de un requerimiento ......................................................................................... 24 Tabla 3.1 Tabla comparativa de metodologías .......................................................................................... 35 Tabla 3.2 Métricas adaptadas de PSP........................................................................................................ 52 Tabla 3.3 Métricas propuestas por la metodología ................................................................................... 53 Tabla 3.4 Estándar de defectos .................................................................................................................. 55 Tabla 4.1 Herramientas de soporte para pruebas ..................................................................................... 84 Tabla 4.2 Caso de prueba 1 ........................................................................................................................ 86 Tabla 4.3 Caso de prueba 2 ........................................................................................................................ 92 Tabla 4.4 Riesgos encontrados ................................................................................................................... 98
Abreviaturas
CENIDET Centro Nacional de Investigación y Desarrollo Tecnológico
FODA Análisis de dominio orientado a las características (Feature
Oriented Domain Analysis)
MEPERS Metodología para la evaluación personal en la especificación
de requerimientos de software
PSP Proceso personal de software (Personal Software Process)
SRS Especificación de requerimientos de software (Software
Requirements Specification)
TSP Proceso de software en equipo (Team Software Process)
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 8
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].
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 9
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 10
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 11
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 12
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 2008.
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 2001.
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 13
“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.
1.2.1 “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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 14
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
1.2.2 “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 830-1998, 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 15
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]
1.2.3 “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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 16
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 Metodología de
especificación de
requerimientos
Se forma un SRS
bajo un formato
estándar
Se evalúa la
calidad del
proceso y
producto de
manera
personal
“Una Metodología para
elicitación de requisitos en
proyectos GSD”
[AVCPS2007]
Enfocada a
desarrollo de
software global
No (El usuario de esta
metodología decide el
formato a utilizar, pero
no se contempla en la
metodología)
No
“Metodología para la
elicitación de requisitos de
sistemas de software”
[DUBE2002]
Guía en el proceso de
especificación de
requerimientos
Si (IEEE 830-1998) No
“Metodología DoRCU
para la ingeniería de
requerimientos”
[BABA2001]
Toma métodos,
técnicas y
herramientas de
distintos autores para
las etapas del
proceso
No (Se menciona que
el entregable es un
documento de
requerimientos pero no
define ningún formato)
No
Metodología para la
evaluación personal en la
especificación de
requerimientos de
software(TESIS)
Se utilizaran
formatos, guías y
métodos de
evaluación para cada
etapa del proceso
Si(IEEE 830-1998) Si
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 17
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 18
1.5 Justificación y beneficios
1.5.1 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]
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.
Figura 1.5 Problemas en requerimientos "The Chaos Report"
Completados exitosamente
32%
Completados con problemas
44%
Fallos 24%
Resultados de proyectos en 2009 de acuerdo al
estudio "The Chaos Report"
Requerimientos incompletos
30%
Falta de involucramiento
del usuario 28%
Expectativas no realistas
23%
Requerimientos cambiantes
19%
Problemas en requerimientos 43.5% de acuerdo
al estudio "The Chaos Report"
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 19
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
1.5.2 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 IEEE830-1998 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 830-1998)
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 20
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
1.6.1 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
830-1998).
1.6.2 Limites
El documento SRS a realizar esta pensado únicamente en el
estándar de la IEEE 830-1998
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 21
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 22
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]
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 23
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]
2.1.1 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 24
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]
Tabla 2.1 Características de un requerimiento
Característica Descripción
Unitario El requerimiento atiende una sola cosa
Completo El requerimiento tiene toda la información
necesaria
Consistente El requerimiento no es contradictorio con
otro requerimiento.
Seguimiento El requerimiento pertenece a todo o una
parte del negocio
Actual El requerimiento no se ha vuelto obsoleto
por el paso de tiempo
Factible 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 25
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.
Figura 2.1 Etapas de la especificación de requerimientos de software
´
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 26
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.
Figura 2.2 Etapas del análisis FODA [KCHNP1990]
Análisis de Dominio
Análisis de contexto
Diagrama de estructura
Diagrama de contexto
Modelado del dominio
Análisis de información
Modelado de características
Modelado arquitectónico
Modelo de interacción del
proceso
Grafico de la estructura del
modelo
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 27
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]
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 28
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”).
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 29
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 30
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 31
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
3.1.1 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.
Figura 3.1 Actividades realizadas FODA
Análisis de Dominio
Análisis de contexto
Diagrama de estructura
Diagrama de contexto
Análisis comparativo
Modelado del dominio
Análisis de información
Modelado de características
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 32
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.
PSP TSP RUP
Metodología para la
evaluación personal en la
especificación de
requerimientos de
software
Procesos de desarrollo de software
Metodologías para la especificación de requerimientos
Metodología para
la elicitación de
requisitos de
sistemas de
software
Una Metodología
para elicitación de
requisitos en
proyectos GSD
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 33
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.
Metodología para la evaluación personal en la
especificación de requerimientos de
software
Requerimientos del usuario
Manejo de métricas para la evaluación
personal
Conocimiento del proceso personal en la especificación de
requerimientos
Datos de entrada
Almacena
Procesa información
Retroalimentación del proceso personal
Se genera
Se obtiene
Especificación de requerimientos de
software (SRS IEEE-830)
Registro de tiempos de desarrollo y
defectos presentados
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 830-1998, 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 34
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 IEEE830-1998.
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 35
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 830-1998 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 36
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 37
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 38
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 39
Figura 3.6 Etapas de la metodología
3.2.1 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 40
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 41
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.
3.2.3.1 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 42
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 43
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.
3.2.3.2 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 44
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 45
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 46
3.2.3.3 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 830-1998 [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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 47
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.
3.2.4 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 48
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.
3.3.1 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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 49
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 50
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]
A continuación una descripción general de estos elementos.
Guías
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 51
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 IEEE830-1998,
además de proponer un estándar de defectos el cual se presenta en la sección 3.3.3.1.4.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 52
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
El tiempo total planeado en desarrollar
una especificación de requerimientos de
software
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
Tiempo actual
de desarrollo
El tiempo total actual en desarrollar una
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
Tiempo
planeado por
etapa
El tiempo planeado por cada etapa El realizar estas estimaciones se pueden
tener una mejor administración del
tiempo según la etapa.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 53
Tiempo actual
por etapa
El tiempo que tomo 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
Defectos
insertados por
etapa
Los defectos insertados en cada etapa El registrar esta información permite
identificar en qué etapa del proceso se
introducen mayor cantidad de defectos.
Defectos
removidos por
etapa
Los defectos removidos en cada etapa 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
encontrados en el proceso.
N de técnicas de
elicitación utilizadas
Número y nombre de las técnicas
utilizadas de elicitación
Identificar cuáles son las técnicas
más utilizadas y que mayor número
de requerimientos son encontrados.
N de personas
elicitadas
Número de personas con las que se
trabajó la elicitación de requerimientos
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.
N veces que se
revisaron los
requerimientos con
la misma persona
Número de veces que se volvió a realizar
una sesión de elicitación debido a
problemas en los requerimientos
Identificar las causas que
originaron que se repitieran
sesiones de elicitación
N requerimientos
antes del análisis
Numero de requerimientos encontrados
en la etapa elicitación y la etapa de
revisión de elicitación
Permite identificar los
requerimientos que se encontraron
antes de hacer uso de las checklists
N requerimientos
funcionales
Numero de requerimientos funcionales. Realizar estimaciones de tamaño
del documento de SRS
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 54
N conflictos en
requerimientos
Numero de requerimientos que
presentaron conflictos, no cumplieron
con el estándar de requerimientos.
Realizar un mejor análisis de los
defectos y su tipo que se presentan
en el proceso
N requerimientos
reusados
Numero de requerimientos reusados de
proyectos previos, debido a similitudes o
un análisis de sistemas anteriores
Para poderlos separar del esfuerzo
empleado en el desarrollo de la
especificación de requerimientos
N páginas del
documento de
especificación de
requerimientos
Número de páginas que tuvo el
documento al ser realizado
Realizar estimaciones de tamaño
del documento de SRS
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 55
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 56
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 57
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 58
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
general Registrar el tiempo invertido en la especificación de requerimientos
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
Interrupción
Registrar el tiempo consumido durante las interrupciones
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 59
Bitácora de defectos
Figura 4.2 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ó.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 60
3.3.4.1 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:
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
dominio del
problema
Realizar un análisis del dominio del problema (Guía del dominio del problema) 3.4.2.3.2
2 Estimación de
tamaño y tiempo En base a datos históricos realizar una estimación
de tamaño y tiempo.
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 61
Introducir las estimaciones en el formato de
resumen del plan del proyecto de especificación
de requerimientos 1.0
3 Calendarización de
actividades 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
4 Verificación de la
planeación 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
Criterios de salida 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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 62
participantes del
proyecto
proyecto, definiendo al grupo desarrollador, al
cliente o clientes y usuarios del sistema actual.
3 Elaboración del
glosario Para un mejor entendimiento del dominio es
necesario realizar un glosario con el vocabulario
propio del dominio.
4 Actividades para el
SRS 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
parte del SRS
Información
general Registrar a todos los participantes del proyecto
Como campos obligatorios es necesario el registro del
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 63
nombre y su información de contacto.
Encabezado Se debe llenar lo siguiente
Nombre
Fecha actual
Numero de ejercicio
Breve descripción del ejercicio
Nombre Registrar el nombre del participante del proyecto
Rol Registrar el rol que desempeña el participante del proyecto
Nivel profesional Registrar el nivel profesional del participante del proyecto
Responsabilidades Registrar las responsabilidades que tiene con el sistema el
participante del proyecto
Información de
contacto
Registrar información mediante la cual se le puede contactar, por
ejemplo un correo electrónico o número telefónico.
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 64
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
general Registrar todas las tareas que se consideren pertinentes
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
Hrs
Registrar la suma acumulada de las horas planeadas por cada tarea
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
del valor planeado
Registrar la suma acumulada del valor planeado por cada tarea
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
acumulado ganado
Registrar la suma acumulada del valor ganado por cada tarea.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 65
Figura 4.4 Formato de planeación de tareas
Checklist de planeación
Figura 4.5 Checklist de planeación
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 66
3.3.4.2 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
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
3 Análisis de
requerimientos 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 67
4 Verificación del
análisis de
requerimientos
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
5 Registro de
requerimientos 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
Criterio de salida Una especificación de requerimientos de software
basada en el estándar IEEE 830-1998
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:
A continuación se presentan estos elementos.
Guía de elicitación
Formato de Objetivos y
metas
Minuta de reuniones
Checklist de elicitación
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 68
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
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
3 Identificación de
los requerimientos
del cliente.
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
4 Actividades para el
SRS Se registran los usuarios participantes del proyecto
en la plantilla del SRS, a partir del formato de
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 69
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 70
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
general Registrar todos los objetivos y metas que sean posible
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 71
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
reunión
Registrar cual es el propósito por el que la reunión será realizada
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 72
Figura 4.7 Minuta de reuniones
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 73
Checklist de elicitación
Figura 4.8 Checklist de elicitación
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 74
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:
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
entrada Conocimiento del dominio del problema
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
Guía de análisis
Formato de análisis de
requerimientos
Checklist de análisis
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 75
1 Descripción y
clasificación de
los requerimientos
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.
2 Modelado
conceptual 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.
3 Detectar y
resolver conflictos
entre
requerimientos
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.
4 Actividades para
el SRS Se registran los requerimientos en la plantilla del
SRS tomando la información del formato de
registro de requerimientos
Criterios de salida 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 76
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 77
Checklist de análisis
Figura 4.10 Checklist de análisis
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 78
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:
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 de
entrada 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
1 Obtener un
documento de
especificación de
requerimientos
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 830-1998
Criterio de salida Una especificación de requerimientos de software basada en el
estándar IEEE 830-1998
Bitácoras de tiempos y defectos completas para la etapa de
registro de requerimientos.
Plantilla del documento SRS
Esta plantilla puede ser utilizada para realizar un SRS cumpliendo con el estándar IEEE830, la plantilla
puede ser vista en el anexo 2.
Guía de registro
Plantilla del documento SRS
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 79
3.3.4.3 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:
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
estándar IEEE 830
1 Defectos
introducidos
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
Guía de postmortem
Formato de propuesta de
mejora
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 80
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 81
Figura 4.11 Formato PIP
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 82
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 83
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 84
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 Descripción
Microsoft Word Fue utilizado para leer los formatos y guías que se utilizan
en la metodología, además de poder hacer correcciones al
momento.
Microsoft Excel 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.
Manic Time 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.
Microsoft Visio Utilizado como herramienta de soporte para el diseño de los
casos de uso en el documento de SRS
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 85
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 86
4.6 Casos de Prueba
4.6.1 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
4.6.1.1 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 87
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.
4.6.1.2 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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 88
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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 89
Figura 4.6 Objetivos Caso 1
Figura 4.7 Reunión Caso 1
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 90
Figura 4.8 Requerimientos Caso 1
Figura 4.9 Formato PIP Caso 1
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 91
4.6.1.3 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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 92
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-SSA1-1998.
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
4.6.2.1 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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 93
Notas médicas
Recetas
Reportes
Se debe trabajar con la Norma Oficial Mexicana del expediente clínico (NOM 168-SSA1-1998)
4.6.2.2 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
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 94
Figura 4.11Bitacora de tiempos Caso 2
Figura 4.12 Bitácora de defectos Caso 2
Figura 4.13Participantes del proyecto Caso 2
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 95
Figura 4.14Estimación de tareas Caso 2
Figura 4.15 Objetivos Caso 2
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 96
Figura 4.16 Requerimientos Caso 2
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 97
Figura 4.17Formato PIP Caso 2
4.6.2.3 Análisis de la información
Este ejercicio de tamaño mediano fue trabajado con la metodología MEPERS cumpliendo con las
condiciones de éxito, esta vez la figura 4.10 muestra una mejora en la estimación de tiempo. Aunque
esta estimación todavía no es la adecuada se requiere seguir trabajando para lograr mejorar estas
estimaciones.
Una característica nueva en este trabajo fue el trabajar mediante una norma. Este punto fue
agregado a la plantilla de SRS para futuros trabajos. Además la falta de un cliente ocasionó que se
tuviera información faltante durante el análisis de requerimientos
Los defectos inyectados fueron principalmente durante el análisis, el estándar de defectos
permitió clasificarlos de manera correcta. Y mediante las listas de verificación fueron detectados.
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.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 98
4.7 Riesgos
Tabla 4.4 Riesgos encontrados
Riesgos Plan de Contingencia Impacto
Es necesario una
capacitación en la
metodología
Capacitación de la
metodología
Debido a que se requiere la
costumbre de registrar información,
medir tiempos y análisis del
proceso es conveniente una
capacitación previa. Por ejemplo
con un curso de PSP o TSP.
Las pruebas se
realizaron con
ejercicios básicos.
Aplicarlo con proyectos más
grandes
Aplicarlo con proyectos reales
A causa de que las pruebas eran
muy controladas a la hora de
implementarlo en un ambiente real,
pueden encontrarse ciertos
imprevistos.
El análisis de la
información del
proceso solo se
realizó con una
persona
Tener un grupo mayor de
personas para realizar una
serie de pruebas de la
metodología.
Como sólo se tomó la información
del proceso de una persona, hace
falta una mayor cantidad de
información de varios procesos
para asegurar la utilidad de la
metodología.
4.8 Conclusiones del capitulo
En este capítulo se presentaron los casos de prueba, así como los resultados de aplicar la metodología de
esta tesis.
Se analizaron los resultados demostrando que la metodología cumple el objetivo por el cual fue
diseñada siendo este el conocimiento del proceso personal en la especificación de requerimientos de
software, además se detectaron los riesgos que presenta el uso de esta metodología, se presenta una idea
de ciertas contramedidas para realizar una mejora en este trabajo.
En el siguiente capítulo se presentan las conclusiones que se obtuvieron del trabajo de tesis
realizado.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 99
Capítulo 5 Conclusiones
En este capítulo se presentan las conclusiones de este trabajo de tesis además de sugerencias a considerar
para futuras investigaciones.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 100
5.1 Conclusiones generales
La metodología puede considerase útil tanto para el desarrollador experimentado como para el novato,
sin embargo se recomienda tener una capacitación previa. Ya que sin importar la metodología es
esencial contar con un entrenamiento completo, además de las herramientas de soporte utilizadas durante
el proceso, de lo contrario esta metodología puede ser mal empleada.
Sería interesante contar con cierto grupo de trabajo y que aplicaran la metodología presentada,
analizando la información de los distintos procesos personales, que permita obtener retroalimentación
acerca del proceso y lograr especificar métricas más certeras.
La metodología cumple con el principal objetivo por el cual fue desarrollado ya que utilizando
los distintos elementos que la integran como son 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 es posible localizar las áreas de mejora y proponer
correcciones del proceso personal en la especificación de requerimientos de software.
Una aportación que no forma parte de la metodología pero que se considera importante es la
definición de las etapas del proceso, muchos autores definen estas etapas y existe mucho debate de
cuáles son las correctas o que tareas son más convenientes, realizando un análisis de varias metodologías
se detectaron las etapas comunes y fundamentales, las cuales son empleadas para definir el proceso de la
metodología.
Además se logró un beneficio que originalmente no se tenía contemplado, el de la enseñanza del
proceso de especificación de requerimientos, principalmente mediante el uso de los formatos, guías y
plantillas presentados aquí, es posible obtener un documento de especificación de requerimientos,
incluso si no se desea conocer el proceso personal. Ya que estos elementos cumplen con las
recomendaciones presentadas en [SWEBOK2004].
Es entendible que este trabajo no va a resolver los problemas que se presentan durante y después
de la especificación de requerimientos de software, sin embargo representa un esfuerzo de responder a
los problemas presentados por [STANDISH2009] desde un enfoque que no es considerado, el del
proceso realizado por el desarrollador.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 101
5.2 Objetivos cumplidos
De acuerdo a lo comprometido en el capítulo 1 se cumplió con lo siguiente
El desarrollador al utilizar la metodología le es posible identificar la manera en que realiza su
trabajo mediante los distintos elementos que participan en el monitoreo y análisis del proceso de
especificación de requerimientos además mediante las listas de verificación de cada etapa y el
estándar de defectos propuesto es posible identificar los errores más comunes durante la
especificación de requerimientos de software y con toda esta información plantearse propuestas
de mejora del proceso personal.
Los elementos que integran la metodología pueden ser utilizados de manera independiente como
soporte para realizar el trabajo de especificación de requerimientos de software incluso si no se
emplea la metodología presentada en este trabajo, esto debido a que para su elaboración se
detectaron las tareas más importantes del proceso de especificación de requerimientos.
La metodología conduce a realizar una especificación de requerimientos basada en el formato
presentado en el estándar IEEE830-1998.
Las etapas definidas en esta metodología pueden usarse para la enseñanza de las actividades
principales del proceso de especificación de requerimientos de software
5.3 Trabajo a futuro
Diseñar e implementar una herramienta de software que facilite el uso de la metodología
presentada.
Utilizar la metodología con un mayor número de personas y varios ejercicios para identificar si la
metodología propuesta es útil para distintos procesos de especificación de requerimientos de
software.
Integrar la metodología para la evaluación personal en la especificación de requerimientos de
software, en el proceso de desarrollo de software junto a metodologías existentes como PSP para
programación y desarrollo y TSP para el trabajo realizado en equipo.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 102
Referencias
[ADGM2009] Apollo, A., Davies, F., Gatti, F., Mayyuri, G., “Feature-
OrientedDomainAnalysis (FODA) FantasyFootball Web
Software”, Departamento de ciencias computacionales del instituto
de tecnología de New Jersey, Octubre 2009.
[AMD1993] A.M. Davis, “Software Requirements: Objects, Functions, and
States (revision)”, Prentice Hall, Englewood Cliffs, NJ, 1993,
ISBN: 978-0138057633.
[AVCPS2007] Aranda, G., Vizcaíno, A., Cechich, A., Piattini, M., Soto, J.P.,
(2007), "Una Metodología para elicitación de Requisitos en
Proyectos GSD". En las XII Jornadas de Ingeniería del Software y
Base de Datos (JISBD) dentro del II Congreso Español de
Informática (CEDI), pp. 191-200, ISBN: 978-84-9732-595-0,
Zaragoza (Spain).
[BABA2001] Báez G., Barba S., “Metodología DoRCU para la Ingeniería de
Requerimientos”, Anais do WER01 - WorkshopemEngenharia de
Requisitos, Buenos Aires, Argentina, Noviembre 22-23, 2001, pp
210-222.
[BOKPSP2009] Pomeroy-Huff, M., Cannon, R., Chick, T., Mullaney, J., Nichols,
W. “The Personal Software Process SM (PSPSM) Body of
Knowledge, Version 2.0”Instituto de Ingeniería de Software,
Universidad Carnegie Mellon, Agosto 2009.
[BROOKS1987] Frederick P. Brooks, Jr., "No Silver Bullet-Essence and Accidents
of Software Engineering", Computer Magazine, vol. 20, no. 4, pp.
10-19, April 1987. ISSN: 0018-9162.
[CONN2004] Conn, R., “A reusable, academic-strength, metrics-based software
engineering process for capstone courses and projects”,
Proceedings of the 35th SIGCSE technical symposium on
Computer science education, 2004, ACM SIGCSE Bulletin. Vol.
36, No. 1, pp. 492-296.
[CROSBY1979] Crosby P., “Quality Is Free, The Art of Making Quality Certain”,
Mentor, 1979, ISBN: 978-0451621290
[DAA1993] Davis, A. “Identifying and Measuring Quality in a Software
Requirements Specification”. Proc. 1st Intl. Software Metrics
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 103
Symposium, IEEE, Baltimore, MD. Mayo 1993.
[DHHS2008] Departamento de salud y servicios humanos de Estados Unidos
Americanos, “Selecting a developmentapproach”,
https://www.cms.gov/SystemLifecycleFramework/Downloads/Sel
ectingDevelopmentApproach.pdf, Consultado noviembre 2010.
[DUBE2002] Durán, A., Bernárdez, B., “Metodología para la Elicitación de
Requisitos de Sistemas Software (versión 2.3)”. Informe Técnico
LSI-2000-10, Universidad de Sevilla.
http://www.lsi.us.es/~informes/lsi-2000-10.pdf [Última vez
visitado, 4-7-2010]. Abril 2002.
[ESPE2003] Estrada, A. Pérez, I. “Medir el proceso de control de
configuración, ¿una utopía para la Industria Nacional de
Software?”, Ingeniería informática N°9, 2003, La Habana, Cuba,
ISSN 0717-4195.
[FHKMM1997] Ferguson P., Humphrey W., Khajenoori S., Macke S., Matvya A.,
“Results of Applying the Personal Software Process”, Computer
Magazine, vol. 30, no. 5, pp. 24-31, May 1997,
doi:10.1109/2.589907
[FUGGETTA2000] Fuggetta, A., “Software Process: A Roadmap”, Proceedings of the
Conference on The Future of Software Engineering, 2000,
ISBN:1-58113-253-0
[HEUMANN2003] Heumann J., “The Five Levels of Requirements Management
Maturity”, Requirements Evangelist Rational Software, 2003,
disponible en línea:
http://www.ibm.com/developerworks/rational/library/content/Rati
onalEdge/feb03/ManagementMaturity_TheRationalEdge_Feb2003
.pdf.
[HUMPHREY1995] Humphrey, W. S. “A Discipline for Software Engineering”.
Addison-Wesley, 1995, ISBN: 0201546108.
[HUMPHREY2000] Humphrey, W. “The Personal Software ProcessSM (PSPSM)”,
SEI TECHNICAL REPORT CMU/SEI-2000-TR-022 ESC-TR-
2000-022, Noviembre 2000.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 104
[IDRE2008] Iduñate E., “Conteo semiautomático de líneas de código en
ambientes de desarrollo integrado mediante una estrategia de
marcado de texto en tiempos de codificación”. Tesis de Maestría,
Departamento de Ciencias Computacionales, CENIDET.
[IEEE1233] IEEE Std 1233, “IEEE Guide for Developing System
Requirements Specifications”, IEEE, 1998, ISBN: 0738117234
[IEEE610] IEEE Std 610-1991, “IEEE Computer Dictionary – Compilation of
IEEE Standard Computer Glossaries”, IEEE, 1991, ISBN:
1559370793.
[IEEE830] IEEE Std 830-1998, “IEEE Recommended Practice for Software
Requirements Specifications“, IEEE, 1998, ISBN: 0738103322
[KCHNP1990] Kang,K., Cohen, S. , Hess, J., Novak, W., Peterson,S.
“TechnicalReport CMU/SEI-90-TR-21 ESD-90-TR-222 Feature-
OrientedDomainAnalysis (FODA) FeasibilityStudy”, Instituto de
Ingenieria de Software, Universidad Carnegie Mellon, Noviembre
1990.
[LAPLANTE2007] Laplante, P. A., “What Every Engineer Should Know about
Software Engineering”, CRC Press, 2007, ISBN: 978-
0849372285.
[MARM2001] Martínez R., “Propuesta metodológica para la captura de
requisitos”. Tesis de Maestría, Departamento de Ciencias
Computacionales, CENIDET.
[MEBFN2011] Meyer B., Furia C., Nordio M."15 quality goals for requirements", ETH
Zurich, Febrero 2011
[MERRIAMW] Diccionario de la MerraimWebster lengua inglesa,
http://www.merriam-webster.com/, 2010
[OBPRER1998] Oberg R., Probasco L., Ericsson M., “Applying Requirements
Managenement with Use Cases”, Rational Software Corporation,
Technichal Paper TP505, 1998.
[ORCA2009] Ortiz A., “SiSoProS, Modulo de interfaz de usuario”. Tesis de
Maestría, Departamento de Ciencias Computacionales, CENIDET.
[PFLEEGER2002] Pfleeger, S., “Ingeniería de Software, Teoría y Práctica” Prentice
Hall., 2002, ISBN 987-9460-71-5.
Metodología para la evaluación personal en la especificación de requerimientos de software
Centro Nacional de Investigación y Desarrollo Tecnológico Página 105
[PRESS2006] Pressman R., “Ingeniería de Software: Un Enfoque Práctico”,
McGraw-Hill, 2006, ISBN: 978-8448132149
[RAE] Diccionario de la real academia española, http://www.rae.es, 2010
[SEICMMI2010] Software Engineering Institute, “What is CMMI?”, SEI,
Disponible en línea: http://www.sei.cmu.edu/cmmi/, consultado el
4/07/2010.
[SOI2006] Sommerville, I., “Software Engineering 8th Ed.”, Addison-
Wesley, 2006, ISBN: 978-0321313799
[SOSA1997] Sommerville, I., Sawyer, P., “Requirements Engineering: A good
practice guide”, John Wiley and Sons, 1997, ISBN: 978-
0471974444.
[STANDISH2009] Standish, G., “The Chaos Report”, The Standish Group
International, Boston Massachusetts,2009.
[SWEBOK2004] Abran, A., Bourque, P., Dupuis, R., Moore, J., Tripp, L., “Guide
to the Software Engineering Body of Knowledge”, IEEE, 2004,
ISBN: 0-7695-2330-7.
[THOL2005] Thomas J., Oliveros A. “Definición de un proceso de elicitación de
objetivos”, Tesis de maestría, Facultad de informática de la
Universidad Nacional de la Plata, Argentina, 2005.
[WIKTIONARY] Wiktionary, el diccionario gratis, www.wiktionary.org/
[YOUNG2001] Young, R., “Effective Requirements Practices”, Addison-Wesley,
2001, ISBN: 978-0201709124
Anexo 1. Análisis FODA
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 siguiente figura.
Actividades realizadas FODA
Análisis de Dominio
Análisis de contexto
Diagrama de estructura
Diagrama de contexto
Análisis comparativo
Modelado del dominio
Análisis de información
Modelado de características
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 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.
PSP TSP RUP
Metodología para la
evaluación personal en la
especificación de
requerimientos de
software
Procesos de desarrollo de software
Metodologías para la especificación de requerimientos
Metodología para
la elicitación de
requisitos de
sistemas de
software
Una Metodología
para elicitación de
requisitos en
proyectos GSD
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
A continuación se presenta una tabla que describe cada uno de los niveles que
integran el diagrama de estructura.
Descripción del diagrama de estructura
Nombre Descripción
Nivel1: Estándar IEEE 830-1998 El estándar indica los puntos que deberá contener un
documento de especificación de requerimientos, ya que a
partir de ellos se elaborarán los formatos necesarios para la
especificación de requerimientos de software, además de
las guías para facilitar el llenado de estos formatos.
Nivel2: Técnicas de elaboración
de metodologías
Debido a que se definirá una metodología es necesario el
uso de ciertas técnicas para la elaboración de metodologías.
Estas técnicas en general consideran los siguientes puntos:
Idea a investigar
Planteamiento del problema
Elaboración del marco teórico
Definir el tipo de investigación.
Establecer la hipótesis
Plan de trabajo
Campo de aplicación
Métricas
Análisis de información
Presentación de resultados
Nivel3: Base de datos de la
información del proceso
La metodología permitirá conocer el proceso personal de
un desarrollador al realizar la especificación de
requerimientos, por lo que es necesario definir la
información que será almacenada en los distintos formatos.
Nivel4: Metodologías para la
especificación de requerimientos
En esta parte se muestran algunas metodologías para la
especificación de requerimientos, estas metodologías
atienden el problema de la especificación de
requerimientos considerando distintos enfoques, en
negritas se muestra la metodología para la evaluación
personal en la especificación de requerimientos de
software.
Nivel5: Procesos de desarrollo de
software
En este nivel se encuentran las metodologías para el
proceso de desarrollo de software que tienen relación con
el trabajo a realizar, estas metodologías se caracterizan por
tener definidos los roles y actividades involucradas,
prácticas y técnicas para el desarrollo de proyectos, además
de una serie de guías como apoyo.
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.
Metodología para la evaluación personal en la
especificación de requerimientos de
software
Requerimientos del usuario
Manejo de métricas para la evaluación
personal
Conocimiento del proceso personal en la especificación de
requerimientos
Datos de entrada
Almacena
Procesa información
Retroalimentación del proceso personal
Se genera
Se obtiene
Especificación de requerimientos de
software (SRS IEEE-830)
Registro de tiempos de desarrollo y
defectos presentados
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 830-1998, además de obtener
conocimiento acerca del proceso personal en la especificación de requerimientos de
software.
Descripción del diagrama de contexto
Nombre Descripción
Metodología para la evaluación
personal en la especificación de
requerimientos de software
Tomando como entrada los requerimientos del
usuario se elabora una especificación de
requerimientos de software basada en el estándar
IEEE 830. Esta metodología facilitará el registro
de métricas acerca de su desempeño, análisis y
comprensión de su proceso personal para la
especificación de requerimientos de software,
teniendo como objetivo lograr que el personal
pueda conocer su proceso de especificación de
requerimientos de software y con esto mejorar su
trabajo, además de generar un documento en un
formato estándar.
Requerimientos del usuario Es lo que el usuario o cliente transmite como
resultado esperado.
Registro de tiempos de desarrollo y
defectos
Se utilizarán una serie de formatos para llevar el
control de los tiempos y defectos encontrados en
las distintas etapas de la especificación de
requerimientos
Manejo de métricas para la
evaluación personal
La información almacenada en los formatos es
procesada y utilizada ciertas medidas que
permitan conocer y retroalimentar el proceso
personal.
Especificación de requerimientos de
software (IEEE 830)
Se genera como resultado de utilizar la
metodología.
Conocimiento del proceso personal
en la especificación de
requerimientos de software
Se obtiene conocimiento del proceso personal el
cual le permite al desarrollador mejorar de
manera personal su trabajo 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.
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.
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 IEEE830-1998.
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.
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 830-1998 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.
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 a continuación
Análisis de información
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.
Diagrama de características
Definición de características
En esta actividad se describen las características presentadas en el diagrama de
características
Cada característica presente en el árbol debe ser descrita, el formato para la descripción
es el siguiente:
Nombre de la característica: Obligatorio u Opcional
Descripción:
Padre:
Fuente:
Un ejemplo para la característica de Formatos;
Formatos: Obligatorio
Apoyo para concentración de información de una especificación de
requerimientos.
Padre: Elementos
Fuente: Usuarios del dominio
Las descripciones realizadas son las siguientes.
Nombre Metodología
Descripción Metodología para la evaluación personal en la
especificación de requerimientos de software
Padre Ninguno
Fuente Expertos del dominio
Nombre Desarrollador
Descripción Usuario que trabaja con la metodología
Padre Metodología
Fuente Usuario
Nombre Información General
Descripción Información acerca del desarrollador
Padre Desarrollador
Fuente Usuario
Nombre Etapas del proceso
Descripción Definición de las etapas de la metodología.
Padre Metodología
Fuente Expertos del dominio
Nombre Elicitación
Descripción Etapa del proceso de especificación de
requerimientos donde se realiza la
comunicación con el/los clientes.
Padre Etapas del proceso
Fuente Expertos del dominio
Nombre Entregables Elicitación
Descripción Los documentos que se obtienen en la etapa de
elicitación
Padre Elicitación
Fuente Metodología
Nombre Análisis
Descripción Etapa del proceso de especificación de
requerimientos donde se verifica si los
requerimientos que fueron identificados son
los adecuados o es necesario refinarlos.
Padre Etapas del proceso
Fuente Expertos del dominio
Nombre Entregables Análisis
Descripción Los documentos que se obtienen en la etapa de
análisis
Padre Análisis
Fuente Metodología
Nombre Registro de requerimientos
Descripción En esta etapa los requerimientos que fueron
obtenidos y analizados se procede a
documentarlos con un detalle muy apropiado y
de acuerdo al público al que va dirigido
Padre Etapas del proceso
Fuente Expertos del dominio
Nombre Entregables Registro
Descripción Los documentos que se obtienen en la etapa de
registro de requerimientos
Padre Registro de requerimientos
Fuente Metodología
Nombre Productos
Descripción Productos obtenidos al aplicar la metodología.
Padre Metodología
Fuente Usuario
Nombre SRS
Descripción Documento de especificación de
requerimientos de software; es una descripción
completa del comportamiento del sistema a ser
desarrollado.
Padre Productos
Fuente Usuario
Nombre Conocimiento del proceso personal
Descripción Es el producto de la metodología
Padre Productos
Fuente Metodología
Nombre Propuesta de mejora
Descripción Con el conocimiento del proceso personal es
posible realizar una propuesta de mejora con la
que el proceso se verá beneficiado.
Padre Productos
Fuente Usuario
Nombre Información del proceso
Descripción Es la información que maneja la metodología
acerca del proceso de especificación de
requerimientos de software.
Padre Metodología
Fuente Expertos del dominio
Nombre Motor de métricas
Descripción Encargado de procesar la información del
proceso.
Padre Información del proceso
Fuente Metodología
Nombre Gráficas
Descripción Gráficas que faciliten el entendimiento del
proceso de especificación de requerimientos de
software
Padre Motor de métricas
Fuente Metodología
Nombre Valores del proceso
Descripción Información del proceso de especificación de
requerimientos de software
Padre Motor de métricas
Fuente Usuario
Nombre Elementos
Descripción Herramientas de apoyo para organizar a
información del proceso.
Padre Información del proceso
Fuente Metodología
Nombre Formatos
Descripción Formatos que sirven como apoyo a la
concentración de la información requerida para
realizar la especificación de requerimientos de
software
Padre Elementos
Fuente Metodología
Nombre Propuesta de mejora del proceso
Descripción Es un formato donde el desarrollador podrá
detectar cuáles son sus áreas de mejora para su
proceso.
Padre Formatos
Fuente Metodología
Nombre Resumen del proceso
Descripción Un formato donde se maneja de manera
general la información acerca del proceso de
especificación de requerimientos
Padre Formatos
Fuente Metodología
Nombre Revisiones
Descripción Formatos con los cuales se verifica que el
proceso se cumpla de acuerdo a la
metodología.
Padre Formatos
Fuente Metodología
Nombre Guías
Descripción Documentos que sirven como apoyo para el
llenado de los formatos.
Padre Elementos
Fuente Metodología
Nombre Pasos para llenar formatos y bitácoras.
Descripción Se usan guías que indican paso a paso el
procedimiento para el llenado de formatos y
bitácoras.
Padre Guías
Fuente Metodología
Nombre Estándares
Descripción En esta parte se manejan los estándares
propios que serán usados.
Padre Elementos
Fuente Expertos del dominio
Nombre Estándar de requerimientos
Descripción Este es el estándar de requerimientos en el que
se basará el SRS, la metodología estará basada
en el IEE 830-1998
Padre Estándares
Fuente Expertos del dominio
Nombre Bitácoras
Descripción Registro de información del proceso
Padre Elementos
Fuente Metodología
Nombre Tiempo
Descripción La bitácora de tiempo es el lugar donde se
realizará el registro de tiempos de cada etapa
del proceso de especificación de
requerimientos de software.
Padre Bitácoras
Fuente Usuario
Nombre Defectos
Descripción La bitácora de defectos es el lugar donde se
realizará el registro de defectos del proceso.
Padre Bitácoras
Fuente Usuario
Nombre Problemas
Descripción La bitácora de problemas es el lugar donde se
realizará el registro de problemas encontrados
durante el proceso.
Padre Bitácoras
Fuente Problemas
Anexo 2 Plantilla SRS
Especificación de Requerimientos de
Software
Proyecto: Escribir nombre de proyecto.
Fecha: Haga clic aquí para escribir una fecha.
Versión: Escribir numero de version.
Realizado por: Nombre del autor
Realizado para: Escribir nombre del cliente
Lista de Cambios
Núm. Fecha Descripción Autor
Escribir número de cambio
Dar click en el botón para asignar fecha
Escribir texto que describa los cambios realizados
Escribir nombre del autor del cambio
Validación del documento: Dar click en el botón para asignar fecha
Firma desarrollador Firma cliente
Escribir nombre del desarrollador Escribir nombre del cliente
Índice
Lista de Cambios ..................................................................................................... 2
Validación del documento: Dar click en el botón para asignar fecha ....................... 2
1 Introducción ...................................................................................................... 4
1.1 Propósito .................................................................................................................................................... 4
1.2 Alcance ....................................................................................................................................................... 4
1.3 Definiciones, siglas y abreviaciones ............................................................................................................ 4
1.4 Referencias ................................................................................................................................................. 4
1.5 Apreciación global ...................................................................................................................................... 4
2 Participantes del proyecto ................................................................................ 4
3 Descripción del sistema actual (Opcional) ........................................................ 5
4 Descripcion global ............................................................................................ 5
4.1 Perspectiva del producto ............................................................................................................................ 5
4.2 Funciones del producto .............................................................................................................................. 5
4.3 Características del usuario .......................................................................................................................... 5
4.4 Restricciones ............................................................................................................................................... 5
4.5 Atención y dependencias ........................................................................................................................... 5
5 Requisitos específicos ...................................................................................... 6
5.1 Requerimientos de interfaz ........................................................................................................................ 6
5.1.1 Interfaz de usuario .............................................................................................................................. 6
5.1.2 Interfaz de hardware .......................................................................................................................... 6
5.1.3 Interfaz de software ........................................................................................................................... 6
5.1.4 Interfaz de comunicación ................................................................................................................... 7
5.2 Requerimientos funcionales ....................................................................................................................... 7
5.2.1 Requerimiento funcional 1 ................................................................................................................. 7
5.2.2 Requerimiento funcional 2 ................................................................................................................. 7
5.2.3 Requerimiento funcional 3 ................................................................................................................. 7
5.2.4 Requerimiento funcional n ................................................................................................................. 7
5.3 Requerimientos no funcionales .................................................................................................................. 7
1 Introducción
Escribir aquí una breve introducción, que permita una vista general del SRS
1.1 Propósito
Escribir el propósito del documento, que se pretende y para quien va dirigido
1.2 Alcance
Identificar el alcance que tendrá el producto a desarrollar
1.3 Definiciones, siglas y abreviaciones
Escribir las definiciones, siglas y abreviaciones que sean necesarias para poder hacer una
correcta interpretación del documento
1.4 Referencias
Referencias de todos los documentos que se relacionen con el SRS, se recomienda seguir alguna
norma de referencias bibliográficas
1.5 Apreciación global
Describir lo que contiene el SRS y su organización.
2 Participantes del proyecto
Para cada participante se deberá llenar la siguiente tabla
Tabla 1 Participante 1
Nombre Nombre del participante.
Rol Rol del participante.
Nivel Profesional Nivel profesional del participante.
Responsabilidades Responsabilidades del participante.
Información de contacto Contacto del participante.
3 Descripción del sistema actual (Opcional)
En caso de contar con un sistema actual se debe describir las características de este, en esta sección
4 Descripcion global
4.1 Perspectiva del producto
Se debe describir si el sistema a desarrollar es independiente o pertenece a un sistema mayor. Si es
necesario utilizar diagramas para situar al producto y facilitar su comprensión
4.2 Funciones del producto
Escribir las principales funcionalidades que el producto debe realizar de manera general, en esta
sección no es necesario entrar en muchos detalles, para facilitar el entendimiento del cliente se
recomienda utilizar imágenes, diagramas, tablas, etc.
4.3 Características del usuario
Por cada usuario realizar la siguiente tabla
Tabla 2 Usuario 1
Nombre Nombre del usuario.
Nivel educativo Nivel educativo del usuario
Experiencia Experiencia del usuario.
Especialización técnica Especialización técnica del usuario.
4.4 Restricciones
Escribir las restricciones que presentara el sistema a desarrollar
4.5 Atención y dependencias
Describir las características que podrían ocasionar un cambio en los requerimientos, esto es una
análisis de riesgos y como mitigarlos
5 Requisitos específicos
Esta sección es la más importante del documento, aquí se pondrán los requerimientos que deberá
realizar el sistema y a un nivel de detalle que permita transmitir las ideas al grupo de desarrollo, para
esto se recomienda utilizar casos de uso UML, porque se consideran una herramienta eficaz para una
mejor descripción de los requerimientos.
Las características que debe presentar cada requerimiento que se plantee se muestran en la tabla
siguiente.
Numero o ID Numero o ID del requerimiento.
Nombre Nombre del requerimiento.
Tipo Tipo de requerimiento.
Fuente Fuente del requerimiento.
Prioridad Prioridad del requerimiento.
Breve descripción Descripción del requerimiento.
5.1 Requerimientos de interfaz
En esta sección se pondrán las características detalladas de cada entrada y salida de un sistema de
software se divide en 4 subsecciones
5.1.1 Interfaz de usuario
Describir los requerimientos que deberá cumplir la interfaz para el usuario
5.1.2 Interfaz de hardware
Describir los requerimientos que deberá tener el hardware con el que se trabajara
5.1.3 Interfaz de software
Si el producto a ser desarrollado se comunicara con otro software, se debe poner en esta sección las
características del software y el propósito
5.1.4 Interfaz de comunicación
Describir los requerimientos que deberá cumplir el sistema si se comunica con otros sistemas
5.2 Requerimientos funcionales
En esta sección se describen las características fundamentales que deberá realizar el software, para
producir los resultados esperados. Aquí es donde se recomienda utilizar casos de uso y sus plantillas
ya que cada requerimiento deberá mostrar sus entradas, salidas, secuencias de acciones, escenarios
de éxito y fracaso. Por cada requerimiento se recomienda realizar una subsección como se muestra
más adelante
5.2.1 Requerimiento funcional 1
5.2.2 Requerimiento funcional 2
5.2.3 Requerimiento funcional 3
5.2.4 Requerimiento funcional n
5.3 Requerimientos no funcionales
En esta sección se describen los requerimientos no funcionales, existe mucha controversia en esta
sección, sin embargo de acuerdo al estándar IEEE 830-1998, se consideran los requerimientos del
rendimiento, seguridad, fiabilidad, disponibilidad, mantenibilidad y portabilidad, esta sección queda a
criterio del desarrollador, sin embargo se recomienda utilizar la tabla 3