Upload
hoangkhanh
View
214
Download
0
Embed Size (px)
Citation preview
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/
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
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?
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
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.
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 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
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