V2Soft guía metodológica para el proceso de validación y

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


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


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


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”


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.


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


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


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.


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


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


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


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”


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?


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


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

https://trello.com/b/7LqCeX3y/trabajo-de-grado-ximena


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


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


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.


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


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]


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


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


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


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]


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


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]


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


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]


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]


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]



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


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


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


usuario


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]


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]


Página 29


• 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


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.


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]


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


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


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]


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]


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


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


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.


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


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


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]


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


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]


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


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


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


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


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]


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]


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


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.


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.


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]


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]


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


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


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.


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


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


X X X

R02

Definición de

funciones y

responsabilidades de

los roles que se

X X X


Página 61

definan en R01.

R03

Definición de la

planificación de las


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


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


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


Página 63

Comentarios de la guía

Ítem considerado Evaluador 1 (técnico Andrés

Perdomo)


Castellanos)


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


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


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


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


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


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


Certified Tester Foundation Level

ISTQB – Bogotá 2011

Capacitation – TSP Team Member Training


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)


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.


Id

Necesida

d

Necesidad

identificada

Evaluador 1 (técnico Andrés

Perdomo)


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


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


Códig

o Enunciado



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



Si No Si No Si No


Página 69


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



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


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


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


Página 72




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


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


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.


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


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


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


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


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


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.


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.


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.


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


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.


Página 84


Página 85


Página 86


Página 87

Documents

V2Soft guía metodológica para el proceso de validación y