Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
CIS1430IS08 V2SOFT: GUÍA METODOLÓGICA PARA EL PROCESO DE VALIDACIÓN Y
VERIFICACIÓN DE REQUERIMIENTOS PARA EL USUARIO FINAL
MARÍA XIMENA NARVÁEZ BARRERA
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTÁ, D.C.
2015
Ingeniería de Sistemas Memoria de Trabajo de Grado – Guía metodológica
Página i
CIS1430IS08
V2SOFT: GUÍA METODOLÓGICA PARA EL PROCESO DE VALIDACIÓN Y
VERIFICACIÓN DE REQUERIMIENTOS PARA EL USUARIO FINAL
Autor:
María Ximena Narváez Barrera
MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO
DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE
SISTEMAS
Director
Miguel Eduardo Torres Moreno
Jurados del Trabajo de Grado
Claudia Marcela Rodríguez Viveros
Jaime Andrés Plavlich Mariscal
Página web del Trabajo de Grado
http://pegasus.javeriana.edu.co/~CIS1430IS08
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTÁ, D.C.
MAYO, 2015
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página ii
PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
Rector Magnífico
Jorge Humberto Peláez Piedrahita, S.J.
Decano Académico Facultad de Ingeniería
Ingeniero Jorge Luis Sánchez Téllez
Decano del Medio Universitario Facultad de Ingeniería
P. Antonio José Sarmiento Nova, S.J.
Director de la Carrera de Ingeniería de Sistemas
Ingeniero Germán Alberto Chavarro Flórez
Director Departamento de Ingeniería de Sistemas
Ingeniero Rafael Andrés González Rivera
Ingeniería de Sistemas Memoria de Trabajo de Grado – Guía metodológica
Página iii
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus
proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral
católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que
se vean en ellos el anhelo de buscar la verdad y la Justicia”
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página iv
AGRADECIMIENTOS
Tengo varias personas a quien agradecer por todo el apoyo recibido en el trabajo de grado,
pero antes que nada, quiero agradecer a Dios por permitirme continuar y estar presente para
cumplir con esta meta propuesta, agradecer porque me dio la fortaleza y los ánimos para
seguir en el camino que empecé hace varios años.
A Miguel, mi director de trabajo de grado, porque desde el primer momento en que acepto
dirigir la tesis hasta el último día ha sido una persona primordial para realizar este trabajo, es
una persona a la que le he aprendido muchísimo y continuo aprendiendo, es más lo que estoy
agradecida que lo que puedo expresar aquí.
A mis padres y hermanos, que son mi fuente, son mis ganas de seguir, porque ellos son los
que han estado todo este tiempo detrás de mí y nunca perdieron la esperanza de verme
terminar, de verme finalizar la carrera.
A Ricardo que siempre busca como subirme los ánimos.
A la organización donde trabaje hasta enero del 2015 que me permitieron realizar la encuesta,
en realidad, es pensando en ellos que desarrolle este trabajo de grado.
Por último a mi perrita Martina, que aunque al principio no me dejaba trabajar, se acostumbró
a que trabajara junto a ella.
Ingeniería de Sistemas Memoria de Trabajo de Grado – Guía metodológica
Página v
CONTENIDO
Tabla de contenido CONTENIDO ............................................................................................................................ v
I - INTRODUCCIÓN ............................................................................................................... 1
II - DESCRIPCION GENERAL ............................................................................................... 2
1 Oportunidad, Problemática, antecedentes ......................................................................... 2
Formulación del problema .................................................................................................... 2
1.1. Solución a la problemática .................................................................................... 3
1.2. Justificación del problema .................................................................................... 4
1.3. Impacto Esperado .................................................................................................. 4
2. Descripción del Proyecto .............................................................................................. 5
2.1. Objetivo general .................................................................................................... 5
2.2. Objetivos específicos ............................................................................................ 5
3. Metodología .................................................................................................................. 6
3.1 A nivel de proyecto ......................................................................................................... 6
3.2 A nivel de la guía metodológica ................................................................................... 14
III - CONTRIBUCIONES ...................................................................................................... 17
1. Conceptos Fundamentales .......................................................................................... 17
1.1.1 Objetivo de la Validación y Verificación .............................................................. 18
1.1.2 Pruebas de Software ............................................................................................... 19
¿Porque las pruebas son necesarias? ............................................................................... 21
Pruebas a realizar ............................................................................................................ 21
Niveles de pruebas .......................................................................................................... 24
1.1.3 Casos de pruebas .................................................................................................... 30
Elementos de un caso de prueba ..................................................................................... 31
2. Trabajos relacionados ................................................................................................. 44
3. Justificación ................................................................................................................ 47
4. Descripción de la Solución ......................................................................................... 50
1.1 Validación y verificación de requerimientos en el ciclo de vida ........................ 50
1.2 Proceso de prueba: .............................................................................................. 51
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página vi
1.3 Adaptación del modelo en V, a la problemática a resolver ................................. 52
1.4 Identificación de actividades de acuerdo al modelo en V y al proceso de pruebas.
53
1.5 Definición de las actividades del proceso – Desarrollo de la guía y “Way –Of” 56
1.6 Supuestos y restricciones de la guía .................................................................... 57
5. Validación ................................................................................................................... 58
6. Validación y Resultados ............................................................................................. 60
1.1 Primera evaluación – Guía metodológica semestre 2014 ................................... 60
1.2 Segunda evaluación – Guía metodológica semestre 2015 ................................. 66
7. Análisis de Impacto ..................................................................................................... 74
8. Conclusiones ............................................................................................................... 74
Trabajos futuros .............................................................................................................. 75
IV. Referencias y Bibliografía ................................................................................................ 79
Referencias .................................................................................................................... 79
Anexo 2. Post-Mortem ............................................................................................................ 82
1. Metodología propuesta vs. Metodología realmente utilizada. .................................... 82
2. Actividades propuestas vs. Actividades realizadas. .................................................... 82
3. Efectividad en la estimación de tiempos del proyecto ................................................ 82
Otros anexos ........................................................................................................................... 83
Plantilla plan de pruebas ..................................................................................................... 83
Plantilla documento gestión de riesgos ............................................................................... 83
Plantilla documento casos de pruebas ................................................................................. 83
Plantilla para la ejecución de casos de pruebas. .................................................................. 83
Plantilla para el informe de avance de pruebas. .................................................................. 83
Ingeniería de Sistemas Memoria de Trabajo de Grado – Guía metodológica
Página vii
ABSTRACT
Software outsourcing development to expert firms, is a solution that allows companies to focus in
their core business, and make their own activities.
In order to ensure, size, and establish the correct delivery and compliance of the requirements
defined, a methodological guide was developed. It establishes how to define and implement the
process of validation and verification of requirements, from the viewpoint of final user. (A person
who has no technical knowledge, and is not involved in the process of building the system, but
has business knowledge)
RESUMEN
Tercerizar el desarrollo de software en empresas expertas, es una solución que permite que
las empresas se enfoquen en su centro de negocio y a realizar sus propias actividades.
Con el fin de garantizar, medir, establecer la correcta entrega y el cumplimiento de los
requerimientos definidos, se desarrolló una guía metodológica que establece la manera de
definir y realizar el proceso de validación y verificación de requerimientos, desde el punto de
vista del usuario final. (Una persona que no tiene conocimientos técnicos, ni se encuentra
envuelta en el proceso de construcción del sistema, pero si cuenta con el conocimiento del
negocio)
Pontificia Universidad Javeriana Trabajo de Grado – Guía metodológica
Página 1
I - INTRODUCCIÓN
En este documento se presenta un resumen sobre el proceso realizado para el desarrollo del
trabajo de grado V2Soft: Guía metodológica para la validación y verificación de los
requerimientos para el usuario final. Cuyo objetivo principal es apoyar el proceso de
Validación y Verificación de requerimientos funcionales de software, bajo las características
de las empresas que no desarrollan sus productos.
El documento está conformado por cuatro secciones que se enfocan en describir el proceso
del trabajo de grado desde los puntos de vista de la descripción del proyecto y desde el punto
de vista de las contribuciones del trabajo de grado. La primera sección presenta la descripción
general del trabajo de grado, donde se contextualiza al lector sobre la problemática que busca
solucionar el trabajo grado y como lo soluciona, también encontrara la información sobre el
objetivo general, los objetivos específicos y la metodología empleada para el trabajo.
En la segunda sección, se presentan las contribuciones del trabajo de grado, inicia con el
marco teórico donde se encuentra la base del conocimiento para el desarrollo del proyecto y
de la guía metodológica, continua con la descripción de la solución, seguido por el proceso de
evaluación de la solución, con las conclusiones del proceso y de los resultados obtenidos. Y
finaliza con una propuesta de trabajos futuros.
La tercera sección presenta las referencias y la bibliografía utilizada en el trabajo de grado y
por último la cuarta sección presenta los anexos del documento.
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 2
II - DESCRIPCION GENERAL
1 Oportunidad, Problemática, antecedentes
Formulación del problema
En Colombia se presenta el modelo de empresa que busca el desarrollo de sus necesidades o
productos de software, en empresas terceras mediante el outsourcing, debido que el proceso de
desarrollo de software, no hace parte de su modelo de negocio y permite que la empresa se enfoque
en lo que realmente es lo suyo, se oriente a sus propios servicios, a sus clientes y producir los
resultados alineados a sus objetivos para cumplir su misión y visión, “de lo contrario la empresa
tendría que asumir desarrollos que no podría soportar con personal de dedicación exclusiva y
aumentos en la carga prestacional”[1]. Dejar en manos de terceros, las necesidades, le permite a la
empresa, responder a un mercado cada vez más exigente y ser cada vez más competitivo, “en esas
condiciones, todas las empresas necesitan servicios especializados, porque ninguna organización
puede hacer de todo con buena rentabilidad.”[1]
Dicho de otra manera, por estrategia, necesidades, competencia y oportunidades, cuando las
empresas requieren crear nuevos productos o servicios, o bien realizar mejoras a los ya existentes,
para ofrecerlos a sus clientes tanto externos como internos y así optimizar procesos que van acorde
a su negocio, recurren a empresas especialistas para que implementen sus requerimientos.
Dada esta característica, la empresa que terceriza el desarrollo de software, realiza una definición y
especificación de los requerimientos que se deben satisfacer, los entrega al contratista para que
realice el desarrollo y queda a la espera de ver los requerimientos en una aplicación funcional.
Cuando se cumple el proceso de desarrollo y la empresa recibe el software, algunas empresas,
realizan una fase adicional, antes de poner a disposición el producto. Realizan la Validación y
Verificación de los requerimientos en el software, este proceso, permite evaluar la completitud,
consistencia y comportamiento del producto y así tener la garantía que se satisface los
requerimientos establecidos.
En la Ilustración 1, se sintetizan las actividades anteriormente mencionadas, correspondientes a la
empresa que busca el outsourcing como solución para el proceso de desarrollo:
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 3
Ilustración 1. Actividades Empresa
El proceso de validación y Verificación de requerimientos consiste en la comprobación de los
requerimientos desarrollados conforme a los especificados, acorde a la definición del International
Software Testing Qualifications Board, la verificación es la "Confirmación mediante examen y
mediante el suministro de evidencia objetiva que la especificación de los requisitos se han
cumplido."[2] y la validación es la "Confirmación mediante examen y mediante el suministro de
evidencia objetiva de que se han cumplido los requisitos para un uso específico previsto o
aplicación."[2]
En el estudio de la validación y verificación de requerimientos, se ha identificado, una problemática
correspondiente a los requerimientos de sistemas no triviales, cuya complejidad, obliga que el
proceso sea riguroso y exhaustivo; teniendo en cuenta la definición dada por [3] “en primer lugar,
las pruebas no son determinantes. En segundo lugar, es necesario realizar pruebas bajo restricciones
de tiempo y presupuesto.”, y al ser un proceso necesario, que no solo depende de la habilidad y del
conocimiento del negocio de quien realiza la actividad, sino también de factores externos (tiempo,
recursos, presupuesto), se evidencio la oportunidad de realiza una guía metodología que apoye el
proceso de validación y verificación de requerimientos, bajo las condiciones descritas: empresa no
desarrolladora. Lo que genero la siguiente pregunta ¿Cómo lograr la validación y Verificación de
requerimientos, que garantice la completitud de su especificación, para empresas que contratan
desarrollos a externos (outsourcing)?
1.1. Solución a la problemática
Se desarrolló una guía metodológica, para la validación y verificación de los requerimientos de
software, para empresas que no implementan sus requisitos, para brindar una alternativa de mejora
al proceso, para el fortalecimiento y la claridad a las actividades que deben llevarse a cabo a partir
de las buenas prácticas, para la reducción de los riesgos referentes al proceso y así garantizar la
calidad integral y el cumplimento de los objetivos del sistema.
Define y especifica
Requerimientos
Terceriza desarrollo
Recibe desarrollo
Valida y Verifica Requerimientos
Certifica producto
Instalación del producto en producción
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 4
1.2. Justificación del problema
La calidad de los proyectos de software está directamente relacionada con el proceso de validación
y verificación de requerimientos, debido que el proceso busca garantizar que los requerimientos
establecidos se cumplan, se encuentren acorde a su especificación y su funcionalidad sea la
esperada por el usuario final. [3], [4]
A partir del conocimiento de la importancia del proceso de la validación y verificación de los
requerimientos y de los constantes problemas que se presentan en algunas aplicaciones de la
organización donde actualmente trabajo, (empresa que cumple con el esquema al que va dirigida la
guía), surgió la pregunta generadora: ¿Qué estrategia se debe seguir en la verificación de la calidad
del software, con base a la validación de los requerimientos?, buscando forma de trabajo y
procedimientos que se deban seguir para que no se presenten inconvenientes en el proceso.
El trabajo de grado tenía como fin generar una guía metodológica, para dar una alternativa de
mejora al proceso de validación y verificación de requerimientos y una solución a la problemática
identificada. Se determinaron las actividades y tareas necesarias para el proceso, bajo los
lineamientos de las buenas prácticas, estándares y metodologías de pruebas, pensando siempre en
el beneficio de las empresas que tercerizan el desarrollo y realizan la validación y verificación de
requerimientos mediante las pruebas funcionales del software.
Por lo tanto, los interesados de los resultados del trabajo de grado son las personas que a diario
realizan el proceso de validación y verificación de requerimientos y se enfrentan a la problemática
mencionada anteriormente, particularmente al grupo de trabajo de la organización donde
actualmente laboro. Pero beneficio es para todas las empresas que presentan el modelo de la
Ilustración 1 y el interés estará determinado por las necesidades de mejorar el proceso.
1.3. Impacto Esperado
El impacto esperado de la guía es su uso tanto a nivel académico como a nivel organizacional.
Se espera que la guía desarrollada, realmente aporte al proceso de validación y verificación de
requerimientos en las organizaciones que tercerizan el desarrollo, se considera que se brindan los
elementos suficientes y necesarios para realizar el proceso con calidad y buenos resultados.
Se considera que la guía puede tenerse en cuenta en el ámbito académico con el fin de
profundizar sobre la Validación y Verificación de requerimientos y concientizar a los estudiantes
sobre la importancia del proceso, para que cada día y cada nueva generación de presente mayor
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 5
interés en el desarrollo con calidad. A continuación en la Ilustración 2, se especifica otros
impactos esperados por el trabajo de grado.
Ilustración 2. Impactos esperados
2. Descripción del Proyecto
A continuación se presenta la descripción general del proyecto
2.1. Objetivo general
Desarrollar una guía metodológica que apoye el proceso de Validación y Verificación de
Requerimientos, por parte de Stakeholders con rol de usuario y cliente, en empresas que no
son desarrolladoras de Software1
2.2. Objetivos específicos
• Generar documento del estado del arte sobre las prácticas y modelos actuales de validación
y verificación de los requerimientos de software para usuario final.
• Seleccionar las mejores prácticas y modelos de validación y verificación de los
requerimientos.
• Identificar las debilidades, falencias y/o problemáticas presentadas en el proceso de
validación y verificación de requerimientos.
1 Que usan los servicios de un tercero para el desarrollo de software, o, Empresas cuyo fin no es el desarrollo de software, o , Empresas
clientes que no son del ámbito del desarrollo de software
• Continuidad en la investigación sobre la Validación yVerificación de Requerimientos, no solamente parausuario final, si no también se realice en todos losámbitos posibles, como por ejemplo las validacionesestáticas y por modelos.
Corto Plazo
• Aplicación de la guía en empresas que tercerizanel desarrollo de software.
• Análisis de costo y beneficio de implementación.Mediano Plazo
• En empresas que aplican la guía, se presentenmenos inconvenientes e incidentes por parte delproceso de validación y verificación derequerimientos.
Largo Plazo
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 6
• Elaborar una guía metodológica, que especifique el proceso de validación y verificación de
los requerimientos de software, dando alternativas de manejo a los puntos críticos
identificados, en el marco de referencia de una empresa no desarrolladora de software
• Evaluar la guía metodológica planteada, por medio de lista de chequeo y encuestas,
dirigidas a expertos en validación y verificación de requerimientos
3. Metodología
Para el desarrollo del trabajo de grado, se emplearon principalmente dos metodologías, la primera
fue a nivel de proyecto, que dirigía la ejecución de las actividades y las tareas programadas, y la
segunda la metodología implementada fue para el desarrollo de la guía metodológica, ver
Ilustración 3.
Ilustración 3. Metodologías del proyecto
3.1 A nivel de proyecto
El trabajo de grado se desarrolló bajo la metodología SCRUM, fue seleccionado e implementado,
por ser un marco de trabajo iterativo e incremental para el desarrollo de proyectos y productos, bajo
el esquema de trabajo de las metodologías ágiles. Lo que facilito que el cumplimiento del desarrollo
de los objetivos, se dieran con incrementos continuos.[5], [6] y la evolución del proyecto, a partir
de la revisión de las iteraciones, SCRUM “tiene como base la idea de creación de ciclos breves,
que comúnmente se llaman iteraciones, y que en Scrum se llamarán “Sprint” ”[6], de acuerdo a [5]:
“Se denomina Sprint a cada ciclo o iteración de trabajo que produce una parte del producto
terminada y funcionalmente operativa (incremento)”.
Esquema de trabajo en SCRUM, está compuesto por cuatro artefactos y cuatro eventos. Los cuatro
artefactos se definidos a continuación:
Proyecto Trabajo de grado.
SCRUM
Actividades del proyecto
Metodología propia del
Sprint
Guía metodología
Marco de referencia “Way – Of”
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 7
• Product backlog: es la pila del producto, contiene la lista de requerimientos y necesidades
de usuario que se deben satisfacer en el producto, esta lista presenta la visión inicial del
proyecto, pero esta crece y evoluciona durante el desarrollo del proyecto. [5]
• Sprint backlog: es la pila del sprint, contiene las actividades o tareas que se deben realizar
en un sprint específico para realizar un incremento. [5]
• Sprint: como se definió anteriormente, el sprint corresponde a las iteraciones del producto,
“Es el núcleo central que genera el pulso de avance por tiempos prefijados”. [5]
• Incremento: Resultado de la ejecución de cada Sprint. [5]
Cada Sprint del proyecto se enfocó en el desarrollo de los objetivos específicos. Cada Sprint tenía
un propósito, una metodología de desarrollo, actividades o tareas y resultados correspondientes a
los entregables del proyecto (incrementos).
Por otro lado, los eventos de SCRUM, determinan las actividades generales del Sprint, los cuales
son: “Reunión de planificación del sprint”, “Scrum diario”, “Revisión del sprint” y “Retrospectiva
del sprint”, definidos en Ilustración 4.
Ilustración 4. Eventos de los Sprint, basado en [5], [6]
En la Ilustración 5, se presenta el esquema de trabajo de la metodología en función del trabajo de
grado. A partir de los objetivos del proyecto, se definieron los Sprints que se debían realizar y la
lista de actividades del proyecto o product backlog. Cuando se realiza la ejecución de un Sprint
Reunión de planificación
del Sprint
Determinar cuales y como van a ser las
funcionalidades que se incorporaran en el
Sprint
Qué se entregará al terminar el Sprint.
Cuál es el trabajo necesario para realizar el incremento previsto,
y cómo lo llevará a cabo
Scrum diario
Evaluación diaria del avance del
proyecto:
- Lo que ha logrado desde el anterior
scrum diario.
- Lo que va ha hacer hasta el próximo
scrum diario.
- Si están teniendo algún problema, o si
prevé que puede encontrar algún impedimento.
Revisión del Sprint
Al finalizar cada Sprint se revisa
funcionalmente el resultado, con los implicados del
proyecto.
Permite descubrir planteamientos
erróneos,
mejorables o malinterpretaciones
en las funcionalidades
Retrospectiva del Sprint
Reunión donde se debate el Sprint recientemente
finalizado y los cambios que se
podrían mejorar en el próximo Sprint.
¿Qué ha ido bien durante el último
Sprint? , ¿Qué será mejorado para el siguiente Sprint?
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 8
especifico, se tomaban las actividades definidas del sprint y se incluían en el Sprint backlog. En la
ejecución del sprint, se desarrollaron las actividades propias del sprint en ejecución, a partir de los
ciclos diarios o ciclos de trabajo, se obtuvo el incremento iterativo. Al director de trabajo de grado
se le realizaron entregas del resultado de los sprints, pero también se realizaron entregas a medida
que se tenían avances, no necesariamente cuando el producto del sprint se encontraba finalizado,
debido que la ejecución de un sprint podía durar un tiempo considerable, como por ejemplo el
desarrollo del marco teórico o de la guía metodológica. El director realizaba la retroalimentación de
los productos recibidos, cuando se identificaba un cambio o mejora este se incluía en la lista
product backlog. Si el producto se finalizaba y a partir de la retroalimentación del director no
necesario realizar un cambio, el producto se daba por cerrado.
Ilustración 5. Proceso metodología SCRUM Trabajo de grado
La metodología SCRUM, permitió tener las siguientes ventajas en el desarrollo del trabajo de
grado:
• El desarrollo del producto, se realiza por iteraciones, lo que permitió al director conocer el
la evolución y avance del proyecto de trabajo de grado. Como se mencionó anteriormente,
se realizaron entregas parciales, con los avances obtenidos durante los sprints. [6]
• Las entregas del producto, permitieron realizar mejoraras a partir de las retroalimentaciones
recibidas por parte del director. SCRUM busca que se establezca una comunicación
continua para evitar errores, trabajo innecesario y la retroalimentación constante ente el
equipo y el cliente para obtener un producto de alta calidad. [6]
• SCRUM al ser una metodología ágil, asume los cambios como algo natural durante la
ejecución del proyecto, por lo que se requirió tener control sobre los resultados obtenidos
en cada sprint y las retroalimentaciones. Fue necesario para cada Sprint, tener en cuenta el
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 9
ciclo PDCA ver Ilustración 6, para planear y definir las nuevas actividades, a partir del
resultado de la retroalimentación o actividades que se identifican como necesarias y que no
se tuvieron en cuenta en la planeación inicial. [6]
Ilustración 6. Ciclo PDCA de cada Sprint
En la propuesta de trabajo de grado se identificaron seis Sprints, que durante la ejecución del
proyecto, se modificaron para incluir un séptimo, que contemplo el desarrollo de la memoria y la
página web del trabajo de grado.
Para el desarrollo del proyecto en el 2015 se incluyeron los Sprint identificados como necesarios
para:
• Mejorar guía metodológica.
• Evaluar la guía a partir de los cambios realizados.
• Desarrollar memoria trabajo de grado.
• Complementar página web.
Para el seguimiento del desarrollo de los sprint, se utilizó la herramienta de gestión Trello, ver
tablero del trabajo de grado en https://trello.com/b/7LqCeX3y/trabajo-de-grado-ximena. Trello
permitió realizar el seguimiento de las actividades, definir las fechas de ejecución, incluir listas de
chequeo con las tareas de cada actividad, que a medida que se iban realizando se marcaban como
completada.
La herramienta fue adaptada a SCRUM, con el fin de definir los tiempos de control de las
actividades y la planeación de ejecución. El tablero de control, permitía ver como las actividades en
los eventos, ver Ilustración 7 donde se presentan los componentes del tablero.
El tablero en trelllo, presenta dos listas de actividades realizadas, las ejecutadas en el semestre del
2014 y las ejecutadas en el semestre 2015.
Planear
HacerVerificar
Actuar
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 10
Ilustración 7. Trello adaptado a Scrum
A continuación se presentan en la Tabla 1, los Sprints que fueron ejecutados a lo largo del trabajo de grado y la metodología propia del Sprint que
fue utilizada, en el semestre 2014 se realizaron del Sprint 1 al Sprint 7, y en el semestre de 2015 los Sprint del 8 al 11.
Sprint Objetivo Metodología Justificación metodología Resultados
Sprint 1:
Investigación
Investigar las fuentes
primarias y
secundarias
necesarias para el
desarrollo del trabajo
de grado
Exploratoria
Se seleccionó la metodología debido que permite realizar
“Un avance en el conocimiento de un fenómeno, con
frecuencia con el propósito de precisar mejor un problema
o para poder explicitar una hipótesis” [7], Malhotra en [8]
comenta sobre la metodología exploratoria: “Es el diseño
de investigación que tiene como objetivo primario facilitar
una mayor penetración y compresión del problema que
Matriz de
bibliografía
•Lista de actividades del trabajo de grado
Product backlog
•Actividades que se realizaran en siguiente sprint
Sprint planing•Actividades que se realizaran en el sprint que se esta ejecutando
Sprint backlog
•Actividades del trabajo de grado en ejecución
In progress•Actividades del trabajo de grado terminadas.
Done
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 11
enfrenta el investigador”
Sprint 2:
Desarrollo del
marco teórico
Desarrollo del marco
teórico que
correspondió a una
base fundamental
para el desarrollo del
trabajo de grado.
Descriptiva
Se implementó esta metodología ya que permitió el
desarrollo de las bases teóricas para el proceso de
validación y verificación de requerimientos.
Tal como se describe en [8] “La investigación descriptiva
es el tipo de investigación concluyente que tiene como
objetivo principal la descripción de algo, generalmente las
características o funciones del problema en cuestión”
Documento de
marco teórico
Sprint 3:
Selección de
metodologías
acorde a las
necesidades de la
guía
Seleccionar las
metodologías sobre
el proceso de
validación y
verificación de
requerimientos, para
el desarrollo de la
guía
Descriptiva
Permitió la selección de las mejores prácticas y modelos
de validación y verificación de los requerimientos y
permite encontrar la relación entre las variables de
estudio. Debido que “La Investigación descriptiva es
aquella que busca especificar las propiedades,
características, y los perfiles importantes de personas,
grupos, comunidades o cualquier otro fenómeno que se
someta a un análisis” [9]
Se realizó la
documentación
como complemento
en el marco teórico
Sprint 4:
Identificar las
debilidades,
falencias y/o
problemáticas
Identificar y
determinar las
debilidades, falencias
o problemáticas del
proceso de
Validación y
Verificación de los
Cuantitativa /
Descriptiva
Se escogió la metodología descriptiva, debido que permite
identificar las propiedades en estudio, se realizó encuesta
a un grupo de personas que trabajan en el Esqueda de
empresa al que va dirigida la guía, permitió reconocer e
identificar las variables a mejorar para el proceso de
validación y verificación de requerimientos. Se realizó el
análisis de los datos recolectados en la encuesta que
Documento de
análisis de encuesta
donde se
determinaron las
necesidades del
proceso.
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 12
requerimientos desde
el punto de vista de
las necesidades de
los Stakeholders, con
el fin de identificar
oportunidades de
mejora
permitió interpretar las necesidades del proceso.
Sprint 5:
Desarrollo de la
Guía
metodológica
Desarrollo de la guía
metodológica V2Soft
del trabajo de grado
Descriptiva,
bajo el marco
de referencia
“Way-of”
El desarrollo de la guía tomo como marco de referencia
“Way-of” para describir los componentes para el
desarrollo de la guía.
Se eligió la metodología descriptiva, debido que permitió
realizar la definición y descripción del proceso para la
validación y verificación de requerimientos para las
empresas que tercerizan el desarrollo.
V2Soft: Guía
metodológica para
el proceso de
validación y
verificación de
requerimientos para
el usuario final
Sprint 6:
Metodológica
Evaluación de la
guía
Evaluación de la guía
metodológica
desarrollada en el
sprint anterior
Descriptiva
Se realizó el proceso de la evaluación de la guía
metodológica por medio de expertos, que midieron la
guía a partir de los puntos identificados en el sprint 4.
Documento de
evaluación de la
guía metodológica.
Sprint 7:
Desarrollo de
memoria de grado
y página web
Desarrollo de la
memoria del trabajo
de grado y página
web
Descriptiva
El desarrollo tanto de la memoria del trabajo de trabajo de
grado y la página web se realizó a través de la
metodología descriptiva, que permitió la descripción del
proceso del trabajo de grado.
Memoria trabajo de
grado y página web
Sprint 8: Definición de puntos Descriptiva La definición de los puntos de mejora, se realizó a partir Matriz de puntos de
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 13
Identificar puntos
a mejorar
a mejorar de la guía de la lectura y análisis de la guía metodología desarrolla
en el semestre del 2014, y teniendo en cuenta los puntos
mencionados por los expertos. Se determinaron los puntos
de mejora y de profundización que permitieron
complementar y reforzar la guía.
mejora
Sprint 9:
Profundización
Guía
Desarrollo de puntos
de mejora en la guía
metodológica.
Exploratoria
/ Descriptiva
A partir de la metodología exploratoria, se realizó la
búsqueda de fuentes de información sobre los temas a
mejorar. Para la inclusión de la información en la guía
metodológica, se siguió la metodología descriptiva.
V2Soft: Guía
metodológica para
el proceso de
validación y
verificación de
requerimientos para
el usuario final
Sprint 10:
Evaluación de la
guía
Evaluación de la guía
metodológica con los
puntos adicionales.
Descriptiva /
análisis
cualitativo y
cuantitativo
Se realizó el proceso de la evaluación de la guía
metodológica obtenida en el Sprint anterior, por medio
de la evaluación de expertos. La evaluación se desarrolló
a partir del análisis cualitativo y cuantitativo.
Documento de
evaluación de la
guía metodológica.
Sprint 11: Ciclo
de mejora de
memoria trabajo
de grado y página
web
Complemento y
actualización de la
memoria de trabajo
de grado y página
web.
Descriptiva
El complemento y actualización de la memoria de trabajo
de grado se realizó a partir de la metodología descriptiva
de los resultados y procesos realizados.
Memoria trabajo de
grado y página web
Tabla 1. Sprints del trabajo de grado
Ingeniería de Sistemas Memoria Trabajo de grado – Guía Metodológica
Página 14
3.2 A nivel de la guía metodológica
Para el diseño y construcción de la guía metodológica, se tomó como base el marco de referencia
“Way-of” o “forma de” en español[10], debido que permite modelar los procesos de negocio, por lo
tanto definir la guía por su modo de pensamiento, modelamiento, conceptos, administración y
trabajo.[11]
El marco de referencia “Way-of” está compuesto por los siguientes componentes:
Way of Thinking – Forma de Pensar: Define los lineamientos con los que se va a
desarrollar la guía, por lo tanto provee una perspectiva del dominio del problema y hace
explicita las suposiciones, principios y estrategias sobre el método. [10] Presenta tres
puntos de vista:
o El objetivo (propósito): Relaciona las metas y las estrategias que la empresa
implementa en sus procesos de negocio. [10]
o Vista dinámica: Relacionada a los eventos, actividades y procesos de negocio que
describen la forma de funcionamiento de la empresa. [10]
o Vista estática: Relaciona los datos, productos e insumos producidos o que son
manejados durante la ejecución de los procesos de negocio. [10]
Way of Working – Forma de Trabajar: Define la estructura del proceso: las actividades,
tareas y la secuencia en el que se deben llevar a cabo. Establece los lineamientos para el
desarrollo de las actividades. [10]
Way of Modelling – Forma de Modelar: Provee información de los conceptos para el
modelamiento, junto con sus relaciones y propiedades. Estructura los modelos y provee un
lenguaje para expresarlos. [10]
El detalle de los modelos, depende de lo que se quiera representar, mientras mayor sea el
detalle, se tendrá mayores definiciones como las formas de trabajo, que ayudan a los
administradores a la toma de decisiones. [10]
Way of Controlling – Forma de Controlar: Este aspecto es el administrativo del
modelo, determina cómo se debe controlar y evaluar el proceso. [12]
Way of Supporting – Forma de Soportar/Apoyar: Se refiere a las técnicas,
herramientas y ayudas de trabajo que apoyan la ejecución del proceso. [10], [12]
En la Ilustración 8, se presenta la integración de los componentes “Way – Of”, y se presentan las
siguientes definiciones:
• Producto: Conjunto de diagramas o esquemas que describen el nuevo modelo que será
construido y la organización en la que va a operar. [10]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 15
• Proceso: Lleva el registro del cómo el producto se ha construido. [10]
Ilustración 8. Marco de referencia, adaptado de [10], [12]
El marco de referencia elegido, respecto a la guía metodológica se presenta en la Tabla 2, donde se
presenta de manera general la descripción de cada “Way –of” y la guía.
Way Of Aspecto a tener en cuenta Descripción guía
Way of thinking
• Enmarca a la guía
metodológica.
• Define los factores especiales
se deben tener en cuenta para
implementar el proceso de
Validación y Verificación de
requerimientos.
Se tuvo en cuenta para la ejecución de
actividades, el modelo en V del ciclo de
desarrollo con el fin de ejecutar
actividades de manera transversal al
desarrollo y tener un involucramiento
temprano.
Way of
modeling
• Lenguaje utilizado para generar
el modelo.
• Factores especiales de la
organización y su estado actual.
Para el modelado de las actividades, se
utilizó la notación BPM – Business
Process Management (Gestión de procesos
de negocio), para realizar la representación
gráfica del modelo de negocio.
Way of working • Actividades y • El proceso de validación y verificación
Way of thinking - Forma de
pensar
Way of supporting – Forma
de soportar o apoyar
Way of modeling -
Forma de modelar
Way of working-
Forma de trabajar
Proceso
Way of Controlling -
Forma de controlar
Producto
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 16
responsabilidades. de requerimientos, tomo como base
fundamental para su desarrollo, el
proceso establecido por el “International
Software Testing Qualifications Board”
– ISTQB, adaptado a las necesidades de
una empresa que no es desarrolladora de
software.
• La forma de trabajar, permitirá el
cumplimiento de los objetivos que se
establezcan.
Way of
controlling
• Objetivos serán medidos a
través de indicadores.
• Definición de indicadores para conocer
los niveles de cumplimiento de los
objetivos.
• La manera de realizar la medición
depende del objetivo que se desea
medir.
Way of
supporting
• Que necesita el proceso para su
ejecución: Recursos humanos y
herramientas de pruebas.
• Para el soporte del proceso, se
definieron roles y sus responsabilidades
para la ejecución de cada actividad.
• Se incluyeron herramientas de apoyo
como por ejemplo plantillas para
registrar información.
Tabla 2. “Way of” y la guía metodológica
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 17
III - CONTRIBUCIONES
1. Conceptos Fundamentales
El proceso de Validación y Verificación de los requerimientos, busca garantizar que los
requerimientos especificados se cumplan en todo el proceso del desarrollo de software, tal como se
define en Sommerville, “La verificación y la validación (V & V) es el nombre dado a estos procesos
de análisis y pruebas. La verificación y validación tienen lugar en cada etapa del proceso de
software. V & V comienza con revisiones de los requerimientos y continua con revisiones del
diseño e inspecciones de código hasta la prueba del producto” [4], este proceso permite comprobar
que de los requerimientos desarrollados se encuentran conforme a los requerimientos especificados
y cumplen un propósito. El International Software Testing Qualifications Board define la
verificación como la "Confirmación mediante examen y mediante el suministro de evidencia
objetiva que la especificación de los requisitos se han cumplido."[2] y la validación es la
"Confirmación mediante examen y mediante el suministro de evidencia objetiva de que se han
cumplido los requisitos para un uso específico previsto o aplicación."[2].
Es importante diferenciar la validación y la verificación de requerimientos ya que no son lo mismo
y a menudo estos dos términos se confunden entre sí debido que las definiciones no presentan de
manera clara la diferencia. Boehm en [4], [13], definió de la siguiente manera:
“Validación: ¿Estamos construyendo el producto correcto?”
“Verificación: ¿Estamos construyendo el producto correctamente?”
Lo que significa que con el proceso de verificación se busca detectar o corregir errores que desvían
del resultado esperado acorde a los requerimientos definidos, que el software cumple con los
requerimientos funcionales y no funcionales [4]; mientras que con el proceso de validación se busca
detectar o corregir los errores que desvían los requerimientos, necesidades y expectativas del cliente
[4]. Con la verificación se evidencia si el software se cumple con lo especificado, mientras que con
la validación se evidencia si realmente el software hace lo que debe realizar.
El estándar internacional ISO/IEC 12207 [14] define que “El propósito de la Verificación del
software es confirmar que cada producto, servicio o proyecto, refleja adecuadamente los
requerimientos especificados” y “El propósito del proceso de Validación es confirmar que se
cumplen con los requerimientos para un uso específico y cumple con lo previsto del producto de
software”.
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 18
Como resultado esperado de la implementación del proceso de Verificación y Validación se tiene,
de acuerdo a [14]:
1. Una estrategia para la Verificación y Validación desarrollada e implementada
2. Criterios de Verificación y Validación son necesarios y requeridos son identificados
3. Ejecución de actividades de Verificación y Validación
4. Defectos y problemas son identificados y registrados
5. El resultado del proceso se define que el software o producto es apto y se pone a
disposición del cliente y partes interesadas.
1.1.1 Objetivo de la Validación y Verificación
El proceso de Validación y Verificación de requerimientos permite realizar una evaluación objetiva
de los productos de software durante su ciclo de vida, permitiendo así:
• Determinar si el software cumple el propósito por el que fue creado.[15]
• Garantizar que el sistema es lo suficientemente bueno para su uso pretendido. [15]
• El nivel de confianza requerido depende del propósito del sistema, las expectativas de los
usuarios del sistema y el entorno de mercado actual del sistema.[15]
Entre los beneficios del proceso:
• Facilitar la detección temprana y la corrección de las anomalías [16]
• Asegurar los requerimientos del usuario.[15]
• Remover los defectos del producto fuera del ciclo de vida del proyecto, reduciendo el
volver a trabajar sobre el mismo aspecto, y reduciendo los costos por la baja calidad. [15]
• Asegurar que las necesidades de los usuarios son comprendidas y asegurar que los
productos satisfagan el entorno previsto para el que fueron desarrollados. [15]
• Mejorar la calidad de los procesos y los productos. [15], [16]
• Mejorar la productividad y permite conocer de manera temprana el rendimiento.[15], [16]
• Mejorar la comprensión de la gestión de riesgos de procesos y productos.[16]
• Proporcionar evidencia objetiva de conformidad del producto para apoyar al proceso de
certificación.[16]
• Soporte a las actividades de mejora de procesos. [16]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 19
1.1.2 Pruebas de Software
En esta sección se presenta la información del marco teórico recolectada y analizada sobre pruebas
de software que permite soportar los procesos de validación y verificación dinámica de los
requerimientos.
Conceptos
Pruebas
Las pruebas de software son un proceso que permite determinar la calidad de un producto o sistema,
validar y verificar que el software realiza las funciones esperadas y satisface el propósito para la
cual fue diseñado. A continuación se presentan distintas definiciones sobre las pruebas de software:
Según la definición de IEEE “Las pruebas son un proceso de analizar un elemento de
software para detectar las diferencias entre las condiciones existentes y las condiciones
necesarias, y evaluar las características de un elemento de software.” [17].
El Swebok define “Las pruebas de software consiste en la verificación dinámica del
comportamiento de un programa sobre un conjunto finito de casos de prueba,
adecuadamente seleccionados a partir del dominio de ejecución generalmente infinito, en
relación con el comportamiento esperado”[18]
Myers en el libro the art off software testing, define “La prueba es el proceso de ejecución
de un programa con la intención de encontrar defectos” [19], señala la importancia del
significado, debido que anteriormente se tenía el concepto errado sobre las pruebas: "El
proceso de demostrar que los errores no están presentes.", basándose en aspectos
psicológico del ser humano, “Si nuestro objetivo es demostrar que un programa no tiene
errores, entonces subconscientemente estará dirigido hacia este objetivo; es decir,
seleccionara los datos de prueba que tienen una baja probabilidad de causar el programa
falle. Por otro lado, si nuestro objetivo es demostrar que un programa tiene errores, los
datos de prueba tendrán una mayor probabilidad de encontrar errores.”[19]
Error
Entre las definiciones de la Real Academia de la lengua Española, se presenta que un error es una
“Acción desacertada o equivocada” o “Cosa hecha erradamente” [20]. La IEEE presenta varias
definiciones de lo que es un error, pero para este contexto se encuentra “acción humana que
produce un resultado incorrecto”[21], “acción humana que genera un fallo en el software. Por
ejemplo: omisión o mala interpretación de requerimientos, traducción incorrecta, o la omisión de
requerimientos en el diseño”[22].
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 20
Defecto
La IEEE define el defecto como “un problema que, si no se corrige, podría causar la falla en una
aplicación o producir resultados incorrectos.” [21], o, “Una anomalía producto”[22]. El
International Software Testing Qualifications Board (ISTQB), define un defecto como la
“Imperfección en un componente o sistema que puede causar que el componente o sistema falle en
desempeñar las funciones requeridas, por ejemplo una sentencia o una definición de datos
incorrectas. Si se localiza un defecto durante una ejecución puede causar un fallo en el componente
o sistema.”[2].
En la industria del software, un defecto se produce cuando[23]:
1. El software no hace algo que la especificación dice que debe hacer.[23]
2. El software hace algo que en la especificación del producto dice que no debe hacer.[23]
3. El software hace algo que en la especificación no se menciona.[23]
4. El software no hace algo que la especificación no se menciona pero debería.[23]
5. El software es difícil de entender, difícil de usar, lento, o el probador de software con ojos
de usuario final sabe que el software no está bien.[23]
Falla
El International Software Testing Qualifications Board (ISTQB), define la falla como la
“Desviación del componente o del sistema respecto de prestación, servicio o resultado esperado”[2],
la IEEE define la falla como “La terminación de la capacidad de una unidad funcional para realizar
su función requerida. (2) Un evento en el que un sistema o componente del sistema no realiza una
función determinada dentro de los límites especificados.”[22]
En la Ilustración 9, se presenta la relación entre los términos anteriormente presentados, en resumen
se tiene que:
Una falla es un evento.
El defecto es un estado del software, causado por un error.
Las pruebas buscan defecto en el software.
Las pruebas pueden descubrir defectos y fallas, pero es el error el que se debe
solucionar.[18]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 21
Ilustración 9.Relación Error, defecto, falla
¿Porque las pruebas son necesarias?
Las pruebas de software son necesarias debido a que:
• Mide la calidad de un producto, de acuerdo con [24] las pruebas brindan información sobre
las características de calidad del producto.
• Permite conocer si el producto de software realiza lo que se espera que haga [24]
• Las pruebas permiten identificar defectos.
• Las pruebas permiten verificar y validar el software de manera dinámica, para confirmar si
el software cumple con los requerimientos especificados y su propósito.
• Las pruebas aportan fiabilidad y confianza del sistema, cada vez se encuentran defectos y
estos son solucionados, la calidad del software aumenta. [25]
• Disminuye los costos de mantenimiento post – producción. [26]
• Disminuye los riesgos por incumplimiento de tareas. [26]
Un producto de software es imposible crearlo perfecto, por lo tanto, el proceso de pruebas es
obligatorio y debe realizarse de manera eficaz, para garantizar la funcionalidad esperada y el
hallazgos de defectos, para reducir la probabilidad de ocurrencia de errores en el ambiente
productivo y la materialización de los riesgos asociados. Un error en producción impacta a los
usuarios y sistemas finales, es mejor evitar problemas que solucionarlos. [24]
Pruebas a realizar
Cuando se realizan pruebas de software, se debe determinar la cantidad de pruebas que se van a
ejecutar en el sistema debido a que no es recomendable, ni viable probar todo.
Error•Acción humana
• Genera un resultado incorrecto
Defecto•Consecuencia del error
•Conocido como Bug en el Software
Falla
•Consecuencia del defecto
•Desviación del componente
•Afecta la producción
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 22
Para determinar la cantidad de pruebas a realizar, se recomienda tener en cuenta aspectos como:
1. Niveles de riesgo: Permite determinar por donde iniciar las pruebas, donde se debe probar
más[25]. Evaluando desde el punto de vista tecnológico, del negocio, de pruebas, de
proyecto y el impacto de la materialización del riesgo.
2. Restricciones del proyecto: por ejemplo tiempo, presupuesto y recursos.
3. Requerimientos que constituyen el software: Por ejemplo requerimientos contractuales o
legales o Requerimientos específicos.
4. Priorizar las pruebas: Asignar un grado de importancia a cada prueba dependiendo del
impacto de la funcionalidad en el negocio, permite determinar el orden de ejecución de las
pruebas y donde enfocar los esfuerzos de pruebas. Algunos criterios para la priorización de
pruebas incluyen los siguientes aspectos [25], [27]:
• Donde el fallo puede ser más severo
• Donde el fallo puede ser más visible
• Donde un fallo es más probable
• Basado en las prioridades asignadas por el negocio y por los usuarios
• Basado en la criticidad para el negocio del cliente
• Basado en las áreas o módulos que cambian más a menudo
• Basado en las áreas con el mayor número de problemas en el pasado
• Basado en las áreas o módulos más complejas
• Basado en las áreas o módulos técnicamente más vulnerables
Objetivos de quien realiza pruebas.
Los objetivos de quien ejecuta las pruebas, de acuerdo a Patton [23] son:
Encontrar defectos, no solo probar por bien, ni crear casos de prueba para que sean
exitosos. [23]
Encontrar defectos y encontrarlos lo más pronto posible. La persona que realiza pruebas
“Son los ojos de cliente, son los primeros que ven funcionando el software, por lo tanto
habla por el cliente y debe exigir perfección”[23]
Encontrar errores, encontrarlos lo antes posible, y asegurarse de que se arreglen.[23]
Características de las pruebas
Atributos para una buena prueba:
Una buena prueba tiene una elevada probabilidad de encontrar un error: es necesario que
la persona que realiza la prueba conozca el software y las posibilidades de falla. [28]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 23
Una buena prueba no es redundante: Cada caso de prueba debe tener su propio objetivo y
propósito. [28]
Una buena prueba debe ser “la mejor de su clase”: “Un grupo de casos de pruebas con un
objetivo similar y recursos limitados podría optarse por la ejecución de un solo
subconjunto de ellas. En este caso, debe usarse la prueba que tenga la mayor probabilidad
de descubrir un tipo completo de errores.” [28]
Una buena prueba no debe ser ni muy simple ni demasiado compleja: una prueba puede
contener otra prueba pero esto puede llevar a que no se evidencien los errores si no estos
se enmascaren, lo recomendable es mínimo un caso de prueba por requerimiento.[28]
Niveles de pruebas
Las pruebas se realizan en diferentes niveles durante su desarrollo y mantenimiento, dependiendo
de su propósito, uso, comportamiento o estructura[18]. Por lo tanto el nivel de prueba es un grupo
de actividades organizadas y gestionadas de manera conjunta [2], define el objetivo de la prueba, el
enfoque, el propósito y el momento en el que se ejecutan, permiten validar y verificar el software
desde un punto de vista de los responsables del proyecto.[18]
Pontificia Universidad Javeriana Trabajo de Grado – Guía metodológica
Página 24
Niveles de pruebas
Pruebas unitarias o de componente
Descripción: Permite verificar los componentes o módulos del sistema de manera individual. [3], [28]
Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas
• Localizar defectos[25]
• Comprobar y asegurar el
funcionamiento de los
módulos del software,
programas, objetos,
clases, del sistema objeto
de la prueba.[25]
• Verificar que los flujos de
control y de datos se
encuentren cubiertos, y
que funcionen según lo
esperado. [28]
• Módulo/
componente
desarrollado
• Diseño
detallado[26]
De acuerdo al ISTQB
[25]:
• Requerimientos de
componentes
• Diseño detallado
• Código
• Componentes o
módulos [25], [21]
• Programas [25]
• Conversación de
datos[25]
• Procedimientos
asociados.[21]
• Módulos de bases
de datos. [25]
Roles que intervienen
en la prueba:
• Participa el
desarrollar del sistema.
[25],[26]
Corrección de
defectos:
• Se corrigen defectos
cuando son detectados,
por lo tanto no
necesitan una gestión
formal. [25]
• Modulo Probado
[26]
• Modulo listo
para integrar[26]
Tabla 3. Pruebas unitarias
Pruebas de integración
Descripción: Permite verificar la interacción entre los componentes del software. [18]
Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 25
• Verificar la
integración de los
componentes del
sistema.
• Evaluar la
interacción entre los
distintos sistemas o
entre el hardware y
el software. [25]
• Pruebas unitarias
ejecutadas [28].
• Producto
integrado
• Plan de pruebas
de integración. [26]
De acuerdo al ISTQB
[25]:
• Diseño de software y
sistema
• Arquitectura
• Flujos de trabajo
• Casos de uso
• Implementación de
base de datos de
subsistemas [25]
• Infraestructura [25]
• Interfaces [25]
• Configuración del
sistema y datos de
configuración [25]
Quien ejecuta la
prueba:
• Grupo de desarrollo
del sistema, ingenieros
de software. [28]
• Ingeniero de pruebas
[26]
• Jefe de desarrollo[26]
• Informe de
Pruebas de
Integración.[26]
• Producto listo
para su entrega a
pruebas[26]
Técnicas o estrategias
Integración Big-bang
• Todos los componentes y unidades del sistema se ensamblan resultando un sistema completo[26]
• Ventaja: no es necesario simular ninguna parte del sistema porque todo está integrado listo para iniciar las
pruebas.[26]
• Desventaja: No es fácil encontrar la causa del error debido que no es posible aislar los errores encontrados[26]
Arriba hacia abajo
(top-down)
• Las pruebas inician con los módulos de nivel superior, es decir los módulos con mayor nivel de abstracción, para ir
descendiendo de manera progresiva a los más inferiores y probar así su integración.[26]
• Al no tener el sistema completo integrado, es necesario que se desarrollen programas auxiliares de nivel inferior que
simulen el correcto funcionamiento. [26]
Abajo a arriba
(bottom-up)
• Las pruebas inician con los módulos de nivel inferior, es decir los módulos más especializados, para ir ascendiendo de
manera progresiva a los más superiores.[26]
• No se dispone del sistema completo hasta el final, por lo tanto es necesario que se desarrollen programas auxiliares de
nivel superior que permiten probar la integración. [26]
Tabla 4. Pruebas de integración
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 26
Pruebas de sistema
Descripción: Permiten realizar la validación total del sistema implementado, y en la interacción entre los componentes integrados o sistemas
Objetivo Entradas Documentos
base
Objeto de
prueba Otros aspectos Salidas
• Verificar la funcionalidad
del sistema a través de sus
interfaces externas
• Comprobar que la
funcionalidad corresponda
a la esperada de acuerdo a
los requerimientos. [18]
• Las pruebas del sistema no
se limita a sistemas. Si el
producto es un programa,
las pruebas del sistema es
el proceso de tratar de
demostrar cómo el
programa, en su conjunto,
no cumple con sus
objetivos.[19]
• Pruebas de
integración
ejecutadas.
[26]
• Definición
de un
conjunto de
objetivos
medibles
para el
producto.[19
]
• Plan de
pruebas de
sistema[26]
De acuerdo al
ISTQB [25]:
• Especificación
de
requerimiento
s
• Casos de uso
• Especificacion
es funcionales
• Informe de
análisis de
riesgos
• Manuales de
sistema,
usuario y
funcionamient
o [25]
• Configuración
del
sistema[25]
• Datos de
configuración.
[25]
Roles que intervienen:
• Equipo de pruebas independiente[25]
• Ingeniero de pruebas[26]
• Analista funcional[26]
• Jefe de pruebas[26]
Técnicas:
• Basadas en especificación: técnicas
de caja negra [25] y
• Basadas en estructuras: técnicas de
caja blanca [25]
Corrección de defectos:
• Se reportan las inconsistencias
encontradas.
• Se genera nueva versión del software
con la solución del defecto y es
entregado para pruebas de sistema.
De acuerdo a
INTECO [26]:
• Informe de
Pruebas de
Sistema.
• Manual de
Usuario.
• Manual de
Administració
n.
• Plan e Informe
de Pruebas
• Sistema
probado
Tabla 5. Pruebas de sistema
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 27
Pruebas de aceptación
Descripción: Las pruebas que busca determinar si el sistema satisface los criterios de aceptación.[29]Por lo tanto permite “Verificar la idoneidad
de uso del sistema por parte de los usuarios”[25]. Estas pruebas son importantes, tal cual se menciona en Pressman “En la práctica es imposible
que un desarrollador de software prevea cómo utilizará el usuario realmente el programa. Es imposible que se malinterpreten las instrucciones de
uso, que se utilicen con regularidad extrañas combinaciones de datos, que una salida en apariencia clara para el responsable de las pruebas sea
ininteligible para el usuario de campo”[28]
Objetivo Entradas Documentos base Objeto de
prueba Otros aspectos Salidas
• Determinar si el usuario,
cliente, u otra entidad
autorizada acepta el
sistema o componente
objeto de la
prueba.[29],[21]
• Validar los requerimientos
[28]
• “El objetivo principal de
las pruebas de aceptación
no es localizar defectos, si
no evaluar la buena
disposición de un sistema
para su despliegue y
• Ejecución de
pruebas de
sistema[26]
• Especificación
de
requerimientos
[26]
• Manuales de
usuario[26]
• Plan de
pruebas[26]
De acuerdo al ISTQB
[25]:
• Requerimientos de
usuario
• Requerimientos de
sistema
• Casos de uso
• Procesos de negocio
• Informes de análisis de
riesgos
• Procesos de
negocio [25]
• Procesos
operativos y de
mantenimiento
[25]
• Procedimiento
s de usuario[25]
• Formularios
[25]
• Informes [25]
Quien ejecuta la
prueba:
• Analistas de
pruebas
• Usuario del
sistema[25]
• Ingeniero de
pruebas [26]
• Jefe de pruebas
[26]
• Jefe del proyecto
[26]
• Resultados de
pruebas [26]
• Producto
aceptado [26]
• Informe de
pruebas de
aceptación [26]
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 28
uso.”[25], demostrando que
el software se encuentra
listo para el paso a
producción. [26]
Estrategias de pruebas de aceptación
Pruebas Alfa (α)
• El usuario o cliente realiza pruebas del sistema en el entorno de desarrollo [25],[26]
• Se trabaja en un entorno controlado y el cliente siempre tiene un experto que le ayuda a usar el sistema.[28],[26]
• El desarrollador registra los defectos encontrados y los problemas de uso. [26]
Pruebas Beta (β)
• Se realizan después de las prueba alfa. [26]
• Las pruebas se realizan en el entorno del cliente, es decir en un entorno externo a desarrollo [18], [26]
• Las pruebas las realizan los clientes o clientes potenciales [25]
• El cliente realiza las pruebas del producto y registra e informa los fallos encontrados al desarrollador. [28],[26]
Tabla 6. Pruebas de aceptación
Pruebas de regresión
Descripción: Ejecución de casos de pruebas anteriormente ejecutados cuando se implementan cambios en el software. [28]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 29
Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas
• Asegurar que los cambios en el sistema
no afecte de manera negativa el software
(comportamientos no esperados o errores
adicionales).[28]
• Permite asegurar los cambios del
sistema.[28]
• Verificar el correcto funcionamiento del
software ante cambios del mismo.[26]
• Demostrar que las pruebas que fueron
exitosas en el software, continúan siendo
exitosas. [18]
• Incorporación de
un cambio en el
sistema, sea por
nuevas
funcionalidades o
mejoras a las ya
existentes
• Solución a
defectos. [26]
• Las pruebas de regresión se pueden realizar en cada uno de los niveles
de pruebas mencionados anteriormente. [18]
• Las pruebas de regresión se realizan en durante todo el ciclo de vida del
sistema y se ejecutan cada vez que se modifica un componente del
sistema [30], en la Ilustración 10 se presenta como las pruebas de
regresión hacen parte de las pruebas de las pruebas unitarias, integración
y pruebas de sistema.
• Por lo tanto los documentos bases, el objeto de prueba, otros aspectos y
salida dependen del nivel de prueba en el que se realiza la prueba de
regresión.
Tabla 7. Pruebas de regresión
Ilustración 10.Pruebas de regresión en, tomado de [30]
PRUEBAS DE REGRESIÓN
Pruebas
unitarias
Pruebas de
integración
Pruebas de
Sistema
Pruebas de
Aceptación
Pontificia Universidad Javeriana Trabajo de Grado – Guía metodológica
Página 30
1.1.3 Casos de pruebas
Uno de los conceptos más importantes en el proceso de pruebas de software, son los casos de
prueba, debido que suministran la información necesaria para la ejecución y el paso a paso que
debe ejecutar el probador para la prueba. En esta sección se encuentra la información relacionada a
los casos de pruebas.
¿Qué es un caso de prueba?
De acuerdo a la IEEE y al ISTQB, un caso de prueba es un conjunto de valores de entradas,
condiciones previas de ejecución, resultados esperados y condiciones posteriores de ejecución, para
cumplir con un objetivo en particular, condición de prueba, evento, o sistema, desarrollado para
verificar o validar el cumplimento de los requerimientos. [2], [21],[29]
Define los pasos a seguir para poder verificar el comportamiento esperado del sistema y los
requerimientos establecidos.
Permite realizar la evaluación sobre un objeto de prueba.
La definición de los casos de prueba debe ser un proceso iterativo. [31]
Un caso de prueba puede cubrir una o varias condiciones de pruebas.
Debe ser repetible, verificable y localizable en los requerimientos.[25]
Características y beneficios de un caso de prueba
Un caso de prueba, se encuentra completo si su definición cumple con las siguientes características,
de acuerdo a [32], [31]:
• Preciso: Describe que se va a probar
• Efectivo: Tiene una probabilidad de encontrar defectos. [31]
• Trazable: El caso de prueba se encuentra relacionado a un requerimiento. [25]
• Evolutivo: Fácil de mantener[31]
• Eficiente: El caso de prueba presenta únicamente los pasos que son necesarios, evitando los
pasos innecesarios. [31]
• Estado inicial: Luego de la ejecución del caso de prueba, el ambiente de pruebas retorna a
su estado normal
Por lo tanto, si un caso de uso bien definido, brindara los siguientes beneficios para el proceso de
pruebas[33]:
1. Registra el comportamiento del sistema.
2. Registra el límite y o alcance del caso de prueba.
3. El caso de prueba puede ser reutilizable.
4. Se puede determinar el momento exacto en el que se produce un error.
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 31
5. Se puede utilizar el caso de prueba como una unidad medible.
Elementos de un caso de prueba
Los casos de prueba deben definir la información necesaria para la ejecución de las pruebas, en la
Ilustración 11, se presenta los elementos que debe incluirse en la definición de los casos de prueba.
Ilustración 11. Casos de pruebas, adaptado de [31]
Técnicas de pruebas
Las técnicas de pruebas son procedimientos que permite la selección y diseño de pruebas
ejecutables de manera efectiva, permite identificar las condiciones de pruebas, casos de pruebas y
datos de pruebas.[25] Existen dos grandes grupos de técnicas de pruebas, las técnicas basadas en la
especificación del sistema comúnmente llamadas técnicas de caja negra y las técnicas basadas en la
estructura conocidas como técnicas de caja blanca [25],[26], que no son objetivos de la guía por lo
Identificador único • Identificador del caso de prueba de manera única, permite distinguir el caso de los demás. [31]
Objetivo• Define el propósito del caso de prueba, el como se debe probar y que se va a probar: Que se va a validar o a verificar. [30],[31]
•Se puede incluir el riesgo o la prioridad [31]
Condición de prueba
•"Un elemento o evento de un componente o sistema que debería ser verificado por uno o más casos de prueba, por ejemplo, una función, transacción, característica, atributo de calidad, o elemento estructural." [8]
Entradas
•Datos de entra o datos de pruebas (test data) que son requeridos para la ejecución del caso.[31]
•Valores de entrada o nombre de archivos o constantes que se utilicen.[31]
Precondiciones•Estado y condiciones previas que el sistema debe cumplir para la ejecución del caso de prueba. [30]
Resultados esperados
•Comportamiento esperado del sistema a partir de las entradas y las condiciones de ejecución.[31]
•Salidas, cambios de estados, valores especificos.[31]
Condiciones Posteriores
•Estado esperado del sistema luego de la ejecución del caso de prueba.[31]
Configuración de ambiente
•Definir las necesidades a nivel de hardware, software, que son requeridas para la ejecución de las pruebas. [31]
Dependencias•Relación de casos de pruebas que deben ser ejecutados antes del caso de prueba, debido a la dependencia [31]
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 32
tanto no se presenta la descripción, ni las técnicas. El tercer grupo de técnicas de pruebas están
basadas en la experiencia de la persona que realiza las pruebas. En la Ilustración 12, se presenta la
clasificación de los tres grupos de técnicas.
Las técnicas de pruebas corresponden a la validación y verificación dinámica de los requerimientos,
sólo se aplican sobre el código del producto para detectar defectos y determinar atributos de calidad
del software.[26] Las técnicas de pruebas, permiten realizar: pruebas efectivas ya que permiten
encontrar más defectos y pruebas eficientes ya que encuentra los defectos en el menor tiempo
posible.
Ilustración 12. Técnicas de pruebas, adaptado de [19] , [32], [26]
Basada en la especificación (Caja negra)
Las técnicas basadas en especificación o pruebas de caja negra, no necesitan conocer la lógica
interna del sistema a probar para el desarrollo de los casos de prueba [25]. Se basan en las posibles
entradas, las salidas del sistema como resultado y la validación del resultado[23], las pruebas son
exitosas si el resultado cumple los criterios de aceptación, en caso contrario la prueba revela un
defecto (salida errónea)[34]. Quien ejecuta las pruebas se basa en que hace el software y no en el
cómo[26], tiene en cuenta las respuestas del sistema y no la trayectoria interna de cálculos y
procesamiento realizado. [34]
Basada en especificación (Caja negra)
Partición de equivalencia
Análisis de valores limites
Tabla de decisión
Grafos de causa- efecto
Transición de estados
Casos de uso
Basada en estructura
(Caja Blanca)
Pruebas de sentencia
Pruebas de decisión
Pruebas de caminos
Basadas en experiencia
Predicción de error
Pruebas Exploratorias
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 33
La IEEE define esta técnica como “un enfoque que trata a un sistema o componente cuyas entradas,
salidas y funciones en general son conocidos, pero cuyo contenido o implementación son
desconocidos o irrelevantes” [21]. En la Ilustración 13, se presenta un ejemplo sobre pruebas sobre
una calculadora, que como entrada recibe los números y las operaciones que se requieren ejecutar
sobre ellos y devuelve una salida con el resultado de la operación. [23]
Ilustración 13.Técnica de caja negra
En las siguientes subsecciones se presentan las técnicas de pruebas de acuerdo a este enfoque.
Partición de equivalencia
Como su nombre lo indica, esta técnica busca dividir las entradas o salidas del sistema en grupos de
acuerdo a un común comportamiento o por características comunes, por lo tanto se espera que sean
procesados de la misma manera,[25],[31] el resultado de la prueba para una entrada de una clase es
representativo para todas las entradas de la misma clase.[19]
Dividir las entradas o salidas, en grupos equivalentes[30],[31]. En la Ilustración 14 se
presenta ejemplo sobre la partición.
Supuesto: Si un valor da resultado esperado, el resto del grupo harán lo mismo.[19],
o por el contrario, si un valor de una partición no funciona, entonces se asume que
el resto de la partición no funcionará.[26]
La partición de equivalencia puede aplicarse en todos los niveles de pruebas.[25]
Ilustración 14. Partición de equivalencia, tomado de [31]
Por ejemplo, para el rango 0 < 𝑋 < 10
Se identifican tres particiones para realizar los casos de prueba:
• Todos los valores numéricos de entrada que se encuentren dentro de los rangos 𝑋 ≤ 0 y
𝑋 ≥ 10 son valores de entrada inválidos.
5
+
5
=
10
Calculadora
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 34
• Todos los valores numéricos de entrada que se encuentren dentro del rango 0 < 𝑋 < 10
son valores de entrada válidos.
Ilustración 15. Valores de entrada partición de equivalencia
Pressman define cuatro directrices para la definición de particiones equivalentes[28], se define una
clase de equivalencia válida y dos no validas si la condición de entrada:
1. Especifica un rango[28]
2. Requiere un valor especifico[28]
3. Especifica un miembro de un conjunto [28]
4. “Se define una clase de equivalencia y otra no valida, si la condición de entrada es
booleana”[28]
Análisis de valores limites
Esta técnica parte de la base de la técnica anterior y se centra en el análisis del valor frontera de las
particiones para identificar su valor límite, [31] de modo que para cada partición, se define un caso
de prueba que cubra el límite superior e inferior.[30]
Los valores máximos y mínimos de una partición corresponden a los valores límites.[25]
Los limites o fronteras son un buen lugar para encontrar defectos, debido que los defectos
tienen a encontrarse alrededor de ellos.[31] Es probable que se presente un error en los
valores justo fuera del rango por ser aceptados o los valores justo en el límite del rango por
ser rechazados.[26] En la Ilustración 16, se presenta un ejemplo sobre este error.
Ilustración 16. Análisis de valores limites, adaptado de [31]
Los limites válidos constituye al valor límite de las particiones válidas y limites no válidos
corresponde a valor límite de las particiones no válidas. [25],[26] Por lo tanto un valor
límite es el valor en un límite de una partición de equivalencia. [31]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 35
Las pruebas deben considerar los valores válidos, valores inválidos, valores límite válidos y
valores límite inválidos. [25] Cuando se selecciona un valor límite, se debe seleccionar el
valor límite, al menos un valor dentro del límite y otro valor fuera del límite, por lo tanto
por cada límite se seleccionan tres valores. [31] Es importante tener cuidado con el valor
fuera del límite de la partición, debido que esta puede ser el valor de la frontera de otra
clase, lo que puede estar reduciendo los valores de selección a dos: el valor límite y un
valor dentro del límite.[31]
El análisis de valores límite puede aplicarse en todos los niveles de pruebas.[25]
Con frecuencia se presentan inconvenientes en el momento de definir los valores límites de
una partición, por lo que es necesario basarse en la especificación de los requerimientos, y
como segunda instancia buscar los límites de manera indirecta u ocultos. [31]
En el ejemplo anterior para el rango 0 < 𝑋 < 10, se tienen las mismas particiones con las
fronteras: 0 y 10.
Ilustración 17. Análisis valor frontera
Se tiene los siguientes valores de pruebas:
• Valores identificados para las tres particiones: -1, 0, 1, 5, 9, 10, 11
• 0, 1, 9, 10 representan valores de prueba para el rango 0 < 𝑋 < 10, donde las fronteras
son excluidas en el rango.
• -1, 0, 10, 11 representan valores de prueba para el rango 0 < 𝑋 < 10, donde las
fronteras no son excluidas en el rango.
Tabla de decisión
Las tablas de decisión, comprende un conjunto de condiciones (entradas) y un conjunto de acciones
(salidas). Para cada conjunto de condiciones, se relaciona la entrada con las opciones “Si”, “No”, o
“No aplica” como respuesta y una lista de resultados esperados de acuerdo a las reglas
seleccionadas. [30]
Las tablas de decisión permite registrar todas las condiciones de entrada posibles junto con
todas las acciones resultantes del sistema. [26], [31]
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 36
Facilita la definición de las decisiones lógicas del sistema, debido que las tablas representan
relaciones lógicas entre las condiciones. [18], [26]
Las tablas de decisión, son muy útiles cuando se tienen reglas de negocio complejas y se
cuenta con varias condiciones de entradas que producen varias salidas.[25],[26]
Las tablas de decisión permiten determinar si los requerimientos están completos, los casos
de prueba se crean a partir de cualquier texto o documento y a menudo permiten evidenciar
ambigüedades o falencias en los requerimientos. [31]
Las combinaciones posibles de la tabla de decisión se deriva de los requerimientos,[31] se
debe analizar la especificación para identificar las condiciones y acciones del sistema.[25]
Las filas de la tabla de decisión especifican las condiciones de entrada o acciones que son
realizadas en el sistema. [35]
Las columnas de la tabla de decisión, representan los casos de prueba, especifican las
acciones que pueden ocurrir.[25],[35] Representa un conjunto único de combinaciones de
entrada.
Entrada / Acciones Prueba 1 Prueba 2 Prueba N
Entrada 1 Si No Si
Entrada 2 Si N/A No
Entrada N Si N/A Si
Salidas/Respuestas
Salida 1 Si No Si
Salida 2 Si No No
Salida N No Si N/A
Tabla 8. Tablas de decisión
En la Tabla 9 se presenta un ejemplo sobre la técnica de tablas de decisión. Las entradas
corresponden a los estados de las personas que ingresan a un sistema y las salidas corresponden a
las salidas de acuerdo a las entradas.
Entrada
/Acciones
Prueba 1 Prueba 2 Prueba 3 Prueba 4 Prueba 5
¿Mayor de edad? Si Si Si Si No
¿Empleado? Si No No Si N/A
¿Esta pensionada? Si Si No No N/A
¿Estudia en No No No No Si
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 37
colegio?
Salidas/Respuestas
Cotiza pensión. No No No Si N/A
Recibe ingresos
por pensión. Si Si N/A N/A N/A
Recibe sueldo por
trabajo. Si No N/A Si N/A
Depende
económicamente
de los padres.
N/A N/A N/A N/A Si
Tabla 9. Ejemplo tabla de decisión
Así por ejemplo se tienen las siguientes entradas para definir los casos de pruebas y las salidas o
respuestas esperadas:
• El primer caso de prueba, las entradas definen a una persona que es mayor de edad, esta
empleada, es jubilada y no es menor de edad. Por lo tanto no cotiza pensión, recibe ingresos por
pensión, recibe sueldo por trabajo y no estudia en colegio.
• El segundo caso de prueba, las entradas definen a una persona que es mayor de edad, no está
empleada, esta pensionada y no es menor de edad. Por lo tanto no cotiza pensión, recibe
ingresos por pensión, no recibe sueldo por trabajo y no estudia en un colegio.
• El quinto caso de prueba, las entradas definen a un menor de edad, que no es empleado, no está
pensionado y estudia en el colegio. Por lo tanto no cotiza pensión, no recibe ingreso de pensión,
no recibe sueldo por trabajo y depende económicamente de sus padres.
Grafos de causa- efecto
Técnica de prueba que busca representar de manera gráfica las “entradas o estímulos (causas) del
sistema con las salidas asociadas (efectos) del sistema.” [31]
El grafico es el resultado del análisis de los requerimientos[31]
Los casos de prueba se generan a partir del diagrama. [19], [31]
Es útil para los casos donde las funciones dependen de más de una entrada[31]
Las entradas y las salidas tienen que ser las declaraciones que son verdaderas o falsas.[31]
“El contenido semántico de la especificación se analiza y se transforma en un grafo de
Boole con las causas y los efectos”[19],[31], ver la Ilustración 18
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 38
𝑓(𝐸𝑠𝑡𝑎𝑑𝑜 𝑎𝑐𝑡𝑢𝑎𝑙, 𝑒𝑛𝑡𝑟𝑎𝑑𝑎) → (𝑁𝑢𝑒𝑣𝑜 𝑒𝑠𝑡𝑎𝑑𝑜, 𝑠𝑎𝑙𝑖𝑑𝑎)
𝑓(𝐸𝐴1, 𝐸𝐴2. . 𝐸𝐴𝑛, 𝐸𝐴𝑛+1, 𝐸1, 𝐸2. . 𝐸𝑛, 𝐸𝑛+1) → (𝑁𝐸1, 𝑁𝐸2. . 𝑁𝐸𝑛, 𝑁𝐸𝑛+1, 𝑆1, 𝑆2. . 𝑆𝑛, 𝑆𝑛+1)
Ilustración 18.Función grafo de causa – efecto, tomado de [31]
Para la creación de casos de pruebas es necesario:
1. Cuando un requerimiento no es atómico es difícil de manejar , por lo que se recomienda
Dividir el requerimiento en varios segmentos viables, que puedan ser representados como
causa – efecto.[19]
2. Identificar las causas y los efectos del requerimiento. A cada una de las causas y efecto se le
debe asignar un identificador único. [19],[31]
3. Para cada efecto generar una expresión booleana que exprese las causas. [31]
4. Generar el grafo, en las conexiones se incluye el tipo de combinación entre las causas y
efectos.
a. Si se presenta el operador booleano ∧ (y), significa que todas las causas deben ser
verdaderas para que el efecto sea verdadero. [31]
b. Si se presenta el operador booleano ∨ (o), significa que al menos una causa debe
ser verdadera para que el efecto sea verdadero. [31]
c. Si se presenta un ∼ , representa la negación, lo verdadero debe entenderse
como falso, y viceversa. [31]
d. Si se presenta un arco∡, significa que todas las causas se deben combinar con el
operador. [31]
5. Cuando se presenten consideraciones que no son posibles incluir en el grafo (ejemplo. Una
restricción ambiental), se debe incluir la anotación en el diagrama.[19]
6. Es posible transformar el grafo a una tabla de decisión, donde las columnas de la tabla
representan un caso de prueba. [19]
En la Ilustración 19, se presenta una representación de los grafos de causa – efecto.
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 39
Ilustración 19. Diagramas posibles de causa – efecto, tomado de [19]
Transición de estados
La técnica de transición de estados, es indicada cuando el sistema presenta estados y realiza
transiciones entre ellos de acuerdo a los eventos presentados. Se representa por medio de un
diagrama de máquina de estados finitos, donde los estados son los círculos, las transiciones son
flechas entre los estados y los eventos son un texto que se encuentra junto a la transición, [32] ver
Ilustración 20.
Ilustración 20. Transición de estados
El sistema tiene un número finito de estados, las transiciones de un estado a otro dependen
de los eventos y reglas definidas. El sistema presenta un comportamiento dependiendo de
las entradas y su estado previo. [25],[26]
La transición de estados inicia cuando se presenta un evento, el evento desencadena una
acción y el sistema cambia de estado. [31], [36]
o Transición: Estado inicial+ Evento + Acción + Estado final [31]
Útil cuando el sistema presenta diferentes salidas bajo la misma entrada.[26]
Un estado representa todas las características del sistema en un determinado momento,
“incluyendo todos los datos visibles, todos los datos almacenados, y cualquier forma actual
y campo”[31]
Los casos de pruebas deben corresponder a cada uno de sus estados y transiciones. [18]
Estado
inicial Estado
Final
Transición
Descripción del
evento
E1 S1
Si E1 entonces S1
E1 S1
Si no E1 entonces S1
E1 S1
Si E1 y E2 entonces S1
E2
E1
S1
Si E1 o E2 o E3 entonces S1
E2
E3
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 40
En la Ilustración 21, se presenta un ejemplo de transición de estados para el acceso de una cuenta a
través de una tarjeta que se ingresa a un sistema.
Ilustración 21. Transición de estados, adaptado de [32]
Una transición de la Ilustración 21, es por ejemplo:
Transición: Inicio +Inserta tarjeta + Mensaje del sistema “Por favor ingrese su clave” + Espera
Para generar los casos de pruebas a partir de los diagramas de estado, es necesario traducir el
diagrama a tablas que representen las transiciones de los estados y las condiciones que hacen que
estos cambien. Dentro la investigación se encontró dos aproximaciones:
1. En la primera columna se definen los estados del sistema y en la primera fila los eventos.
En las intersecciones de fila, columna se relacionan el estado final por la transición de la
combinación estado inicial, evento. En la Tabla 10 se representan el ejemplo de la
Ilustración 21.
Eventos
Estado inicial
Inserta
Tarjeta
Ingreso
clave
Clave
correcta
Clave
incorrecta
(S1)Inicio S2 - - -
(S2)Espera clave - S3 - -
(S3)Primer intento - - S6 S4
(S4)Segundo intento - - S6 S5
(S5)Tercer intento - - S6 S7
(S6)Acceso a la
cuenta - - - -
(S7)Bloquear tarjeta S1 - - -
Tabla 10. Transición de estados por eventos, adaptado de [32]
Inicio
Inserta
tarjeta Espera
Clave Ingreso
clave
Primer
Intento
Segundo Intento
Tercer Intento
Acceso a
la cuenta
Clave
Correcta
Clave
Correcta
Clave
Correcta
Bloquear
tarjeta
T1
T2
T3
T4
T5
T6
T7
T8
T1 = Inicio + Inserta tarjeta + Mensaje del sistema “Por favor ingrese su clave” + Espera clave
Estado inicial Evento Acción (no re presentada en la ilustración) Estado final
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 41
2. La segunda aproximación, define por cada columna de la tabla la transición, el estado
inicial, el evento, la acción y el estado final y representa cada caso de prueba. En la Tabla
11 se representa el ejemplo de la Ilustración 21.
Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6 Caso 7 Caso 8
Transi
ción T1 T2 T3 T4 T5 T6 T7 T8
Estad
o
inicial
S1 S2 S3 S3 S4 S4 S5 S5
Event
o
Inserta
tarjeta
Ingreso
de clave
Clave
incorrecta
Clave
correcta Clave
correcta
Clave
incorrecta
Clave
correcta Clave
incorrecta
Acció
n
Solicit
a clave
Recibe
clave
Solicita
clave
Mensaje
clave
correcta
Mensaje
clave
correcta
Solicita
clave
Mensaje
clave
correcta
Mensaje
clave
incorrecta
Estad
o final S2 S3 S4 S6 S6 S5 S6 S7
Tabla 11. Transición de estados por transición, adaptado de [31]
Los casos de pruebas deben identificar: el estado inicial, las entradas del sistema o eventos, los
resultados esperados (acciones) y el estado final esperado. [36]
Casos de uso
Técnica de pruebas que se basa en los casos de uso del sistema, debido a que brindan información
importante y completa del sistema, específica las funcionalidades del negocio, los escenarios, los
flujos de procesos entre el sistema y el actor, describen los usos particulares del sistema para cada
usuario u otro sistema, presenta el sistema de principio a fin. [25],[32],[26]. “Un sistema se describe
por la suma de sus casos de uso”.[35] Las ventajas de los casos de uso son:
Los casos de uso manejan lenguaje natural con términos del negocio y no un lenguaje
técnico. [32], [26] Describe las interacciones de los usuarios con el sistema de manera
secuencial. [32] ,[26]
Los casos de uso tiene precondiciones que el sistema debe cumplir antes de la ejecución y
post condiciones que indican los resultados finales del que el sistema luego de su
ejecución.[25]
Los casos de uso describen un flujo del sistema principal basado en el uso más probable y
otros flujos asociados que describen las posibles excepciones que se pueden presentar. [32]
Cada escenario de un caso de uso representa un caso de prueba.[35]
Permite asegurar el cumplimento de los requerimientos del sistema y las expectativas del
usuario.[35] Por lo tanto son una base para las pruebas de aceptación.[31]
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 42
Dentro de los casos de pruebas se deben incluir los flujos normales de los actores descritos
en los casos de uso, los flujos de las excepciones o variantes que se describan, la
información adicional suministrara información sobre el propósito de la prueba, las
precondiciones . [31]
En la Tabla 12, se presenta la descripción del caso de uso de acceso a la cuenta del ejemplo de
la Ilustración 21.
Caso de uso Acceso a la cuenta de un cliente a través de su tarjeta
Objetivo Describir el flujo de acceso a la cuenta a través de la tarjeta de un cliente
Actor Cliente tarjeta
Precondicione
s
Usuario con tarjeta activa
Cuenta sin bloqueo
Descripción
Flujo normal
No
pas
o
Actor No
paso Sistema
1 Inserta la tarjeta 2 Valida tarjeta y solicita clave
3 Ingresa la clave 4 Valida clave
5 Permite el acceso a la cuenta
Excepciones
2a Tarjeta no valida: el sistema presenta mensaje y rechaza la tarjeta
4a Clave no valida: el sistema presenta mensaje y permite realizar reintento
de clave
4b Clave invalida 3 veces: el sistema bloquea la tarjeta y no permite el
acceso.
Post
condiciones Actor accede a su cuenta
Tabla 12. Descripción caso de uso, adaptado de [32],[31]
Basadas en la experiencia
Esta técnica de pruebas, se basa en la habilidad, intuición, conocimiento, imaginación y experiencia
de la persona que ejecuta las pruebas y representan un factor decisivo en el éxito y la calidad de los
casos de pruebas derivados.[25], [26]
Aportan un valor agregado en la creación de casos de pruebas, debido que permiten identificar
casos especiales que comúnmente no son previstos mediante otros métodos, por lo tanto estas
técnicas deben ser complemento a las técnicas formales [32], a continuación se presentan las
técnicas: Predicción de error y pruebas exploratorias.
Predicción de error
Como su nombre lo indica, esta técnica busca identificar de manera anticipada los errores que se
pueden presentar en el sistema, se basan en la experiencia, en el conocimiento del sistema, en su
funcionamiento y en el conocimiento de ejecución de pruebas por parte del probador, para
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 43
identificar debilidades y posibles los defectos del sistema [32], [35]. Así como también, en el
historial de problemas presentados en versiones anteriores o sistemas similares. [35] Es importante
tener en cuenta los siguientes puntos:
No existen reglas que especifiquen como adivinar errores [32]
Los casos de pruebas se creen a partir de las situaciones identificadas como debilidades o
posibles fallas. [32]
Es importante incluir en los casos de pruebas, eventos que fueron definidos como “Eso
nunca sucede”, debido que son suposiciones que pueden generar errores. [32]
Una buena práctica, es crear una base de conocimientos de problemas presentados en el
sistema y diseñar casos que lo validen. [25], [32]
Este enfoque no solamente se puede usar para la validación dinámica del sistema, sino
también en etapas anteriores como son los requerimientos, el diseño, el desarrollo y
posteriores como operación y mantenimiento.[35]
“Estudios realizados por la IBM Corporation, indican que los mismos tipos de defectos de
software se producen con la misma frecuencia de proyecto a proyecto,.., los expertos en
pruebas de software puede predecir los tipos de defectos que se producirán en el
software.”[35]
Pruebas Exploratorias
En esta técnica de pruebas, se busca realizar pruebas del sistema sin que los casos de pruebas se
encuentren definidos de manera formal, pero se cuenta con el conocimiento del alcance de la
prueba, el enfoque de las pruebas y problemas esperados en una “carta de pruebas” que presenta
dicha información.[25],[32]
Útil cuando se cuenta con poca documentación, mala calidad de las especificaciones de los
requerimientos, “y existe una importante presión temporal”[25]
Los casos de prueba y su ejecución se realizan de manera inmediata. [32]
Las pruebas exploratorias se realiza de manera simultánea: el aprendizaje, el diseño de la
prueba y la ejecución de pruebas. [31], por lo tanto a medida que se ejecutan pruebas, se va
generando la documentación de las pruebas, se realiza el reporte de defectos y en caso de
identificar nuevos eventos, estos son incluidos. [32]
Un aspecto importante sobre esta técnica es el aprendizaje del software por parte del
ejecutor de pruebas: su uso, sus fortalezas y sus debilidades. [32]
Permite complementar otras técnicas de pruebas. [32]
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 44
Si el probador tiene experiencia podrá analizar, razonar y tomar decisiones sobre la marcha.
[31]
2. Trabajos relacionados
Los trabajos relacionados, al proceso de validación y verificación de requerimientos, se describen a
continuación en la Tabla 13. En general se encuentra que en común todos los trabajos se enfocan en
las pruebas de software como base para el desarrollo del trabajo, se diferencian su enfoque y la
perspectiva de solución, presentan la misma inquietud de aportar al proceso de calidad del
desarrollo del software.
Información trabajo relacionado Descripción
Trabajo de grado
Título: Propuesta metodológica para la
realización de pruebas de software en un
ambientes productivos
Autor: Crhistian de Jesús Cardona
Velásquez
Lugar: Medellín, Colombia
Año: 2009
El trabajo de grado, aborda los temas de pruebas de
software y aspectos importantes para definir una
metodología para ciclos de pruebas en ambientes
productivos. [37]
Propone el CICLO-P: Un método para el acoplamiento
de pruebas al ciclo de vida del software, tiene en
cuenta el proceso de pruebas desde el inicio del
proyecto mediante la planeación y listas de chequeo,
hasta la implementación y mantenimiento del producto.
[37]
Define cómo realizar pruebas de cargas en aplicaciones
web. [37]
Guía
Título: Guía de validación y verificación
Autor: Laboratorio Nacional de Calidad
del Software del Instituto Nacional de
Tecnologías de la Comunicación, S.A
(INTECO)
Lugar: España
Año: 2009
La guía de validación y verificación, presenta
información sobre:
• El proceso de validación y verificación
durante los distintos ciclos de vida
• Las actividades de validación y verificación
• Técnicas y herramientas de validación y
verificación
• Estándares de referencia.
La guía brinda información sobre la validación y
verificación, es una guía a nivel formativo, “busca
facilitar a los lectores la comprensión, adaptación y
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 45
divulgación de las disciplinas, metodologías,
estándares y normas presentes en el ámbito de la
calidad del software.”[26]
Informe de investigación
Título: Generación de pruebas de
sistema a partir de la especificación
funcional
Autor: Javier Jesús Gutiérrez
Lugar: Sevilla, España
Año: 2005
En el informe se propone el uso de las pruebas de
sistema como herramienta para verificar el
cumplimiento de la especificación funcional de un
sistema y asegurar su calidad.[38]
Expone como obtener un conjunto de pruebas de
sistema y realiza un análisis comparativo de las
propuestas existentes para la generación de casos de
pruebas. [38]
Tesis doctoral
Título: Esquema de caracterización
para la selección de técnicas de pruebas
de software
Autor: Sira Vegas Hernández
Lugar: Madrid, España
Año: 2002
Define la manera de como seleccionar adecuadamente
las técnicas de pruebas de software, realiza la
descripción de técnicas de pruebas centrándose en
“aspectos pragmáticos de las técnicas” para que la
selección sea más acertada y objetiva. [39]
Tesis de maestría en informática
Título: Proceso de Testing funcional
Independiente
Autor: Beatriz Pérez Lamancha
Lugar: Montevideo, Uruguay
Año: 2006
Define el proceso ProTest, para las pruebas funcionales
de un producto de software, independiente del proceso
seguido para su desarrollo. Basándose en las pruebas
funcionales del software, define las actividades,
artefactos y roles que se deben tener en cuenta. [40]
Guía
Título: Guía de pruebas owasp
Autor: OWASP Foundation
Año: 2008
La guía de pruebas se enfoca en los procedimientos y
herramienta para probar la seguridad de las
aplicaciones, para la verificación exhaustiva de las
seguridad en aplicaciones.[41]
Tabla 13. Trabajos relacionados
En relación a la guía metodológica V2Soft, el desarrollo de la guía tomo como base los
fundamentos teóricos para la validación y verificación de requerimientos, al igual que los trabajos
relacionados. A partir de la investigación, fue posible identificar todos los factores que influyen en
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 46
el proceso, y determinar las mejores prácticas a aplicar en el proceso, las herramientas requeridas
para que definir las fases identificadas para el proceso.
A diferencia de los trabajos relacionados y como valor agregado, la guía V2Soft, se planteó a partir
del marco de referencia “Waf –of”, ver sección 3.2 A nivel de la guía metodológica. Lo que
definió el cómo se implementar la guía a partir de: la Forma de Trabajar, la Forma de Modelar, la
Forma de Controlar y la Forma de Soportar/Apoyar, cada fase de proceso de pruebas. Teniendo así,
una guía que no solo presenta información y la manera ideal de ejecutar cada etapa, si no también
define el cómo hacerlo y como complemento presenta las siguientes herramientas de trabajo,
incluidos en los anexos, que se basan en las mejores prácticas de validación y verificación:
• Planilla SVVP (Software Verification & Validation Plan): Plantilla para el plan de
pruebas, herramienta definida para la planeación del proceso, busca que se establezcan la
información necesaria para el inicio del proceso. Esta plantilla busca ser apoyo para
presentar un plan de pruebas ante las personas interesadas del proceso. Ver [Anexo 1]
Plantilla SVVP
• Documento de riesgos: Documento para la gestión de riesgos, busca definir los riesgos
identificados en el proyecto durante el desarrollo del plan de pruebas, definir la valoración
de los riesgos y los planes de acción: plan de mitigación y de contingencia. Corresponde a
una herramienta de control. [Anexo 2] Documento de riesgos.
• Documento de casos de pruebas: Documento donde se define una plantilla para la
definición de casos de prueba. [Anexo 3] Documento de casos de prueba. Este documento
hace referencia al documento de diseño, que se especializa en la definición detalla de los
elementos del caso de prueba. [Anexo 6] Documento de Diseño. Herramienta de soporte
para el diseño.
• Documento de ejecución de casos de pruebas: Documento que permite registrar la
ejecución los casos de prueba. Se registra el resultado obtenido de la ejecución del caso de
prueba. [Anexo 4] Documento de ejecución de casos de prueba. Herramienta de soporte
para implementación y control
• Informe de avance de pruebas: Documento guía para la generación de avance de las
pruebas. Donde se incluye la información correspondiente al porcentaje de avance, reporte
de defectos, informe de los inconvenientes presentados. [Anexo 5] Informe Avance de
pruebas. Herramienta de soporte para implementación y control
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 47
• Ejemplo aplicación documento de diseño: Documentos con la definición de pruebas para
un ejemplo cotidiano, donde se desarrolla el documento de diseño. [Anexo 7] Ejemplo
aplicación documento de diseño.
3. Justificación
El proceso de la validación y verificación de los requerimientos permite asegurar el cumplimiento y
desarrollo de los requerimientos, este proceso hace parte de la ingeniería de requerimientos, que
permite encontrar, establecer, analizar, documentar, verificar y administrar los requerimientos de
software, para denotar una dirección sistemática de los requerimientos. [18], [42], [43]
Aun teniendo un buen proceso de desarrollo de requerimientos, se pueden presentar inconsistencias
en el sistema, que no fueron detectadas en etapas de la ingeniería de requerimientos. Por lo tanto, no
solo es necesario que la validación y verificación de requerimientos se realice tanto de manera
dinámica como son las pruebas de software sobre una versión ejecutable, como también estática en
los documentos y código del sistema que permitirán depurar inconsistencias del proceso.
Estudios sobre los requerimientos basados en pruebas [44] y [45], manifiestan la necesidad e
importancia del proceso de Validación y Verificación de requerimientos, debido que la causa de los
errores pueden surgir en las diferentes fuentes y sus razones [23], causando de la mala calidad de
los productos[46] y volviéndose en un factor importante y crítico, debido que “un software que no
funciona correctamente puede dar lugar a muchos problemas, incluyendo perdida de dinero, tiempo
o renombre, daños personales o incluso la muerte.”[25]
Para las empresas a las que va dirigida la guía, no solo se busca que la empresa verifique y valide el
cumplimiento de los requerimientos, si no también reducir los riesgos e impactos asociados a los
defectos del software, estudio sobre la reducción de defectos del software del año 2001[47],
estableció que:
1. Encontrar y corregir un defecto del software después de su liberación, es a menudo 100
veces más caro que encontrar y corregir el defecto durante la etapa de requerimientos y la
fase de diseño. [47] Esta medida puede variar dependiendo de la complejidad del sistema.
Actividades como: el análisis y diseño de requerimientos, involucramiento temprano, la
verificación y validación en todo el ciclo de vida del software, prototipos y simulación
permiten evitar costosas correcciones.
Permite la reducción de costos: la relación del costo por el esfuerzo requerido para dar
solución a los defectos encontrados en una determinada fase del ciclo de vida del software,
se presenta en la Tabla 14, por ejemplo si se detecta un defecto en la fase de Operación del
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 48
sistema, su corrección presentaría un costo mayor al que habría sido si se encontraba en las
fases de pruebas de sistema / integración o pruebas de aceptación.[44]
Fase donde se encuentra el defecto Porción de costo
Requerimiento 1
Diseño 3-6
Codificación 10
Pruebas de sistema / Integración 15-40
Pruebas de aceptación de usuario 30-70
Operación 40-1000
Tabla 14. Porción costo por fase. Tomado de [45]
2. Proyectos de software gastan aproximadamente 40 a 50 por ciento de su esfuerzo en re
trabajo evitable.[47]
El esfuerzo dedicado a la corrección de los defectos de software que podrían haber sido
descubiertos, corregidos o evitado por completo en etapas tempranas a un menor costo.
3. Alrededor del 80 por ciento de re trabajo evitable proviene del 20 por ciento de los
defectos.[47]
Dos de las principales fuentes de re trabajo se originan por:
• Requisitos especificados apresuradamente
• Definición tardía de requisitos no nominales causan el mayor re trabajo en diseño,
arquitectura, y en el código.
4. Alrededor del 80 por ciento de los defectos provienen del 20 por ciento de los módulos, y
aproximadamente la mitad de los módulos son defectos.[47]
Casi todos los defectos se agrupan en la mitad de los módulos. El reconocimiento de las
características de los módulos propensos a errores en un entorno particular puede resultar
útil.
5. Acerca del 90% del tiempo de inactividad viene en su mayoría del 10 por ciento de los
defectos.[47]
Algunos defectos afectan de manera desproporcionada el tiempo de inactividad y la
fiabilidad de un sistema. [47]
6. La revisión de pares capturan el 60 por ciento de los defectos. [47]. Estudios presentan que
la revisión de pares ofrece una técnica efectiva debido que permite encontrar entre el 31 y el
93 por ciento de los defectos, con una mediana de alrededor de 60 por ciento.[47]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 49
Con el marco teórico del trabajo de grado, se definieron las bases y fundamentos para el desarrollo
de la guía, pero mediante la guía se definió como se debe implementar la teoría en la práctica, como
se debe trabajar, controlar, modelar, soportar, que se debe considerar y que recomendaciones
existen para llevar a cabo el proceso.
Es claro que en el marco teórico o estado del arte, se definieron las bases para el proceso, se
encuentra la técnicas e información que permite mejorar la ejecución de las pruebas, pero no se
define el cómo se debe implementar.
A diferencia, la guía busca definir cómo implementar el proceso de validación y verificación de los
requerimientos, de tal manera que la empresa que tome como base la guía, sepa cómo debe llevar a
cabo las actividades. En la Ilustración 22, se presenta las fortalezas de la guía respecto al estado del
arte o marco teórico.
Ilustración 22. Guía versus estado del arte
GuíaEstado del
arte
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado
Página 50
4. Descripción de la Solución
Para el desarrollo de la guía, fue necesario el estudio de procesos de pruebas con el fin de
determinar el más adecuado para resolver la problemática. Dentro de los puntos identificados, se
encontró que los procesos de pruebas se debían adaptar a un modelo de ciclo de vida del software,
debido que permite definir claramente cuando se deben ejecutar los subprocesos y actividades del
proceso de pruebas.
Por lo tanto lo primero que se identificó fue el modelo de ciclo de vida que se iba a desarrollar en la
guía y el proceso de pruebas con el que se basara la guía. Luego se realizó la identificación de las
actividades del proceso dentro del ciclo de vida del software, para así determinar su momento de
ejecución. A continuación se describe el proceso realizado para llegar al desarrollo de la solución
del problema.
1.1 Validación y verificación de requerimientos en el ciclo de vida
Para realizar la validación y verificación de los requerimientos a lo largo de todo el ciclo de vida del
software, se requiere que la planificación del proceso comience en las etapas tempranas del proceso
de desarrollo, con la ayuda de los modelos de ciclo de vida. Se seleccionó el “Modelo en V”,
debido que permite que el proceso de validación y verificación se realice de manera temprana desde
el inicio del ciclo de vida del software y permite la ejecución de actividades de manera paralela al
desarrollo del sistema [26] y presenta las siguientes características:
• El proceso de validación y verificación de los requerimientos, las actividades no solo se
basan en la ejecución, la validación se inicia con la revisión de la especificación de los
requerimientos de usuario y finaliza con las pruebas de aceptación de usuario. [26]
• El lado izquierdo del modelo, representa el proceso que permite el desarrollo del sistema y
el lado derecho, presenta los niveles de pruebas que permiten asegurar la calidad del
sistema. [48]
• La planificación y especificación de las pruebas se recomiendan iniciar, cuando los
requerimientos se encuentran avanzados. [48]
• El Modelo en V presenta los diferentes niveles de pruebas y especifica el momento en el
que se debe realizar la planificación y su ejecución. [25]
• Dentro de las ventajas que presenta este modelo se encuentran:
1. Mayor tiempo para planificar y especificar la prueba. [48]
2. Permite la revisión de documentos y del código del sistema. [48]
3. Mayor tiempo para realizar la configuración del ambiente de pruebas. [48]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 51
4. Mayor oportunidad de estar listos para el momento de ejecución de pruebas. [48]
En la Ilustración 23, se presentan el modelo V, donde se encuentran las actividades de validación y
verificación.
Ilustración 23. Actividades de validación y verificación en el modelo en V, tomado [26]
1.2 Proceso de prueba:
La guía metodológica para la Validación y Verificación de requerimientos, tomo como base el
proceso de pruebas definido por el “International Software Testing Qualifications Board” ISTQB,
teniendo en cuenta las actividades que corresponden a la etapa de usuario final, es decir la
Validación y Verificación de se realizan sobre la ejecución del sistema, proceso presentado en la
Ilustración 24.
Ilustración 24. Proceso ISTQB
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 52
1.3 Adaptación del modelo en V, a la problemática a resolver
Para adaptar el modelo en V a la guía, fue necesario clasificar las actividades del modelo
presentado anteriormente, de acuerdo a los responsables de la ejecución de la actividad y asignarles
un color que permitan diferenciarse del resto en el diagrama del modelo:
- A las actividades que pertenecen al equipo responsable de la Validación y Verificación de
requerimientos, se les asigno el borde de color verde.
- El borde de color azul fue asignado a actividades que son de la empresa que busca la
tercerización pero que no corresponden a actividades de Validación y Verificación.
- A las tareas cuyos responsables son el equipo de desarrollo (empresa tercera) se les asigno
color naranja.
- Se evidencio una tarea que debe ser realizada tanto por el equipo responsable de la
Validación y Verificación de requerimientos como el equipo de desarrollo, a esta tarea se
les asigno el color morado.
En la Ilustración 25 se presenta la relación de los colores de las actividades del modelo con
los responsables de la ejecución.
Ilustración 25. Relación de colores de las actividades del modelo en V
Por lo que se realizó la adaptación del modelo en v de acuerdo a la adaptación de los colores, en la
Ilustración 26, se presenta el modelo V, con el color definido para las actividades de acuerdo a los
responsables.
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 53
Ilustración 26. Modelo en V para la guía, adaptado de [26]
1.4 Identificación de actividades de acuerdo al modelo en V y al proceso de pruebas.
En el modelo en V, las actividades del proceso de pruebas no son explicitas y es necesario adaptar
el proceso con el modelo, el proceso de pruebas se considera parte de la totalidad del ciclo de vida
de desarrollo de software, por lo tanto debe estar alineado el proceso con el modelo de ciclo de vida
en V. [49]
Las actividades del proceso de pruebas y el modelo en v, pueden alinearse de la siguiente manera:
- La planeación de las pruebas es simultánea a la planificación del proyecto. [49]
- El control debe existir durante todo el modelo del ciclo de vida hasta la actividad de cierre.
[49]
- El análisis y diseño de las pruebas concurren con la especificación de los requerimientos, la
especificación del diseño de alto y bajo nivel. [49]
- La implementación del entorno de pruebas puede iniciarse durante el diseño del sistema,
aunque algunas veces esta actividad se realiza días antes de la ejecución de pruebas. [49]
- La ejecución de pruebas de sistema se realizan cuando se cumplen los criterios de entrada
de las pruebas de sistema, en el caso de la guía se deben iniciar cuando se hayan finalizado
las pruebas unitarias y de integración de componentes. [49] Y deben realizarse hasta que se
cumplan los criterios de aceptación definidos.
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 54
- La evaluación de criterios de salida y la elaboración de informes sobre los resultados de las
pruebas, se deben realizar a lo largo de la ejecución de las pruebas. [49]
- Las actividades de cierre, se realizan cuando se cumplan con todos los criterios de salida de
las pruebas y se han completado las ejecuciones de las diferentes pruebas. [49]
El proceso de pruebas debe poderse modificar en función del contexto del proyecto y estar
conforme al ciclo de vida de desarrollo. En la Ilustración 27, se presenta el modelo en V y las
actividades del proceso de pruebas. En este modelo se mantiene únicamente las actividades de las
que es responsable el equipo de validación y verificación de requerimientos de la empresa a la que
va dirigida la guía.
Ilustración 27. Actividades modelo en V de acuerdo al proceso ISTQB, adaptado de [26]
El proceso de pruebas adaptado al modelo en v, se presenta en la Ilustración 28 y en la Ilustración
29 el subproceso de pruebas.
Por lo tanto el proceso de pruebas definido para inicia por la planeación y de manera paralela se
ejecutan los subprocesos de pruebas y de control. Para las actividades de control se definió a partir
del estándar IEEE 29119-1. [50]
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 55
Ilustración 28. Proceso de pruebas, adaptado del modelo en V
Ilustración 29. Subproceso pruebas
El control se realiza de manera paralela a las pruebas y es un sub proceso que contiene diferentes
actividades.
Ilustración 30. Subproceso control, adaptado de [50]
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 56
1.5 Definición de las actividades del proceso – Desarrollo de la guía y “Way –Of”
Para la definición de las actividades de cada proceso definido y como se comentó en la sección 3.2
A nivel de la guía metodológica, se siguió el modelo “Way –of”. Para el desarrollo de la guía se tomó
como referencia, la descripción de cada actividad identificada en el proceso de pruebas, mediante
el uso de la Tabla 15.
Ítem Definición
Actividad Nombre de la actividad
Descripción Descripción de la actividad
Entradas Incluye las entradas que son requeridas para la ejecución de la actividad
Participante Rol del equipo de pruebas que participa en la actividad
Forma de trabajar Forma de trabajar de la actividad
Forma de soportar Forma de soportar la actividad
Forma de Modelar Forma de modelar la actividad
Forma de controlar Forma de controlar la actividad
Salidas Presenta los artefactos resultantes de la actividad
Tabla 15. Descripción de las actividades
Adicional se incluirán consideraciones y recomendaciones que sean pertinentes y que se deben
tener en cuenta para la ejecución de la actividad, mediante el modelo de la Ilustración 31.
Ilustración 31. Consideraciones y recomendaciones para actividad
Consideraciones
Consideración 2
Consideración 1
Recomendaciones
Recomendación 1
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado
Página 57
1.6 Supuestos y restricciones de la guía
La guía metodológica debe iniciar su aplicación, cuando se cuenta con los requerimientos definidos
y sin ambigüedades, para que exista un involucramiento temprano por parte del equipo de pruebas,
para que conozcan el sistema, y se realice de manera anticipada la actividad de planeación del
proceso, debido que no requiere la ejecución del software, permitiendo que estén preparados para el
inicio de las pruebas cuando el sistema esté listo.
Supuestos:
• Se cuenta con la información necesaria para la creación de los casos de prueba.
• Los documentos entregados para el proceso no presentan inconsistencias y son completos.
• Las pruebas basadas en la estructura son ejecutadas por el equipo responsable de la empresa
que realiza el desarrollo y las realizan antes de entregar el sistema.
Restricciones:
• La guía no se debe aplicar, cuando se realizan pruebas técnicas o pruebas no funcionales,
por lo que deben estar a cargo de expertos junto a herramientas que permitan su ejecución.
Las pruebas identificadas, con las que no se debe usar la guía son:
o Recuperación
o Seguridad
o Resistencia
o Desempeño
o Rendimiento
o Carga
o Stress
o Portabilidad
o Fiabilidad
o Mantenibilidad
o Usabilidad
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado
Página 58
5. Validación
Para la validación de la guía metodológica, se determinó en los objetivos que se realizaría a partir
de la evaluación de expertos, debido que para aplicarla dentro de un proyecto de software, tiempo
para la validación de la guía dentro de un proyecto se requiere mucho más tiempo que el definido
para el trabajo de grado, ya que se necesitaría realizar actividades desde la planeación y el cierre
del proceso. Se encontró que la manera más óptima para su evaluación fue la validación por
expertos.
Para determinar los aspectos a tener en cuenta para la evaluación, se realizó en primera instancia
una encuesta a una organización que presenta el esquema de trabajo a la que va dirigida la guía, con
el fin de identificar las necesidades para el proceso de validación y verificación de requerimientos.
Luego del análisis de los resultados obtenidos en la encuesta, se determinaron requerimientos, que
fueron los puntos de evaluación y controles para la validación de guía, presentados a continuación
en la Tabla 16
Id Necesidad R01
Necesidad identificada Definición de roles del proceso de pruebas de software.
Id Necesidad R02
Necesidad identificada Definición de funciones y responsabilidades de los roles
que se definan en R01.
Id Necesidad R03
Necesidad identificada Definición de la planificación de las pruebas de software.
Id Necesidad R04
Necesidad identificada Definición de proceso para la estimación de tiempos de
pruebas de software.
Id Necesidad R05
Necesidad identificada Definición de proceso para determinar casos pruebas de
software.
Id Necesidad R06
Necesidad identificada Definición de proceso para priorizar los casos pruebas de
software.
Id Necesidad R07
Necesidad identificada Definición de métricas para evaluar la calidad proceso de
pruebas.
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 59
Tabla 16. Requerimientos identificados
• La evaluación de la guía se organizó en dos tipos de preguntas.
- El primer grupo presentaba preguntas de selección, que buscaba medir el
cubrimiento de los requerimientos de la Tabla 16 en la guía con las siguientes
opciones: “Totalmente cubierta”, “Parcialmente cubierta” y “No está cubierto”.
- El segundo grupo de preguntas, eran de selección donde la persona que realizaba la
evaluación contestaba entre las opciones “sí” o “no”. Las preguntas pretenden
medir el grado de aceptación de la guía.
Enunciado Respuesta
¿Considera que la guía es completa? Si No
¿Considera que la guía es clara? Si No
¿Considera que la guía se puede adaptar a una
organización que presente el modelo de empresa? Si No
¿Considera que la implementación de la guía es viable? Si No
¿Considera que la guía es servible? Si No
¿La información que se presenta en el marco teórico de la
guía es suficiente para el entendimiento del proceso? Si No
¿Considera que a la guía le hace falta información? Si No
¿Cree que la guía aporta al proceso de pruebas? Si No
Tabla 17. Preguntas aceptación guía
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado
Página 60
6. Validación y Resultados
1.1 Primera evaluación – Guía metodológica semestre 2014
• La guía fue evaluada por tres expertos en la Validación y Verificación de requerimientos.
• Dos de las personas que realizaron la evaluación, pertenecían a la organización en la que se realizó la encuesta para el levantamiento de las
necesidades.
• La tercera persona, es un ingeniero de sistemas encargado de realizar automatización de pruebas de software.
Resultados obtenidos
A continuación se presentan los resultados obtenidos en la pregunta número uno.
Id
Nece
sida
d
Necesidad
identificada
Evaluador 1 (técnico Andrés
Perdomo)
Evaluador 2 (técnico Guillermo
Castellanos)
Evaluador 3 ( Experto en
automatización de pruebas Ing.
William Ceballos)
Totalment
e cubierta
Parcialment
e cubierta
No está
cubierto
Totalment
e cubierta
Parcialmen
te cubierta
No está
cubierto
Totalment
e cubierta
Parcialme
nte
cubierta
No está
cubierto
R01
Definición de roles
del proceso de
pruebas de software.
X X X
R02
Definición de
funciones y
responsabilidades de
los roles que se
X X X
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 61
definan en R01.
R03
Definición de la
planificación de las
pruebas de software.
X X X
R04
Definición de proceso
para la estimación de
tiempos de pruebas
de software.
X X X
R05
Definición para
determinar casos
pruebas de software.
X X X
R06
Proceso para priorizar
los casos pruebas de
software.
X X X
R07
Definición de
métricas para evaluar
la calidad proceso de
pruebas.
X X X
Tabla 18. Evaluación de la Guía pregunta 1
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 62
Evaluación de la pregunta dos A continuación se presentan los resultados obtenidos en la pregunta número uno.
Códig
o Enunciado
Evaluador 1 (técnico) Evaluador 2 (técnico)
Evaluador 3 ( Experto
automatización de
pruebas)
Respuesta Respuesta Respuesta
C01 ¿Considera que la guía se completa? Si No Si No Si No
C02 ¿Considera que la guía es clara? Si No Si No Si No
C03 ¿Considera que la guía se puede adaptar a una
organización que presente el modelo de
empresa?
Si No Si No Si No
C04 ¿Considera que la implementación de la guía es
viable? Si No Si No Si No
C05 ¿Considera que la guía es servible? Si No Si No Si No
C06 ¿La información que se presenta en el marco
teórico de la guía es suficiente para el
entendimiento del proceso?
Si No Si No Si No
C07 ¿Considera que a la guía le hace falta
información? Si No Si No Si No
C08 ¿Cree que la guía aporta al proceso de pruebas? Si No Si No Si No
Tabla 19. Evaluación guía pregunta dos
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 63
Comentarios de la guía
Ítem considerado Evaluador 1 (técnico Andrés
Perdomo)
Evaluador 2 (técnico Guillermo
Castellanos)
Evaluador 3 ( Experto
automatización de pruebas)
Comentarios
Se deben hacer más
especificaciones dentro del marco
de aprobación del software y los
posibles incidentes que se presenten
dentro del paso a producción, ya
que es de vital importancia
contemplar los peores casos para
que sean esos peores casos quienes
determinen el tiempo total del
proyecto.
Ninguno
De pronto la forma de solucionar los
diferentes tipos de trabas o
inconvenientes que el tester
encuentre en el desarrollo de un plan
de pruebas.
Recomendaciones
Por otro lado sería interesante y
muy práctico a la guía que la tabla
de contenido este referenciada a las
páginas que indica y que al dar
click sobre el tema se pueda dirigir
de una vez y no usar el
desplazamiento que ofrece el
software de ofimática.
Ninguna Ninguna
Tabla 20. Comentarios a la guía
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado
Página 64
En relación del primer grupo de preguntas, se evidencia que la única pregunta concluyente donde
los tres evaluadores opinaron igual fue la pregunta sobre los roles del proceso de software. Las
demás presentas difieren entre totalmente cubierta la necesidad y en parcialmente cubierta.
Se recibe un punto negativo donde se considera que la necesidad sobre la estimación de tiempos no
está cubierta en la guía, en la sección 5.2.2 Herramientas para la planeación, se incluyó una
descripción detallada sobre el proceso de estimación de tiempos, técnicas existentes y se enfocó en
la metodología de puntos funcionales, lo que significa que la necesidad si se encuentra cubierta.
A continuación en la Tabla 21, se presenta la información de la evaluación de la guía.
Id
Necesida
d
Necesidad identificada Totalmente
cubierta
Parcialme
nte
cubierta
No está
cubierto
R01 Definición de roles del proceso
de pruebas de software. 3
R02
Definición de funciones y
responsabilidades de los roles
que se definan en R01.
2 1
R03 Definición de la planificación
de las pruebas de software. 1 2
R04
Definición de proceso para la
estimación de tiempos de
pruebas de software.
1 1 1
R05 Definición para determinar
casos pruebas de software. 2 1
R06 Proceso para priorizar los casos
pruebas de software. 1 2
R07
Definición de métricas para
evaluar la calidad proceso de
pruebas.
2 1
Tabla 21. Evaluación necesidades
En cuanto a la pregunta dos de selección, se evidencio una unificación en las respuestas, de las ocho
preguntas realizadas, siete fueron contestadas afirmativamente y la pregunta en donde dos personas
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 65
contestaron que no, fue una respuesta positiva debido a que la pregunta hacía referencia si
consideraba que a la guía le hacía falta información.
En la Tabla 22, se presenta la información cuantificada respecto a la pregunta dos.
Enunciado Respuesta
SI NO
¿Considera que la guía se completa? 3
¿Considera que la guía es clara? 3
¿Considera que la guía se puede adaptar a una
organización que presente el modelo de empresa? 3
¿Considera que la implementación de la guía es
viable? 3
¿Considera que la guía es servible? 3
¿La información que se presenta en el marco teórico
de la guía es suficiente para el entendimiento del
proceso?
3
¿Considera que a la guía le hace falta información? 1 2
¿Cree que la guía aporta al proceso de pruebas? 3
Tabla 22. Evaluación necesidades selección
En los comentarios y recomendaciones
Se reciben dos comentarios, el primero corresponde a los posibles incidentes que se pueden
presentar en la marcha del producto y el segundo sobre las posibles soluciones a los
inconvenientes con los que se encuentran a diario los testers.
o Los incidentes en que se generan a partir de la liberación del producto, no son
cubiertos en la guía. Debido que se considera que un buen análisis y desarrollo de
casos de pruebas a partir de las técnicas propuestas, identifican de manera más
efectiva los defectos, protegiendo al sistema de posibles fallas en producción, pero
siempre recordando que las pruebas exhaustivas no son posibles, por lo tanto el
sistema no se está exento de tener errores.
o En la guía no se establecieron posibles soluciones, debido que la idea era evitar los
inconvenientes a partir de una buena gestión y desarrollo del proceso de pruebas de
software. Y a su vez se realizaron recomendaciones en cada uno de las actividades
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 66
del proceso. Se considera que este punto se puede fortalecer pero teniendo en
cuenta los problemas de manera puntual.
El único comentario recibido corresponde al índice de la guía y sus referencias, se realizó la
validación del documento y se evidencio que cada título del índice hace la referencia de
manera correcta al título del documento, se considera que el comentario no aplica y no fue
necesario realizar una corrección.
1.2 Segunda evaluación – Guía metodológica semestre 2015
La segunda evaluación, hace parte de la etapa dos del trabajo de grado, la guía metodología
presentada en la primera evaluación se complementó a partir de la evaluación obtenida y
documentada en la sección anterior y los puntos identificados para mejorar.
Se realizó una segunda evaluación, con los tres primeros evaluadores y una persona experta en la
validación y verificación de requerimientos.
Nombre experto: Mauricio Chávez López
Con los siguientes niveles de estudio:
Ingeniero de sistemas graduado en 2011 de la Fundación Universitaria San Martin
Curso Alta Madurez CMMI
Fedesoft – Bogotá 2012
Introducción CMMI desarrollo versión 1.3
Fedesoft – Bogotá 2012
Certified Tester Foundation Level
ISTQB – Bogotá 2011
Capacitation – TSP Team Member Training
Fedesoft – Bogotá 2011
Auditor interno de calidad ISO 9001:20
Kirtoma – Bogotá 2011
Diplomado gerencia de proyectos
Fundación Universitaria San Martín – Bogotá 2011
- Con 6 años de experiencia en el área de calidad de software orientado siempre a pruebas de
software bancario (diferentes entidades financieras)
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado
Página 67
Evaluación de la pregunta uno
A continuación se presentan los resultados obtenidos en la pregunta número uno, en la segunda evaluación, realizada con las mejoras a la guía
metodológica.
A continuación se presentan los resultados obtenidos en la pregunta número uno.
Id
Necesida
d
Necesidad
identificada
Evaluador 1 (técnico Andrés
Perdomo)
Evaluador 2 (técnico Guillermo
Castellanos)
Evaluador 3 ( Experto en
automatización de pruebas Ing.
William Ceballos)
Totalment
e cubierta
Parcialmen
te cubierta
No está
cubiert
o
Totalment
e cubierta
Parcialmen
te cubierta
No está
cubiert
o
Totalment
e cubierta
Parcialmen
te cubierta
No está
cubiert
o
R01
Definición de
roles del
proceso de
pruebas de
software.
X X X
R02
Definición de
funciones y
responsabilidad
es de los roles
que se definan
en R01.
X X X
R03
Definición de la
planificación de
las pruebas de
software.
X X X
R04
Definición de
proceso para la
estimación de
tiempos de
pruebas de
software.
X X X
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 68
R05
Definición para
determinar
casos pruebas
de software.
X X X
R06
Proceso para
priorizar los
casos pruebas
de software.
X X X
R07
Definición de
métricas para
evaluar la
calidad proceso
de pruebas.
X X X
Tabla 23. Evaluación de la Guía pregunta 1, segunda evaluación
Evaluación de la pregunta dos
A continuación se presentan los resultados obtenidos en la pregunta número uno.
Códig
o Enunciado
Evaluador 1 (técnico) Evaluador 2 (técnico)
Evaluador 3 ( Experto
automatización de
pruebas)
Respuesta Respuesta Respuesta
C01 ¿Considera que la guía se completa? Si No Si No Si No
C02 ¿Considera que la guía es clara? Si No Si No Si No
C03 ¿Considera que la guía se puede adaptar a una
organización que presente el modelo de
empresa?
Si No Si No Si No
C04 ¿Considera que la implementación de la guía es
viable? Si No Si No Si No
C05 ¿Considera que la guía es servible? Si No Si No Si No
C06 ¿La información que se presenta en el marco
teórico de la guía es suficiente para el
entendimiento del proceso?
Si No Si No Si No
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 69
C07 ¿Considera que a la guía le hace falta
información? Si No Si No Si No
C08 ¿Cree que la guía aporta al proceso de pruebas? Si No Si No Si No
Tabla 24. Evaluación guía pregunta dos
Comentarios sobre la guía
Ítem considerado
Evaluador 1 (técnico) Evaluador 2 (técnico)
Evaluador 3 ( Experto
automatización de
pruebas)
Comentarios /
Recomendaciones
En los roles sería bueno tener un poco
más de definición general frente al
cargo de los jefes ya que en todas las
organizaciones no se cuenta con un
jefe en particular sino que pueden
presentar gerentes o figuras mixtas que
no son 100% dedicables al esquema de
pruebas.
Ninguno
Básicamente corregir
algunos temas de redacción
para dar mayor claridad a la
explicación de los temas
tratados.
Opinión sobre la guía
La Guía presenta una estructura clara y
formal frente a los procesos a
desarrollar con la implementación del
tema
Considero que es una guía útil para
ser aplicada. Quizá al principio sea
complicado, por el cambio de
metodología, pero es un cambio
que beneficiara el trabajo que
actualmente se realiza en la
organización.
Considero que la guía
contempla los temas
relevantes a tener en cuenta
en un proceso de elaboración
y ejecución de pruebas de
software, por lo tanto le veo
un buen grado de
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 70
Se tratan temas que normalmente
no se tienen en cuenta en el
momento del proceso de pruebas.
maduración para ser
implementado en una
empresa que cumpla con el
modelo.
Tabla 25. Comentarios de a la guía Evaluación 2
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado
Página 71
Evaluación experto 4
Evaluación de la pregunta uno
Id
Necesida
d
Necesidad identificada Evaluador Mauricio Chávez
Totalmente
cubierta
Parcialment
e cubierta
No está
cubiert
o
R01 Definición de roles del proceso de pruebas
de software.
X
R02 Definición de funciones y responsabilidades
de los roles que se definan en R01.
X
R03 Definición de la planificación de las pruebas
de software.
X
R04 Definición de proceso para la estimación de
tiempos de pruebas de software.
X
R05 Definición para determinar casos pruebas de
software.
X
R06 Proceso para priorizar los casos pruebas de
software.
X
R07 Definición de métricas para evaluar la
calidad proceso de pruebas.
X
Tabla 26. Evaluación guía pregunta uno, cuarto experto
Evaluación de la pregunta dos
Código Enunciado Evaluador
Respuesta
C01 ¿Considera que la guía se completa? Si No
C02 ¿Considera que la guía es clara? Si No
C03 ¿Considera que la guía se puede adaptar a
una organización que presente el modelo de
empresa?
Si No
C04 ¿Considera que la implementación de la guía
es viable? Si No
C05 ¿Considera que la guía es servible? Si No
C06 ¿La información que se presenta en el marco Si No
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 72
teórico de la guía es suficiente para el
entendimiento del proceso?
C07 ¿Considera que a la guía le hace falta
información? Si No
C08 ¿Cree que la guía aporta al proceso de
pruebas? Si No
Tabla 27. Evaluación guía pregunta dos, cuarto experto
Comentarios sobre la guía
Ítem considerado Evaluador
Comentarios /
Recomendaciones
Ya que la guía está orientada a un proceso de pruebas y revisión de
requerimientos muy específicos, se considera apropiado detallar el perfil
profesional (conocimientos básicos) de las personas que ejercerían las
diferentes funciones mencionadas en la guía esto como referencia para las
empresas interesadas en las metodologías descritas en el documento.
Cabe anotar que como guía los pasos y definiciones a implementar en un
proceso como al que está orientada la guía, dependerá del tipo de proyecto
y de los diferentes acuerdos a los que se llegue con el cliente, esto dado
por ejemplo, cada entidad tienen intereses variados en cuanto a velocidad,
seguridad, rendimiento, etc de la solución que se desea desarrollar y la
variación de los requerimientos analizados que podrían generar controles
de cambio y variaciones en el sistema.
Opinión sobre la
guía
Los procesos de verificación de las diferentes funcionalidades de una
solución pueden ser complejos, sin un plan de trabajo detallado es
imposible llegar a cumplir con tiempos de respuesta ni los cronogramas
acordados con los clientes, por lo general las áreas de calidad son las que
tienen una mayor carga o presión en cuanto a la liberación de versiones,
por esto se considera que la guía es una buena base para las diferentes
compañías que ejercen este tipo de actividad ya que detalla de forma
completa cada una de las fases del proceso y el personal involucrado en
las mismas, generando que el impacto en cuanto a tiempo perdido en las
áreas de desarrollo y calidad sea mínimo ya que se involucra la parte de
completitud de requerimientos y de esta manera se garantiza que durante
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 73
la ejecución de las pruebas exista menos probabilidad de encontrar
inconsistencias en cuanto a la integración de los diferentes servicios que
componen un sistema.
Tabla 28. Comentarios de a la guía Evaluación 2, cuarto experto
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado
Página 74
7. Análisis de Impacto
La guía metodológica apoya a las empresas que tercerizan el desarrollo de software, en el proceso
de garantía de calidad del sistema, mejorando las actividades de Validación y Verificación de
requerimientos que son realizadas por la organización respectiva.
Se espera que con el tiempo, las actividades de la organización se realicen de acuerdo a la guía, las
cuales a su inicio de la implementación no debe interrumpir la ejecución de las actividades que
comúnmente se realizan para las pruebas, sino que paulatinamente se deben ir adaptando, lo que
impactará en tiempo de aprendizaje hasta que se implemente toda la guía. El tiempo usado en esta
actividad será compensado al disminuir el esfuerzo en el proceso de planeación, debido a que se
establece un hilo conductor de las actividades a realizar.
A nivel académico se espera que esta guía sea analizada y estudiada en la formación de los
estudiantes, para que mediante esta investigación ellos se concienticen de la importancia de la
Validación y Verificación de requerimientos.
A nivel de Empresas, impacto en la disminución de riesgos por defectos de mala calidad del
software y sus impactos asociados.
A nivel general el conocimiento de porque la calidad del software es necesaria y como su proceso
de desarrollo es fundamental en el ciclo de vida del software.
Por último impacto en lo económico y en el tiempo de la realización de las actividades porque un
software cuyo funcionamiento es deficiente ocasiona muchos males incluyendo la perdida de
dinero, tiempo y ocasiona inseguridad de las acciones que se estén llevando a cabo.
8. Conclusiones
• Se evidencia la necesidad de la implementación de la guía en áreas que realizan la
validación y verificación de requerimientos, teniendo en cuenta el estudio realizado con la
encuesta, donde se evidencio que no se tienen modelos establecidos para llevar a cabo el
proceso. Uno de los factores importantes y de gran éxito es que el personal conozca la
importancia del proceso y se encuentre capacitado para que implemente las técnicas
investigadas que soportan todo el proceso.
• El integrar varias metodologías ya aprobadas, con un nivel de madurez alto, en el proceso
de validación y verificación de requerimientos, permiten disminuir los riesgos de
implementación y puesta en producción de los nuevos sistemas de una empresa.
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 75
• V2Soft como guía metodológica soporta las necesidades de validación y verificación de
requerimientos y establece la manera de cómo implementar el proceso soportado por el
marco de referencia “Way of” que facilita su comprensión y realización, permitiendo ser
una de las ventajas frente a otros trabajos relacionados.
• La validación y verificación de requerimientos para una empresa que terceriza el desarrollo,
es muy importante, no solo le permite conocer si se cumplen con los requerimientos y las
expectativas, si no también disminuir los problemas relacionados a los defectos del
desarrollo, si bien la empresa de desarrollo debe realizar sus propias validaciones, son los
expertos del negocio los que conocen el propósito del sistema y pueden enfocar con mayor
precisión y efectividad el proceso.
• La evaluación de una guía dependerá del tiempo que se tenga dispuesto para el trabajo de
grado, con el método seleccionado para la evaluación, se tiene dependencia del criterio del
experto hacia la guía y pueda que en el momento de responder las preguntas no tenga
presente un aspecto de la guía que si se encuentra incluido.
• La ejecución de encuestas a integrantes del área de validación y verificación de
requerimientos en una organización, permitió determinar puntos a incluir en la guía porque
presentaba los problemas que se enfrentan a diario y los puntos a considerar para la
evaluación.
• Es muy importante el tipo de preguntas que se realizan en una encuesta, el uso de preguntas
de selección facilitan las respuestas a los encuestados, pero a través de preguntas abiertas
se puede conocer que tan acertadas fueron las preguntas de selección.
Trabajos futuros
A continuación se presentan los trabajos futuros identificados, que buscan fortalecer el proceso de
validación y verificación de requerimientos.
• Existe un amplio camino en cuanto a la validación y verificación de requerimientos, dentro
de los trabajos futuros se considera que se puede contemplar la validación y verificación
estática de los requerimientos y los métodos formales.
Son técnicas que tienen el mismo fin, garantizar la calidad del producto o sistema, pero se
enfocan en diferentes etapas del ciclo de vida del software, que no siempre son
contemplados o se obvian en el proceso, pero que pueden apoyar en la definición del
sistema y su entendimiento.
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 76
En la Ilustración 32, se presentan las ramas de investigación para profundizar en los futuros
trabajos.
Ilustración 32. Validación y verificación en etapas de ciclo de vida del software, tomado de [24]
Dentro de la investigación realizada, se encontró fuentes de información sobre las
definiciones de estas técnicas presentadas en la Ilustración 32, pero su implementación se
vuelven algo abstractas y abiertas a la imaginación de la persona que realice el proceso.
Los métodos formales, requiere la especificación de un modelo en lenguaje formal y el uso
de sus propiedades, para asegurar que las declaraciones del sistema hacen parte del lenguaje
del modelo o se puede producir a partir de él.[51] Permite realizar un “análisis matemático
de la especificación, de transformar la especificación a una representación más detallada
semánticamente equivalente; o de verificar formalmente que una representación del sistema
es semánticamente equivalente a otra representación.” [4]
• Establecer una metodología para la validación y verificación de requerimientos a nivel de
caja blanca o a nivel de estructura del código, que permita garantizar la calidad del software
desde el proceso de desarrollo.
La metodología, se enfocaría en la definición de métodos para realizar la validación y
verificación del sistema en la estructura interna de los componentes del sistema, por lo que
el orientación va a la manera como se implementa el sistema y la lógica de las funciones
Validación y Verificación
Métodos Formales
Comprobación del modelo
Pruebas de corrección o
exactitud
Pruebas Pruebas Estaticas
Inspecciones
Revisiones
Modelos de Verificación
Análisis Estático
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 77
que lleva a cabo, para cubrir los caminos del programa.[19], [35], [52] Por lo tanto el
contenido interno de la aplicación debe ser conocido [31].
Los casos de prueba se basan en la implementación del sistema, permitiendo que:
Se valide que se recorre al menos una vez los caminos independientes de cada
módulo.[23], [44]
Se valide todas las decisiones lógicas tanto verdaderas como falsas. .[23], [44]
Se valide todos los bucles del sistema dentro y sobre sus límites operacionales.[23],
[44]
Se validen las estructuras internas de datos, para asegurar su integridad. .[23], [44]
• V2Soft, va dirigida a empresas que tercerizan el desarrollo, como apoyo, se ve la viabilidad
y complemento a través de una metodología para la validación y verificación para empresas
que brindan el servicio de desarrollo de Software, con el fin de garantizar la calidad del
software antes que el sistema sea entregado a la empresa que terceriza el desarrollo e
identificar los posibles defectos del sistema antes de ser entregado.
Es importante diferenciar la definición de un proceso bajo estas circunstancias, debido la
rigurosidad de las pruebas en ciertos casos es mucho menor, debido a que no se cuenta con
la integración del sistema y los componentes que permitan su completa validación.
o Desarrollo de herramienta que permita llevar el control del proceso de pruebas, que
permita la gestión y control de la validación y verificación de requerimientos
durante el ciclo de vida del software.
Esta herramienta puede dirigirse a:
La metodología propuesta en la guía, donde permita realizar desde la definición
del plan de pruebas hasta la evaluación del sistema a partir de las métricas,
siguiendo las plantillas definidas en el trabajo de grado.
Definición de casos de pruebas, ejecución y reporte de defectos, esta
herramienta puede usarse en diferentes niveles de validación y verificación de
requerimientos, lo que permitirá ser usada, desde las pruebas de parte de la
empresa que desarrolla el software y como la empresa que busca el servicio de
tercerización.
Actualmente, existen herramientas que permiten el reporte y seguimiento de los
defectos, pero pocas herramientas integran la definición y ejecución de casos de
pruebas. Dentro de las herramientas identificadas se encuentran ALM 11
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 78
(Application Lifecycle Management) o Quality center de Hewlett-Packard,
herramientas que son pagas.
• Por último, se identificó como trabajo futuro, una metodología para las pruebas no
funcionales, para la validación del cumplimiento de los requerimientos no funcionales [26]
y los atributos de un componente o sistema que no se refieren a su funcionalidad [2].
Existen varias técnicas para la validación de los requerimientos funcionales, pero en cuanto
a los no funcionales, se considera que existe una grande oportunidad para investigar y
definir la forma de realizar la verificación.
Los requerimientos no funcionales, son un factor importante en la definición de los
requerimientos del sistema, determinan el como el cliente requiere que el sistema reaccione
ante eventos, definen las “restricciones de los servicios o funciones ofrecidos por el
sistema. Incluye restricciones de tiempo, sobre el proceso de desarrollo y estándares.” [4],
son los requerimientos que actúan para obligar a una solución y especifican las propiedades
del sistema, se conocen muchas veces como requisitos de calidad y estos tienen a ser
clasificados de acuerdo a su interés [18].
En la Ilustración 33, se presentan las pruebas no funcionales que pueden ser abarcadas en la
metodología, al momento de probar que se cumplen con los requerimientos definidos, esta
validación muchas veces se vuelve un reto debido que se encuentran factores que en
ambientes de pruebas no se presentan, por lo se requiere de expertos para que realicen el
proceso.
Ilustración 33. Pruebas no funcionales
Pruebas no funcionales
Pruebas de rendimiento
Pruebas de carga
Pruebas de Stress
Pruebas de usabilidad
Pruebas mantenibilid
ad
Pruebas de fiabilidad
Pruebas de portabilidad
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 79
IV. Referencias y Bibliografía
Referencias
[1] «El outsourcing, aliado del ahorro en los negocios», Portafolio.com.co, 22-jul-2013. [En línea]. Disponible en: http://www.portafolio.co/negocios/el-outsourcing-aliado-del-ahorro-los-negocios. [Accedido: 26-sep-2014].
[2] ISTQB, International Software Testing Qualifications Board, «Glossary Archive - ISTQB® Glossary of Testing Terms». Erik van Veenendaal (The Netherlands), 19-oct-2012.
[3] B. Bruegge y Allen H. Dutoit, Ingeniería de Software orientado a objetos, Primera Edición., vol. 1. México: Prentice Hall, 2002.
[4] I. Sommerville, Ingenieria del Software. Madrid: Pearson Educacion, 2005. [5] Juan Palacio, «Gestión de proyectos Scrum Manager. (scrum Manager I y II) V.2.5». 25-abr-
2014. [6] Manuel Trigas Gallego, «Gestión de proyectos informáticos. Metodología Scrum». . [7] A. Labarca C., «LOS MÉTODOS DE INVESTIGACIÓN. Aplicados a las Ciencias de la Conducta».
[En línea]. Disponible en: http://teologiacultura.files.wordpress.com/2007/12/mc3a9todos-de-investigacic3b3n-aplicados-a-la-cs-educacic3b3n.pdf. [Accedido: 25-jul-2014].
[8] N. Malhotra, Investigacion de Mercados Un Enfoque Practico. México: Prentice Hall, 1998. [9] C. Fernandez Collado, Investigación y Comunicación. México: McGraw - Hill, 1989. [10] F. Daoudi y S. Nurcan, «A framework to evaluate methods’ capacity to design flexible business
processes», presentado en 6th International Workshop on Business Process Modeling, Porto, 2006.
[11] I. Mirbel y J. Ralyté, «Situational method engineering combining assembly-based and roadmap-driven approaches», Requirements Engineering, vol. 11, pp. 58–78, mar-2006.
[12] X. Higuera Moriones, «Guía Metodológica de Mejora de Procesos de Construcción de Software Adaptada para MIPyMES_DS Colombianas», Pontificia Universidad Javeriana, Bogotá, 2011.
[13] B. W. Boehm, «GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE REQUIREMENTS AND DESIGN SPECIFICATIONS».
[14] I. S. 12207-2008 ISO/IEC 12207, «Systems and software engineering — Software life cycle processes». 01-feb-2008.
[15] O. R. Puello, «Modelo de verificación y Validación basado en CMMI», Innovación Ing, vol. 1, n.o 1, pp. 20-27, jun-2013.
[16] IEEE Computer Society, «1012-2012 - IEEE Standard for System and Software Verification and Validation». may-2012.
[17] IEEE Std 1059- 1993, «IEEE Guide for Software Verification and Validation Plans». 02-dic-1994. [18] IEEE Computer Society, «Guie to the Software Engineering body of Knowledge - SWEBOK
Guide V3.0». 2013. [19] G. J. Myers, C. Sandler, y T. Badgett, The Art of Software Testing, Edición: 3. Auflage. Hoboken,
N.J: Wiley John + Sons, 2011. [20] Real Academia Española, «Diccionario de la lengua española», 2014. [En línea]. Disponible en:
http://www.rae.es/. [Accedido: 01-oct-2014]. [21] IEEE Computer Society, «Systems and software engineering – Vocabulary», ISOIECIEEE
247652010E, pp. 1-418, dic. 2010. [22] «IEEE Standard Dictionary of Measures to Produce Reliable Software», IEEE Std 9821-1988, pp.
1-54, 1989. [23] R. Patton, Software Testing, 2 edition. Indianapolis, IN: Sams Publishing, 2005.
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 80
[24] «Software and systems engineering Software testing Part 1: Concepts and definitions», sep. 2013.
[25] ISTQB, International Software Testing Qualifications Board, «Certified Tester - Foundation Level Syllabus». 31-mar-2011.
[26] Instituto Nacional de Tecnologías de la Comunicación - INTECO, «Guía de validación y Verificación», nov-2009. [En línea]. Disponible en: http://www.inteco.es/qualite_TIC/descargas/guias/?realLang=fr. [Accedido: 16-ago-2014].
[27] G. Rothermel, R. H. Untch, C. Chu, y M. J. Harrold, «Prioritizing test cases for regression testing», IEEE Trans. Softw. Eng., vol. 27, n.o 10, pp. 929-948, oct. 2001.
[28] R. S. Pressman, Ingenieria del Software - Un Enfoque Practico, 6.a ed. Madrid: McGraw-Hill Companies, 2002.
[29] «IEEE Standard Glossary of Software Engineering Terminology», IEEE Std 61012-1990, pp. 1-84, dic. 1990.
[30] K. Naik y P. Tripathy, Software Testing and Quality Assurance: Theory and Practice, 1 edition. Hoboken, N.J: Wiley-Spektrum, 2008.
[31] A. M. J. Hass, Guide to Advanced Software Testing. Boston: Artech House, 2008. [32] D. Graham, E. V. Veenendaal, I. Evans, y R. Black, Foundations of Software Testing: ISTQB
Certification, Revised edition. Australia: Cengage Learning EMEA, 2008. [33] A. Eseiza, «Guia para la escritura de casos de prueba», 08-mar-2011. [En línea]. Disponible en:
http://alejandroeseiza.blogspot.com/2011/03/guia-para-la-escritura-de-casos-de.html. [Accedido: 20-oct-2014].
[34] D. Galin, Software Quality Assurance: From Theory to Implementation, 1 edition. Harlow, England ; New York: Addison-Wesley, 2003.
[35] W. E. Perry, Effective Methods for Software Testing: Includes Complete Guidelines, Checklists, and Templates, 3 edition. Indianapolis, IN: Wiley, 2006.
[36] J. Watkins, Testing IT : An Off-the-Shelf Software Testing Handbook. Port Chester, NY, USA: Cambridge University Press, 2001.
[37] C. D. J. Cardona Velásquez, «Propuesta metodógica para la realización de pruebas de software en un ambientes productivos», Universidad Nacional de Colombia, Medellin, 2009.
[38] J. J. Gutiérrez, «Generación de pruebas de sistema a partir de la especificación funcional», Universidad de Sevilla, Sevilla España, 2005.
[39] S. Vegas Hernández, «Esquema de caracterización para la selección de técnicas de pruebas de software», Universidad Politécnica de Madrid, Madrid, España, 2002.
[40] B. Pérez Lamancha, «Proceso de Testing funcional Independiente», Universidad de la República, Montevideo, Uruguay, 2006.
[41] OWASP Foundation, «Guía de pruebas owasp», 2008. [En línea]. Disponible en: https://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.pdf. [Accedido: 16-mar-2015].
[42] V. C. Loaiza Carvajal y L. C. Zorro Jiménez, «Easy Requirement Management Tool - Marco teorico», Pontificia Universidad Javeriana, Bogotá, 2011.
[43] E. Hull, K. Jackson, y J. Dick, Requirements Engineering, Edición: 3. London ; New York: Springer, 2010.
[44] P. Skokovi y M. R. Skokovi, «Requirements Based Testing Process Overview (Originally presented as “Getting it right the first time”)», International Journal of Industrial Engineering and Managem ent (IJIEM), vol. 1, n.o 4, pp. 155 - 161, 2010.
[45] Bender RBT Inc, «Requirements Based Testing Process Overview». Bender RBT Inc, 2009. [46] T. O. A. C. Borland, «Eliminate the testing bottleneck - Maximize software quality with
Requirements Based Testing». ago-2006.
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 81
[47] B. Boehm y V. R. Basili, «Software Defect Top 10 List», Software Manangement, ene-2001. [En línea]. Disponible en: http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf. [Accedido: 29-sep-2014].
[48] A. M. J. Hass, Guide to Advanced Software Testing. Boston: Artech House, 2008. [49] ISTQB, International Software Testing Qualifications Board, «Certified Tester - Advanced Level
Syllabus Test Manager». 19-oct-2012. [50] ISO/IEC/IEEE 29119-1:2013(E), «Software and systems engineering Software testing Part
2:Test processes». 01-sep-2013. [51] R. Gore y S. Diallo, «The need for usable formal methods in verification and validation», en
Simulation Conference (WSC), 2013 Winter, 2013, pp. 1257-1268. [52] M. L. Hutcheson, Software Testing Fundamentals: Methods and Metrics, 1 edition.
Indianapolis, Ind: Wiley, 2003.
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 82
Anexo 2. Post-Mortem
Esta sección se presenta el post-mortem del Trabajo de Grado
1. Metodología propuesta vs. Metodología realmente utilizada.
La ejecución de actividades, se realizó de acuerdo a la metodología propuesta: SCRUM, pero se vio
la necesidad modificar el orden de las actividades planeadas en los sprints, debido que actividades
dependían de la disponibilidad de las personas a las que se les realizo la encuesta y de los
evaluadores de la guía, lo que implico que se modificara los momentos de ejecución de los sprints.
Adicional el primer sprint que correspondía a la investigación de fuentes, fue una actividad que
realmente estuvo presente durante todo el desarrollo del proyecto, a medida que se avanzaba nuevas
inquietudes o necesidades de información se presentaban.
2. Actividades propuestas vs. Actividades realizadas.
Se vio la necesidad de incluir más actividades que en el momento de la planeación no fueron
contempladas, correspondían a actividades más específicas, en la planeación se tuvo una idea global
de las actividades requeridas.
3. Efectividad en la estimación de tiempos del proyecto
El tiempo empleado versus el ejecutado, fue mucho menor. Aunque se planearon la cantidad de
horas que correspondían al número de créditos de la materia, se requirió más tiempo para realizar el
marco teórico y la guía metodológica.
Se tuvo un desfase, en cuanto al tiempo estimado de dedicación, el cual fue mayor y la diferencia
fue significativa respecto a la planeación.
Adicional que no se concluyo el trabajo en el semestre del 2014, por lo que
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 83
Otros anexos
Plantilla plan de pruebas
Ver documento [Anexo 1] Plantilla SVVP
Plantilla documento gestión de riesgos
Ver documento [Anexo 2] Documento de riesgos
Plantilla documento casos de pruebas
Ver documento [Anexo 3] Documento de casos de prueba
Ver documento [Anexo 6] Documento de diseño
Plantilla para la ejecución de casos de pruebas.
Ver documento [Anexo 4] Documento de ejecución de casos de prueba
Plantilla para el informe de avance de pruebas.
Ver documento [Anexo 5] Informe Avance de pruebas
Ejemplo aplicación [Anexo 6]
Ver documento [Anexo 7] Ejemplo aplicación documento de diseño
Documento marco de referencia – Way Of.
Ver documento [Anexo 8] Marco de referencia Guía - Way of.
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 84
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 85
Ingeniería de Sistemas Trabajo de Grado – Guía metodológica
Página 86
Pontificia Universidad Javeriana ISTAR- CIS1430IS08
Página 87