You are on page 1of 51

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
Director Trabajo de Grado: Miguel E. Torres
~CIS1430IS08

Grupo de investigación: ISTAR


Modalidad: Investigación Formativa
Agenda

 Introducción  Contribuciones
 Descripción General  Desarrollo de los objetivos
específicos
 Formulación del problema
 Descripción de la solución
 Justificación del problema
 Validación guía
 Solución a la problemática
 Conclusiones
 Impacto esperado
 Trabajos futuros
 Descripción del Proyecto
 Preguntas
 Objetivo general
 Objetivos específicos
 Anexos

 Metodología
Introducción

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

http://pegasus.javeriana.edu.co/~CIS1430IS08/
Descripción General
Formulación del Problema
En Colombia existen empresas que buscan el desarrollo de sus necesidades o
productos de software, en empresas terceras mediante el outsourcing.

El proceso de desarrollo de software, no hace parte de su modelo de negocio.

Permite que la empresa se enfoque en lo que realmente es lo suyo.

Define y
Terceriza
específica Recibe desarrollo
desarrollo
Requerimientos

Instalación del
Certifica Valida y Verifica
producto en
producto Requerimientos
producción
Formulación del Problema

 Requerimientos de sistemas no triviales,


Verificación: Validación: cuya complejidad, obliga que el proceso
sea riguroso y exhaustivo.
“La “Se han
especificación cumplido los
de los requisitos  Restricciones, como factores externos:
requisitos se para un uso Tiempo, presupuesto y los recursos.
han específico
cumplido." previsto o
aplicación."
 ¿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)?
Confirmación mediante examen y mediante
el suministro de evidencia objetiva. [6]
Justificación del Problema
 La validación y verificación de requerimientos, busca asegurar la calidad de
los productos de software, y reducir los riesgos o problemas relacionados:
Perdida de dinero, Tiempo o renombre, Daños personales, Incluso la muerte.

 ¿Qué estrategias, formas de trabajo y procedimientos se deben seguir, para


que no se presenten inconvenientes en el proceso?

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

Costo relativo para corregir un defecto. Tomado de [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.

 Brindar una alternativa de mejora al proceso


 Para el fortalecimiento y la claridad a las actividades
 Reducción de los riesgos referentes al proceso
 Garantizar la calidad integral y el cumplimento de los objetivos del
sistema.
Impacto Esperado

• Continuidad en la investigación sobre la


Corto Plazo Validación y Verificación de Requerimientos

• Aplicación de la guía en empresas que


tercerizan el desarrollo de software.
Mediano Plazo • Análisis de costo y beneficio de
implementación.

• En empresas que aplican la guía, se presenten


menos inconvenientes e incidentes por parte
Largo Plazo del proceso de validación y verificación de
requerimientos.
Descripción del Proyecto
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 Software
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.

Objetivos Identificar las debilidades, falencias y/o problemáticas presentadas en el


proceso de validación y verificación de requerimientos.
específicos
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
Metodología

Proyecto Trabajo de grado

Actividades del proyecto

SCRUM
Metodología Guía metodología
propia del
Sprint Marco de referencia “Way – Of”
A Nivel de Proyecto - SCRUM
Reunión de
Revisión del Retrospectiva
planificación del SCRUM diario
Sprint del Sprint
Sprint

Debate el Sprint
Evaluación del avance Se revisa recientemente
del proyecto: funcionalmente el finalizado y los
Determinar
resultado. cambios que se
funcionalidades que
- Lo que ha logrado podrían mejorar.
se incorporaran en el
Sprint. desde el anterior.
- Lo que va ha hacer
Cuál es el trabajo hasta el próximo.
necesario para - Si están teniendo Permite descubrir
planteamientos ¿Qué ha ido bien
realizar el incremento algún problema, o si
erróneos, durante el último
previsto encuentra algún Sprint? , ¿Qué será
impedimento. mejorables o mejorado para el
malinterpretaciones siguiente Sprint?
en las funcionalidades
Proceso Metodología SCRUM Trabajo de
Grado
Cambios a la Propuesta Inicial

 2014: Se incluyó un séptimo sprint, para el desarrollo de la memoria y la


página web del trabajo de grado.

 2015: Sprints incluidos


 Mejorar guía metodológica.
 Evaluar la guía a partir de los cambios realizados.
 Desarrollar memoria trabajo de grado.
 Complementar página web.
Herramienta de Gestión - Trello

Sprint
In progress
• Lista de planing • Actividades que • Actividades del
actividades del se realizaran en trabajo de grado
• Actividades que • Actividades del
trabajo de grado el sprint que se terminadas.
se realizaran en trabajo de grado
esta ejecutando
siguiente sprint en ejecución

Product Sprint
Done 2014
backlog backlog

Done 2015

https://trello.com/b/7LqCeX3y/trabajo-de-grado-ximena
Sprints Proyecto
Sprint Metodología Resultados
Sprint 1: Investigación Exploratoria Matriz de bibliografía
Sprint 2: Desarrollo del marco
Descriptiva Documento de marco teórico /Estado del arte
teórico

Sprint 3: Selección de
Se realizó la documentación como complemento
metodologías acorde a las Descriptiva
en el marco teórico
necesidades de la guía

Sprint 4: Identificar las


Cuantitativa/ Documento de análisis de encuesta donde se
debilidades, falencias y/o
Descriptiva determinaron las necesidades del proceso.
problemáticas

Descriptiva, bajo el V2Soft: Guía metodológica para el proceso de


Sprint 5: Desarrollo de la Guía
marco de referencia validación y verificación de requerimientos para
metodológica
“Way-of” el usuario final
Sprint Metodología Resultados
Sprint 6: Metodológica Documento de evaluación de la guía
Descriptiva
Evaluación de la guía metodológica.
Sprint 7: Desarrollo de
memoria de grado y página Descriptiva Memoria trabajo de grado y página web
web
Sprint 8: Identificar puntos a
Descriptiva Matriz de puntos de mejora
mejorar
V2Soft: Guía metodológica para el proceso de
Sprint 9: Profundización Guía Exploratoria / Descriptiva validación y verificación de requerimientos para
el usuario final
Sprint 10: Evaluación de la Descriptiva / análisis Documento de evaluación de la guía
guía cualitativo y cuantitativo metodológica.
Sprint 11: Ciclo de mejora de
memoria trabajo de grado y Descriptiva Memoria trabajo de grado y página web
página web
A Nivel de la Guía Metodológica

Marco de referencia, adaptado de [2], [3]


Way –of” y la Guía
Way Of Aspecto a tener en cuenta
• Enmarca a la guía metodológica.
• Define los factores especiales se deben tener en cuenta
Way of thinking
para implementar el proceso de Validación y Verificación
de requerimientos.

• Lenguaje utilizado para generar el modelo.


Way of modeling
• Factores especiales de la organización y su estado actual.

Way of working • Actividades y responsabilidades.

Way of controlling • Objetivos serán medidos a través de indicadores.

• Que necesita el proceso para su ejecución: Recursos


Way of supporting
humanos y herramientas de pruebas.
Contribuciones
Desarrollo de los Objetivos Específicos

• Realizó proceso de investigación


Estado del arte
• Documento “Marco teórico”.

• A partir del marco teórico, se seleccionaron las


Seleccionar las mejores
mejores prácticas, brindando una base para la guía
prácticas
metodológica.

Identificar las debilidades, • Creó y ejecutó la encuesta.


falencias y/o • Se analizó los resultados obtenidos
problemáticas • Documento “Encuesta trabajo de grado”
Desarrollo de los Objetivos Específicos

Desarrollo de guía • Desarrollo de la guía metodológica


metodológica • Documento “Guía metodológica”

Evaluación de la guía • Evaluación de la guía por parte de expertos.


metodológica • Documento “Evaluación guía”
Descripción de la Solución
 El proceso de pruebas se debían adaptar a un modelo de ciclo de vida del
software, para definir cuando se deben ejecutar los subprocesos y
actividades.

Estado
Guía
del arte
Descripción de la Solución
 Se identifico y selecciono, el proceso de validación y verificación de
requerimientos en el ciclo de vida.

Actividades de validación y verificación en el modelo en V, tomado [4]


Descripción de la Solución

 Se selecciono el proceso de pruebas definido por el “International Software


Testing Qualifications Board” ISTQB. [5]
Descripción de la Solución
 Adaptación del modelo en V, a la problemática a resolver
Descripción de la Solución
 Identificación de actividades de acuerdo al modelo en V y al proceso de
pruebas.
Descripción de la Solución
 Definición de las actividades del proceso – Desarrollo de la guía y “Way –Of”

Í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 Consideraciones Recomendaciones
Forma de trabajar Forma de trabajar de la actividad
Forma de soportar Forma de soportar la actividad
Consideración 2
Forma de Modelar Forma de modelar la actividad
Forma de controlar Forma de controlar la actividad Recomendación 1
Salidas Presenta los artefactos resultantes de la actividad
Consideración 1
Validación Guía

Validación Guía

2014 2015

3 expertos V&V Experto


3 expertos V&V
pertenecientes certificado en
(2014)
a la empresa ISTQB
Validación Guía

 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 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
Resultados Validación 2014
Id Parcialme
Totalmente No está
Necesida Necesidad identificada nte
cubierta cubierto
d cubierta
Definición de roles del Respuesta
proceso de pruebas de Enunciado
R01 100% SI NO
software.
¿Considera que la guía se completa? 100%
Definición de funciones y
responsabilidades de los ¿Considera que la guía es clara? 100%
R02 66.66% 33.33%
roles que se definan en R01. ¿Considera que la guía se puede adaptar a una
Definición de la organización que presente el modelo de empresa? 100%
R03 planificación de las pruebas 33.33% 66.66%
¿Considera que la implementación de la guía es viable? 100%
de software.
Definición de proceso para ¿Considera que la guía es servible? 100%
R04 la estimación de tiempos de 33.33% 33.33% 33.33% ¿La información que se presenta en el marco teórico de
pruebas de software. la guía es suficiente para el entendimiento del proceso? 100%

Definición para determinar ¿Considera que a la guía le hace falta información? 33.33% 66.66%
R05 66.66% 33.33%
casos pruebas de software. ¿Cree que la guía aporta al proceso de pruebas? 100%
Proceso para priorizar los
R06 33.33% 66.66%
casos pruebas de software.
Definición de métricas para
R07 evaluar la calidad proceso 66.66% 33.33%
de pruebas.
Comentarios y Recomendaciones

Especificaciones dentro del marco de aprobación del


software y los posibles incidentes que se presenten
dentro del paso a producción

Forma de solucionar los diferentes tipos de trabas o


inconvenientes que el tester encuentre en el desarrollo
de un plan de pruebas.

La guía referencie en la tabla de contenido las páginas


que indica
Mejoras 2015

Como crear, Inclusión de otras


determinar casos técnicas de
de prueba a partir priorización casos
de requerimientos de prueba

Complementar
información sobre
métricas, para
contextualizar
Resultados Validación 2015
Id
Totalmente Parcialmen No está
Necesida Necesidad identificada
cubierta te cubierta cubierto
d
Definición de roles del
R01 proceso de pruebas de 100% Respuesta
Enunciado
software. SI NO
¿Considera que la guía se completa? 100%
Definición de funciones y
¿Considera que la guía es clara? 100%
R02 responsabilidades de los roles 100% ¿Considera que la guía se puede adaptar a
que se definan en R01. una organización que presente el modelo de 100%
Definición de la planificación empresa?
de las pruebas de software. ¿Considera que la implementación de la guía
R03 100% 100%
es viable?
¿Considera que la guía es servible? 100%
Definición de proceso para la ¿La información que se presenta en el
R04 estimación de tiempos de 100% marco teórico de la guía es suficiente para 100%
pruebas de software. el entendimiento del proceso?
¿Considera que a la guía le hace falta
Definición para determinar 100%
R05 100% información?
casos pruebas de software. ¿Cree que la guía aporta al proceso de
100%
Proceso para priorizar los pruebas?
R06 casos pruebas de software. 75% 25%

Definición de métricas para


R07 evaluar la calidad proceso de 75% 25%
pruebas.
Comentarios y Recomendaciones

Tener un poco más de definición general frente al cargo de los jefes.

Se considera apropiado detallar el perfil profesional (conocimientos básicos) de las personas


que ejercerían las diferentes funciones

Dependerá:
Tipo de proyecto.
Tienen intereses en cuanto a velocidad, seguridad, rendimiento, etc
Controles de cambio y variaciones en el sistema.
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.
Se tratan temas que normalmente no se tienen en cuenta en el momento del proceso de pruebas

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 maduración para ser
implementado en una empresa que cumpla con el modelo.

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
Conclusiones

 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 industria, se espera un impacto en la disminución de riesgos por
defectos, sus impactos asociados. Así como el incremento en la calidad de los
productos de software.
 El integrar varias metodologías, permite disminuir los riesgos de
implementación y puesta en producción de los nuevos sistemas de una
empresa.
Conclusiones
 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.
 Uno de los factores importantes y de gran éxito para la implementación de una
metodología es que el personal conozca la importancia del proceso y se encuentre
capacitado.
 La validación y verificación de requerimientos para una empresa que terceriza el
desarrollo, es muy importante. Los expertos del negocio son quienes conocen el
propósito del sistema y pueden enfocar con mayor precisión y efectividad el
proceso.
Conclusiones
 La ejecución de encuestas, permitió determinar problemáticas que se
enfrentan a diario y los puntos a considerar para la guía y 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.
 La evaluación de una guía dependerá del método seleccionado para la
evaluación. Cuando se cuenta con un experto, pueda que en el momento de
responder las preguntas él no tenga presente aspectos de la guía que si se
encuentran incluidos.
Trabajos futuros
Metodología para
la V&V de
V&V estática de
requerimientos a
los requerimientos
nivel de caja
y los métodos
blanca o a nivel
formales
de estructura del
código

Una metodología
para las pruebas
V&V para
no funcionales,
empresas que
para la validación
brindan el servicio
del cumplimiento
de desarrollo de
de los
Software
requerimientos no
funcionales

Desarrollo de herramienta que permita llevar el control del proceso


de pruebas, que permita la gestión y control de la V&V de
requerimientos durante el ciclo de vida del software
Preguntas??
Referencias
 [1] Bender RBT Inc, «Requirements Based Testing Process Overview». Bender RBT Inc, 2009.
 [2] 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.
 [3] 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.
 [4] 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].
 [5] ISTQB, International Software Testing Qualifications Board, «Certified Tester - Advanced
Level Syllabus Test Manager». 19-oct-2012.
 [6] ISTQB, International Software Testing Qualifications Board, «Glossary Archive - ISTQB®
Glossary of Testing Terms». Erik van Veenendaal (The Netherlands), 19-oct-2012.
Bibliografía
[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.

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

[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.
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
Supuestos y Restricciones de la guía

 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 están
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 ejemplo: pruebas de recuperación, seguridad, resistencia , desempeño,
rendimiento, carga, stress, portabilidad, fiabilidad, mantenibilidad, usabilidad.
Resultados esperados

 Como resultado esperado de la implementación del proceso de Verificación y


Validación se tiene, de acuerdo a [14]:
 Una estrategia para la Verificación y Validación desarrollada e implementada
 Criterios de Verificación y Validación son necesarios y requeridos son identificados
 Ejecución de actividades de Verificación y Validación
 Defectos y problemas son identificados y registrados
 El resultado del proceso se define que el software o producto es apto y se pone a
disposición del cliente y partes interesadas.
Entregables
Entregable Descripción
Documento con la base teórica para el desarrollo del trabajo de grado.
Estado del arte
Corresponde al marco teórico del trabajo de grado.

Guía metodológica Guía metodológica para la validación y verificación de requerimientos


Documento con la evaluación de la guía metodológica por parte de
Documento con análisis de expertos. Corresponde al proceso de Validación cuantitativa y
resultados cualitativa del grupo seleccionado para su evaluación.
Memoria del trabajo de grado, incluye como finalizo el proyecto, y los
siguientes resultados de los objetivos específicos:
 Estado del arte
Memoria del trabajo de grado.  Proceso de evaluación, selección de prácticas para la guía
 Debilidades, falencias y/o problemáticas encontrados en el
proceso.
 Resultado de evaluación de la guía
Página web que permitirá el acceso a la información del trabajo de
Página web.
grado y sus documentos

You might also like