TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Manuel Adrian... · Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Metodología para la Evaluación Personal

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.



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



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




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


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



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


CAPÍTULO 5 CONCLUSIONES .................................................................................. 99

5.1 Conclusiones generales ................................................................................................................ 100

5.2 Objetivos cumplidos .................................................................................................................... 101

5.3 Trabajo a futuro .......................................................................................................................... 101

REFERENCIAS................................................................................................................ 102



Í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



Í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)



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].



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.



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.



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.



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.



“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



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.



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.



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



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.



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"



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



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.



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.



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]



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.



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.



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.



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



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]



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”).




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.



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.



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


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 comparativo






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.


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



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




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.



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.



Tabla 3.1 Tabla comparativa de metodologías

Características “Una Metodología para


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


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.



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



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.



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.



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


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.



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.



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.



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.



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


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.



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.



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.



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.



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


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.



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


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



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



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.



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


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.



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


Además como parte del trabajo de tesis desarrollado se proponen unas métricas para la


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


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.



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



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


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



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.



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.



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


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



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



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.


Nombre

Fecha actual

Numero de 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ó.



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.


Formato de resumen de plan de proyecto de

requerimientos 1.0



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

Guias/Guía de Planeacion MEPERS.docx

Guias/Guia del dominio del problema.docx

Guias/Formatos/Guia de FORMATO de participantes del proyecto.docx

Guias/Formatos/Guia de FORMATO planeacion de tareas.docx

Guias/Formatos/Guia de FORMATO planeacion de tareas.docx



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.


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



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


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



nombre y su información de contacto.


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




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.


Nombre

Fecha actual

Numero de 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.



Figura 4.4 Formato de planeación de tareas

Checklist de planeación

Figura 4.5 Checklist de planeación



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


Criterios de entrada Conocimiento del dominio del problema

Formato de planeación de tareas y participantes del proyecto.


requerimientos 1.0 con los estimados de tamaño

y tiempo



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.


2 Verificación de la

elicitación de

requerimientos

Seguir el checklist de elicitación de requerimientos y verificar la elicitación realizada.



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.



4 Verificación del

análisis de

requerimientos

Seguir el checklist de análisis de requerimientos y verificar el análisis realizado.



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


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


estos son:


Guía de elicitación

Formato de Objetivos y

metas

Minuta de reuniones

Checklist de elicitación

Guias/Guia de Elicitacion.docx

Guias/Formatos/Guia de FORMATO de objetivos y metas.docx





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.


requerimientos 1.0 con los estimados de tamaño

y tiempo


Plantilla de SRS


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



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



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


Nombre

Fecha actual

Número de 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



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


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.



Figura 4.7 Minuta de reuniones



Checklist de elicitación

Figura 4.8 Checklist de elicitación



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


estos son:


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


requerimientos 1.0 con los estimados de

tamaño y tiempo

Plantilla del SRS



Checklists

Guía de análisis

Formato de análisis de

requerimientos

Checklist de análisis

Guias/Guia de Analisis.docx

Guias/Formatos/Guia de FORMATO analisis de requerimientos.docx

Guias/Formatos/Guia de FORMATO analisis de requerimientos.docx



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.



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


Nombre

Fecha actual

Numero de 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



Checklist de análisis

Figura 4.10 Checklist de análisis



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


estos son:


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


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



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

Guias/Guia de Registro.docx

Guias/Especificación de Requerimientos de Software.dotx



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:


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 1.0


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

Guias/Guia de PostMortem.docx

Guias/Formatos/Guia de FORMATO PIP.docx



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.


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



Figura 4.11 Formato PIP




En esta capitulo se presentaron las bases, el proceso a seguir y los elementos que participan en la


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




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.



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



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.



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.



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



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



Figura 4.6 Objetivos Caso 1

Figura 4.7 Reunión Caso 1



Figura 4.8 Requerimientos Caso 1

Figura 4.9 Formato PIP Caso 1



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.



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



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



Figura 4.11Bitacora de tiempos Caso 2

Figura 4.12 Bitácora de defectos Caso 2

Figura 4.13Participantes del proyecto Caso 2



Figura 4.14Estimación de tareas Caso 2

Figura 4.15 Objetivos Caso 2



Figura 4.16 Requerimientos Caso 2



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.



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.


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.



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.



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.



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.



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



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.



[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.



[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 comparativo




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.


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



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


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


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.


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


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


software (SRS IEEE-830)


defectos presentados


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


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.


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.


software (IEEE 830)

Se genera como resultado de utilizar la

metodología.

Conocimiento del proceso personal

en la especificación de


Se obtiene conocimiento del proceso personal el

cual le permite al desarrollador mejorar de

manera personal su trabajo en la especificación de


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


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


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


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 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 que describe la descomposición de las características en sub características de manera jerárquica.


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


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


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


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.



Nombre Entregables Análisis


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



Nombre Entregables Registro


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


Padre Metodología


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


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


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


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


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


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.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.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

TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Manuel Adrian... · Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Metodología para la Evaluación Personal

Documents