Guía Metodológica para el Proceso

de Validación y Verificación de

Requerimientos para el Usuario FinalMarí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

Descripción General

Formulación del problema

Justificación del problema

Solución a la problemática

Impacto esperado

Descripción del Proyecto

Objetivo general

Objetivos específicos

Metodología

Contribuciones

Desarrollo de los objetivos

específicos

Descripción de la solución

Validación guía

Conclusiones

Trabajos futuros

Preguntas

Anexos

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

Define y específica

Requerimientos

Tercerizadesarrollo

Recibe desarrollo

Valida y Verifica Requerimientos

Certifica producto

Instalación del producto en producción

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.

Formulación del Problema

Requerimientos de sistemas no triviales,

cuya complejidad, obliga que el proceso

sea riguroso y exhaustivo.

Restricciones, como factores externos:

Tiempo, presupuesto y los recursos.

¿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)?

Verificación:

“La especificación de los requisitos se han cumplido."

Validación:

“Se han cumplido los requisitos para un uso específico previsto o aplicación."

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 laValidación y Verificación de RequerimientosCorto Plazo

• Aplicación de la guía en empresas quetercerizan el desarrollo de software.

• Análisis de costo y beneficio deimplementación.

Mediano Plazo

• En empresas que aplican la guía, se presentenmenos inconvenientes e incidentes por partedel proceso de validación y verificación derequerimientos.

Largo Plazo

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

Objetivos específicos

Generar documento del estado del arte sobre las prácticas y modelos actualesde validación y verificación de los requerimientos de software para usuariofinal.

Seleccionar las mejores prácticas y modelos de validación y verificación de losrequerimientos.

Identificar las debilidades, falencias y/o problemáticas presentadas en elproceso de validación y verificación de requerimientos.

Elaborar una guía metodológica, que especifique el proceso de validación yverificación de los requerimientos de software, dando alternativas de manejo alos puntos críticos identificados, en el marco de referencia de una empresa nodesarrolladora de software

Evaluar la guía metodológica planteada, por medio de lista de chequeo yencuestas, dirigidas a expertos en validación y verificación de requerimientos

Metodología

Proyecto Trabajo de grado

SCRUM

Actividades del proyecto

Metodología propia del

Sprint

Guía metodología

Marco de referencia “Way – Of”

A Nivel de Proyecto - SCRUM

Reunión de planificación del

Sprint

Determinar funcionalidades que se incorporaran en el

Sprint.

Cuál es el trabajo necesario para

realizar el incremento previsto

SCRUM diario

Evaluación del avance del proyecto:

- Lo que ha logrado desde el anterior.

- Lo que va ha hacer hasta el próximo.

- Si están teniendo algún problema, o si

encuentra algún impedimento.

Revisión del Sprint

Se revisa funcionalmente el

resultado.

Permite descubrir planteamientos

erróneos,

mejorables o malinterpretaciones

en las funcionalidades

Retrospectiva del Sprint

Debate el Sprint recientemente finalizado y los cambios que se

podrían mejorar.

¿Qué ha ido bien durante el último Sprint? , ¿Qué será mejorado para el siguiente Sprint?

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

•Lista de actividades del trabajo de grado

Product backlog

•Actividades quese realizaran ensiguiente sprint

Sprint planing •Actividades que

se realizaran enel sprint que se esta ejecutando

Sprint backlog

•Actividades del trabajo de gradoen ejecución

In progress•Actividades del

trabajo de gradoterminadas.

Done 2014

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

teórico Descriptiva Documento de marco teórico /Estado del arte

Sprint 3: Selección de

metodologías acorde a las

necesidades de la guía

DescriptivaSe realizó la documentación como complemento

en el marco teórico

Sprint 4: Identificar las

debilidades, falencias y/o

problemáticas

Cuantitativa/

Descriptiva

Documento de análisis de encuesta donde se

determinaron las necesidades del proceso.

Sprint 5: Desarrollo de la Guía

metodológica

Descriptiva, bajo el

marco de referencia

“Way-of”

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

validación y verificación de requerimientos para

el usuario final

Sprint Metodología Resultados

Sprint 6: Metodológica

Evaluación de la guíaDescriptiva

Documento de evaluación de la guía

metodológica.

Sprint 7: Desarrollo de

memoria de grado y página

web

Descriptiva Memoria trabajo de grado y página web

Sprint 8: Identificar puntos a

mejorar Descriptiva Matriz de puntos de mejora

Sprint 9: Profundización Guía Exploratoria / 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

Descriptiva / 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

Descriptiva Memoria trabajo de grado y 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

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.

Way of modeling• Lenguaje utilizado para generar el modelo.

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

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

humanos y herramientas de pruebas.

Contribuciones

Desarrollo de los Objetivos Específicos

• Realizó proceso de investigación

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

• A partir del marco teórico, se seleccionaron lasmejores prácticas, brindando una base para la guíametodológica.

Seleccionar las mejores prácticas

• Creó y ejecutó la encuesta.

• Se analizó los resultados obtenidos

• Documento “Encuesta trabajo de grado”

Identificar las debilidades, falencias y/o problemáticas

Desarrollo de los Objetivos Específicos

• Desarrollo de la guía metodológica

• Documento “Guía metodológica”Desarrollo de guía

metodológica

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

• Documento “Evaluación guía”Evaluación de la guía

metodológica

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.

GuíaEstado del arte

Descripción de la Solución

Se identifico y selecciono, el proceso de validación y verificación derequerimientos 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

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

Consideraciones

Consideración 2

Consideración 1

Recomendaciones

Recomendación 1

Validación Guía

Validación Guía

2014

3 expertos V&V pertenecientes a la empresa

2015

3 expertos V&V (2014)

Experto certificado en

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

Necesida

d

Necesidad identificadaTotalmente

cubierta

Parcialme

nte

cubierta

No está

cubierto

R01

Definición de roles del

proceso de pruebas de

software.100%

R02

Definición de funciones y

responsabilidades de los

roles que se definan en R01.66.66% 33.33%

R03

Definición de la

planificación de las pruebas

de software.33.33% 66.66%

R04

Definición de proceso para

la estimación de tiempos de

pruebas de software.33.33% 33.33% 33.33%

R05Definición para determinar

casos pruebas de software.66.66% 33.33%

R06Proceso para priorizar los

casos pruebas de software.33.33% 66.66%

R07

Definición de métricas para

evaluar la calidad proceso

de pruebas.66.66% 33.33%

EnunciadoRespuesta

SI NO

¿Considera que la guía se completa? 100%

¿Considera que la guía es clara? 100%

¿Considera que la guía se puede adaptar a una

organización que presente el modelo de empresa? 100%

¿Considera que la implementación de la guía es viable? 100%

¿Considera que la guía es servible? 100%

¿La información que se presenta en el marco teórico de

la guía es suficiente para el entendimiento del proceso? 100%

¿Considera que a la guía le hace falta información? 33.33% 66.66%

¿Cree que la guía aporta al proceso de pruebas? 100%

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, determinar casos de prueba a partir de requerimientos

Inclusión de otras técnicas de

priorización casos de prueba

Complementar información sobre

métricas, para contextualizar

Resultados Validación 2015

Id

Necesida

d

Necesidad identificadaTotalmente

cubierta

Parcialmen

te cubierta

No está

cubierto

R01

Definición de roles del

proceso de pruebas de

software.100%

R02

Definición de funciones y

responsabilidades de los roles

que se definan en R01.100%

R03

Definición de la planificación

de las pruebas de software. 100%

R04

Definición de proceso para la

estimación de tiempos de

pruebas de software.100%

R05Definición para determinar

casos pruebas de software. 100%

R06Proceso para priorizar los

casos pruebas de software. 75% 25%

R07

Definición de métricas para

evaluar la calidad proceso de

pruebas.75% 25%

EnunciadoRespuesta

SI NO

¿Considera que la guía se completa? 100%

¿Considera que la guía es clara? 100%

¿Considera que la guía se puede adaptar a

una organización que presente el modelo de

empresa?

100%

¿Considera que la implementación de la guía

es viable?100%

¿Considera que la guía es servible? 100%

¿La información que se presenta en el

marco teórico de la guía es suficiente para

el entendimiento del proceso?

100%

¿Considera que a la guía le hace falta

información?100%

¿Cree que la guía aporta al proceso de

pruebas?100%

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

V&V estática de los requerimientos

y los métodosformales

Metodología para la V&V de

requerimientos a nivel de caja

blanca o a nivelde estructura del

código

V&V para empresas que

brindan el servicio de desarrollo de

Software

Una metodologíapara las pruebasno funcionales,

para la validacióndel cumplimiento

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

Estado del arte Documento con la base teórica para el desarrollo del trabajo de grado.

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 análisis de

resultados

Documento con la evaluación de la guía metodológica por parte de

expertos. Corresponde al proceso de Validación cuantitativa y

cualitativa del grupo seleccionado para su evaluación.

Memoria del trabajo de grado.

Memoria del trabajo de grado, incluye como finalizo el proyecto, y los

siguientes resultados de los objetivos específicos:

Estado del arte

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.Página web que permitirá el acceso a la información del trabajo de

grado y sus documentos