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
51
Embed
Presentación de PowerPoint - Trabajos de Grado de la ...pegasus.javeriana.edu.co/~CIS1430IS08/docs/PresentacionTG.pdf · Introducción V2Soft: Guía metodológica para la validación
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
• 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:
[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-
[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.
[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:
[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,