impacto de las pruebas no funcionales en la mediciÓn de la …
TRANSCRIPT
1
IMPACTO DE LAS PRUEBAS NO FUNCIONALES EN LA MEDICIÓN DE LA CALIDAD DEL PRODUCTO SOFTWARE DESARROLLADO
ALEJANDRO OCAMPO ACOSTA LUISA MARCELA CORREA TAPASCO
UNIVERSIDAD TECNOLÓGICA DE PEREIRA
FACULTAD DE INGENIERÍAS ELÉCTRICA, ELECTRÓNICA, FÍSICA Y CIENCIAS DE LA COMPUTACION
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN PEREIRA
2011
2
IMPACTO DE LAS PRUEBAS NO FUNCIONALES EN LA MEDICIÓN DE LA CALIDAD DEL PRODUCTO SOFTWARE DESARROLLADO
ALEJANDRO OCAMPO ACOSTA LUISA MARCELA CORREA TAPASCO
Monografía para optar al título de Ingeniero de Sistemas y Computación
Asesor Ph.D. JULIO CESAR CHAVARRO
Docente
UNIVERSIDAD TECNOLÓGICA DE PEREIRA
FACULTAD DE INGENIERÍAS ELÉCTRICA, ELECTRÓNICA, FÍSICA Y CIENCIAS DE LA COMPUTACION
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN PEREIRA
2011
3
Nota de aceptación
________________________________
________________________________
________________________________
________________________________
________________________________
________________________________ Presidente del Jurado
________________________________ Jurado
________________________________ Jurado
Pereira, Octubre de 2011
4
CONTENIDO
pág.
INTRODUCCION. .................................................................................................. 10
1. EL PROBLEMA OBJETO DE ESTUDIO. GENERALIDADES ........................... 11
1.1 DEFINICIÓN DEL PROBLEMA ....................................................................... 11
1.2 JUSTIFICACIÓN .............................................................................................. 13
1.3 OBJETIVOS ..................................................................................................... 14
1.3.1 Objetivo general ........................................................................................... 14
1.3.2 Objetivos específicos .................................................................................... 15
1.4 MARCO CONCEPTUAL .................................................................................. 15
1.4.1 Calidad del software ..................................................................................... 15
1.4.2 Ciclo de vida del software ............................................................................. 15
1.4.3 Procesos ....................................................................................................... 15
1.4.4 Pruebas no funcionales ................................................................................ 16
1.4.5 Verificación de software ................................................................................ 16
1.4.6 Validación de Software ................................................................................. 16
1.4.7 CMMI (Capability Maturity Model Integration). .............................................. 16
1.4.8 Scampi .......................................................................................................... 16
1.4.9 IT-Mark. ......................................................................................................... 17
1.4.10 ISO 9001 ..................................................................................................... 17
1.4.11 ITIL .............................................................................................................. 17
1.4.12 MoProSoft ................................................................................................... 17
1.4.13 Probar software ........................................................................................... 18
1.4.14 Depurar software ........................................................................................ 18
1.4.15 No conformidad y/o hallazgo ....................................................................... 18
1.4.16 Pruebas funcionales. .................................................................................. 18
5
1.4.17 Pruebas no funcionales............................................................................... 19
1.5 MARCO TEÓRICO .......................................................................................... 19
1.6 MARCO HISTÓRICO ....................................................................................... 21
1.6.1 Empresas colombianas de Testing ............................................................... 21
2. LAS PRUEBAS NO FUNCIONALES. ................................................................ 24
2.1 CARÁCTER DE LAS PRUEBAS NO FUNCIONALES .................................... 24
2.1.1 Estándares relacionados con las pruebas de software ................................. 24
2.1.2 Ingeniería de requerimientos ........................................................................ 25
2.1.3 Estrategias de pruebas de software en general ............................................ 33
2.1.4 Descripción del proceso de pruebas no funcionales. .................................. 34
2.1.5 Desarrollo de caso de prueba ....................................................................... 39
3. MÉTODOS DE PRUEBAS. ................................................................................ 41
3.1 MÉTODOS ESTÁTICOS.................................................................................. 42
3.1.1 Inspecciones ................................................................................................. 42
3.1.2 Walkthroughs ................................................................................................ 44
3.2 MÉTODOS DINÁMICOS.................................................................................. 44
3.2.1 Pruebas de unidad. ....................................................................................... 45
3.2.2 Pruebas de integración ................................................................................. 45
3.2.3 Pruebas de sistema. ..................................................................................... 46
3.3 ATRIBUTOS DE CALIDAD DEL SOFTWARE QUE SON EVALUABLES AL
APLICAR PRUEBAS NO FUNCIONALES ............................................................. 47
3.3.1 Características evaluables del requerimiento de Fiabilidad ......................... 50
3.3.2 Características evaluables del requerimiento de Portabilidad...................... 51
3.3.3 Características evaluables del requerimiento de Eficiencia ......................... 52
3.3.4 Características evaluables del requerimiento de Mantenibilidad ................. 53
3.3.5 Características evaluables del requerimiento de Usabilidad ........................ 54
3.4 ANÁLISIS DEL PAPEL ASIGNADO A LAS PRUEBAS NO FUNCIONALES EN
LAS METODOLOGÍAS ÁGILES Y EN LAS METODOLOGÍAS TRADICIONALES.
............................................................................................................................... 62
6
3.4.1 Pruebas no funcionales según Metodologías ágiles. .................................... 62
3.4.2 Pruebas no funcionales según metodologías tradicionales .......................... 65
3.4.3 Metodología de pruebas en V ....................................................................... 68
4. METRICAS PROPUESTAS PARA LA MEDICIÓN DE LOS REQUERIMIENTOS
NO FUNCIONALES. .............................................................................................. 70
4.1 RECOPILACIÓN DE MÉTRICAS PARA ATRIBUTOS DE CALIDAD VISTOS
COMO REQUERIMIENTOS NO FUNCIONALES ................................................. 70
4.2 MÉTRICAS PARA VALIDAR LOS REQUISITOS NO FUNCIONALES ........... 73
4.2.1Usabilidad. ..................................................................................................... 73
4.2.2 Fiabilidad. ...................................................................................................... 74
4.2.3 Portabilidad ................................................................................................... 75
4.2.4 Mantenibilidad ............................................................................................... 75
4.3 PROPUESTA DEL MÉTODO DE EVALUACIÓN DE LOS REQUERIMIENTOS
NO FUNCIONALES. .............................................................................................. 76
4.3.1 Fase 1. Levantamiento de requerimientos. ................................................... 76
4.3.2 Fase 2. Análisis ............................................................................................. 77
4.3.3 Fase 3. Diseño .............................................................................................. 78
4.3.4 Fase 4. Implementación ................................................................................ 79
4.4 DEFINICIÓN DEL MÉTODO DE EVALUACIÓN. ............................................. 80
4.4.1 Roles y responsabilidades ............................................................................ 80
4.4.2 Planificación de las pruebas ......................................................................... 81
4.4.3 Diseño de las pruebas .................................................................................. 82
4.4.4 Ejecución de las pruebas. ............................................................................. 83
4.4.5 Análisis de los resultados .............................................................................. 83
4.4.6 Validar criterios de aceptación ...................................................................... 83
4.4.7 Certificación ................................................................................................. 83
4.5 AUTOMATIZACIÓN DE PRUEBAS A ATRIBUTOS NO FUNCIONALES,
USANDO HERRAMIENTAS PARA LA EVALUACIÓN DE LOS ATRIBUTOS ..... 84
5. CONCLUSIONES Y RECOMENDACIONES. ................................................... 87
7
BIBLIOGRAFÍA ...................................................................................................... 89
8
LISTA DE TABLAS
pág.
Tabla 1.Requerimientos funcionales y no funcionales ........................................... 28
Tabla 2. Restricciones. .......................................................................................... 28
Tabla 3. Estándar de la IEEE 829-1983. ................................................................ 36
Tabla 4. Plantilla recomendada para caso de prueba. ........................................... 40
Tabla 5. Niveles de pruebas. ................................................................................. 42
Tabla 6. RFN fiabilidad. ......................................................................................... 50
Tabla 7. RFN portabilidad ...................................................................................... 51
Tabla 8. RFN eficiencia. ......................................................................................... 52
Tabla 9. RFN Mantenibilidad.................................................................................. 54
Tabla 10. RFN Usabilidad. ..................................................................................... 55
Tabla 11. Esquema general de las listas de chequeo modificadas. ....................... 60
Tabla 12. Tareas y artefactos de usabilidad propuestos. ....................................... 61
Tabla 13. Diferencias entre metodologías ágiles y metodologías tradicionales. .... 63
Tabla 14. Atributos de calidad fragmentados en características. ........................... 72
Tabla 15. Esquema general de las listas de chequeo modificadas. ....................... 74
Tabla 16. Modelo de caos de uso para requerimientos no funcionales. ................ 79
Tabla 17. Herramientas. ........................................................................................ 84
9
LISTA DE FIGURAS
Pág.
Figura 1. Tipos de requerimientos. ........................................................................ 27
Figura 2.Tipos de requerimientos de software. ...................................................... 27
Figura 3. Categorías de requerimientos no funcionales. ........................................ 29
Figura 4. Tipos de requerimientos no funcionales y sus categorías. ..................... 30
Figura 5. Ciclo de vida del desarrollo de software. ................................................ 31
Figura 6. Estrategias de pruebas. .......................................................................... 34
Figura 7. Jerarquía de requisitos no funcionales. .................................................. 48
Figura 8. ISO/IEC 9126. ......................................................................................... 48
Figura 9. Iteraciones de RUP ................................................................................. 67
Figura 10. Miembros del equipo de RUP. .............................................................. 67
Figura 11. Relaciones entre productos de desarrollo y niveles de prueba. ............ 68
Figura 12. Método propuesto para la evaluación de los atributos no funcionales. . 81
10
INTRODUCCION.
En los últimos años, el incremento constante del software desarrollado en Colombia, y la necesidad de mejorar su calidad, ha conllevado la necesidad de utilizar una serie de estándares y procesos para mejorar la calidad de este. Sin embargo, muchas empresas no han tenido en cuenta estos estándares o procesos de mejora hacia la calidad, haciendo que sus productos sean deficientes y muy costosos; es por ello que existe la necesidad de establecer unos procesos de pruebas no funcionales en el software haciendo de ello un producto confiable, usable y de alta calidad. Una de las características que se tienen en los procesos de las pruebas no funcionales, es la de encontrar errores en la realización de una aplicación para luego poder corregirlos en las etapas del ciclo de vida antes de salir al mercado, logrando un acercamiento a un software de buena calidad y reducir costos en estos. Para la realización de este material monográfico se analizaron varios estándares de niveles pruebas no funcionales, aplicados a las metodologías agiles y robustas durante las etapas de desarrollo. También se observaron las diferentes herramientas a utilizar durante cada requerimiento no funcional que se tiene. El interés de la realización monográfica es brindar una orientación, a las organizaciones desarrolladoras de software, en la realización de pruebas no funcionales, debido a que los diferentes problemas que surgen por no realizar estas antes de salir a producción, puede ser muy costoso. En el mundo del software, la importancia que se le debe dar las pruebas no funcionales en el desarrollo es vital, porque con estas se genera confiabilidad, seguridad y lo mejor de todo: hasta se pueden salvar vidas!
11
1. EL PROBLEMA OBJETO DE ESTUDIO. GENERALIDADES.
1.1 DEFINICIÓN DEL PROBLEMA La industria del software en Colombia es un sector joven, si se encuadra en las organizaciones que se dedican a la investigación, desarrollo y comercialización de software; por ser tan joven es inmaduro pero en constante evolución y en búsqueda de mejorar continuamente. Dichas formas de mejoramiento, son entre tanto no solo los modelos de mejora de proceso disponibles, sino además que se encuentren al alcance financiero de la empresa, o se halla también a través de adopciones de buenas prácticas de desarrollo, sin la supervisión de alguna entidad autorizada para certificarles los avances de mejora realizados, o a través de los apoyos que proporciona el gobierno por medio del Ministerio de Tecnologías de la Información y las comunicaciones. Debido a la gran desarticulación entre las federaciones y el estado, no se tienen cifras exactas acerca de la cantidad de casas desarrolladoras en Colombia, sin embargo, según el DANE1 en el país existen ―más de 650 empresas de desarrollo de software‖2, de las cuales en la región cafetera se cuenta con ―48 empresas legalmente establecidas en las cámaras de comercio respectivas, 20 en la ciudad de Manizales, 16 en Pereira y 12 en Armenia‖3, sin tener en cuenta las que ingresaron al gremio el año inmediatamente anterior. Es el constante surgimiento de nuevas empresas, el que exige a las organizaciones que ya se encuentran en dicho segmento, que se preocupen por mejorar la calidad de su producto. Adicionalmente, deben enfocar sus esfuerzos en garantizar cumplimiento en la entrega del producto, respetando los tiempos establecidos y precios, y es el factor del tiempo de entrega – Time to market, por el cual las organizaciones priorizan el desarrollo del software sobre la calidad, ya que además no tienen en cuenta la aplicación de pruebas a lo largo del proceso
1 Departamento Administrativo Nacional de Estadística
2 HESHUSIUS RODRÍGUEZ, Karen, Desafíos de una industria en formación. Mayol Ediciones.2009.293p.
ISBN 978-958-8307-56. 3 CUESTA MEZA, Albeiro. Caracterización de la industria del software en el triangulo del café-Colombia.Madrid.2008.9P.
12
de desarrollo del producto software, por ende, olvidan también las pruebas no funcionales. Las fábricas de software del país, no sólo se enfrentan contra su propios parámetros establecidos para sus proyectos de desarrollo, como lo es tiempo, el precio final, entre otros, sino que además, deben enfrentar al mercado respectivo, el cual exige ser competitivo debido a la globalización. Es por lo anterior que las actuales empresas del gremio, deben contar con un alto grado de especialización en sus funciones, lo cual han logrado en el país ―130 empresas mediante la certificación ISO 9000, una empresa con certificación CMMI categoría V y otras cinco están en proceso de obtener esta certificación‖4, datos correspondientes al 2006. Se puede entonces inferir, que un porcentaje menor a la cuarta parte del total de las casas desarrolladores de software existentes en el país, realizan un proceso completo para desarrollar su producto con calidad. Se exceptúan aquellas que sólo cuentan con certificación ISO 9000, ya que esto no garantiza que se lleve a cabo el proceso formal de aplicación de pruebas, tanto funcionales como no funcionales. Finalmente, la ISO 9000 no garantiza que se aporte a la calidad del producto desarrollado, por el contrario si garantiza, que se realiza una gestión en el proceso de desarrollo con calidad. En la actualidad la realización de pruebas no funcionales, como lo son usabilidad, estabilidad, escalabilidad, eficiencia, seguridad, permiten la evaluación y medición de la calidad del software. Si se tiene en cuenta que por muy alto que sea el nivel funcional del software desarrollado, si la aplicación no es funcional, simplemente será inútil, sin embargo siendo tan importantes, no son aplicadas ya que se prioriza el desarrollo del producto, buscando cumplir con las entregas y minimizar costos por retrasos, pero esto luego se revierte con el tiempo, ya que el error hallado en producción es más costoso que el hallado en un ambiente controlado. Ante lo antes expuesto, se ha planteado un problema de investigación el cual se buscará responder con éste proyecto:
4 HESHUSIUS RODRÍGUEZ, Karen, Desafíos de una industria en formación. Mayol Ediciones.2009.293p.
ISBN 978-958-8307-56.
13
¿Es posible determinar el conjunto de características de los requerimientos no funcionales que permitan mejorar la calidad del software, al aplicar pruebas no funcionales? 1.2 JUSTIFICACIÓN Colombia alcanzó una tasa de crecimiento del 48%, en el mercado del software latinoamericano, entre el 2000 y el 2004. Y de acuerdo con las estadísticas ofrecidas por el DANE entre 1995 y el 2004 se duplicó el número de empresas dedicadas al desarrollo de Software. Esto afirma el incremento desmesurado de casas desarrolladoras de software tanto a nivel regional, como nacional. Lo antes mencionado es un incentivo hacia mejorar el nivel de la calidad del software desarrollado, ya que es lamentable y tan común, encontrar que las empresas priorizan distintos factores para el desarrollo de un producto software frente a la calidad del mismo, todo ello por no perder sus objetivos planteados inicialmente en un proyecto de desarrollo software, puesto que buscan responder a los clientes con el producto solicitado, aún a costa de la calidad del mismo. En otros casos no concluyen con éxito los proyectos contratados en el tiempo estipulado. Lo anterior se afirma con base en los informes ―CHAOS‖ del Standish Group, quienes periódicamente evalúan el sector, en su reporte de 2010, en el que se concluye que ha ocurrido un retroceso en éste campo, con respecto a años anteriores, puesto que se halló que ―sólo el 32% de los proyectos son exitosos, y el 44% están comprometidos por el presupuesto, esfuerzo o fechas y el 24% de los proyectos son cancelados‖. En el país la industria del software tiene una tendencia exponencial donde a mayor tiempo, mayor cantidad de proveedores software, y de igual forma se incrementa la cantidad de consumidores, los cuales cada vez requieren productos con características más complejas, las cuales se traducen en condiciones críticas del software, al ser productos innovadores. Al requerir productos a la medida se incrementa la probabilidad de que se presenten fallas, errores en el sistema, lo cual ratifica, la importancia de la definición, evaluación y medición del software, aplicando en su proceso de desarrollo, las pruebas no funcionales.
14
Se busca entonces establecer un instrumento teórico que permita a las organizaciones del segmento de mercado afectado, la orientación hacia la mejora de la calidad, mediante la aplicación de pruebas no funcionales, si se tiene en cuenta que ―la única estrategia posible para el proveedor es conseguir la calidad solicitada al menor coste posible‖5, para lograr ser competitivos en el mercado, ya que la calidad en el software, aunque es tomada como trascendental y evidente que exista en los productos desarrollados, y su grado de importancia es tan alto, que efectivamente se logre afectar cada acción de la vida moderna. Tal es el efecto de importancia que ha causado el software en Colombia, que ha llegado a ser parte de los sectores que el estado impulsa para el desarrollo y crecimiento del país. Y es así como se debe impulsar y buscar también que las empresas empiecen a incluir en su proceso de desarrollo de software, metodologías de aplicación de pruebas no funcionales, logrando así, dar valor agregado al producto software y enfocado hacia mejorar el nivel de calidad del mismo, y alcanzando los beneficios de éste, como lo es minimizar la ocurrencia de un error o un fallo en producción, lo cual se representa en minimización de los costos del error en producción. Teniendo en cuenta las dificultades antes planteadas, se busca en este proyecto, desarrollar una monografía, que permita servir de base u objeto de argumentación para enfatizar hacia la implementación de pruebas no funcionales, de tal forma que las empresas de software de la región se sientan motivadas, hacia la adopción del proceso de pruebas no funcionales, comprendiendo sus impactos hacia la mejora de la calidad en sus productos software. 1.3 OBJETIVOS 1.3.1 Objetivo general Establecer un referente conceptual y teórico de los requerimientos no funcionales que aportan a la calidad del producto software del proceso de pruebas correspondientes
5 PIATTINI VELTHUIS, MARIO G. Calidad de Sistemas Informáticos. ISBN 978-84-7897-734-5
15
1.3.2 Objetivos específicos - Establecer un análisis comparativo del tratamiento que cada metodología otorga a los requerimientos no funcionales - Definir un modelo de medición para los requerimientos no funcionales que afectan la calidad del software desarrollado. - Proponer un método de evaluación de los requerimientos no funcionales, orientado a fortalecer la calidad del producto de software que se desarrolla, de manera independiente de la metodología. 1.4 MARCO CONCEPTUAL 1.4.1 Calidad del software. Es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. 1.4.2 Ciclo de vida del software. Un modelo de ciclo de vida software es cualquier caracterización descriptiva de la evolución del software. Es sencillo articular un modelo de ciclo de vida que indique cómo deben ser desarrollados los sistemas software. Esto es posible ya que la mayor parte de los modelos son intuitivos, por lo que muchos detalles de desarrollo pueden ser ignorados o generalizados. Sin embargo, puede preocupar la relativa validez y robustez de tales ciclos de vida cuando se desarrollan diferentes clases de aplicaciones en diferentes entornos de desarrollo."Hay que observar o recoger datos durante todo el proceso de desarrollo de un sistema; periodo de tiempo que suele medirse en años‖. 1.4.3 Procesos. El proceso ayuda a los miembros de una organización a alcanzar los objetivos estratégicos ayudando a trabajar más inteligentemente, no más duro, y de un modo más consistente. Los procesos eficaces también proporcionan un medio para introducir y utilizar nuevas tecnologías de forma que permitan responder mejor a los objetivos estratégicos de la organización. Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software.
16
1.4.4 Pruebas no funcionales. Éstas se realizan para verificar que el software desarrollado cumple con los requerimientos no funcionales establecidos por el cliente. Existen varios tipos de pruebas no funcionales, entre las más comunes están las pruebas de seguridad, pruebas de rendimiento, pruebas de usabilidad, pruebas de portabilidad, entre otras. 1.4.5 Verificación de software. Técnica y actividad ligada al control de calidad del software se trata de comprobar si los productos construidos en una fase de ciclo de vida satisfacen los requisitos establecidos en una fase anterior y/o si el software construido satisface los requisitos del usuario. 1.4.6 Validación de Software. Técnica y actividad ligada al control de calidad del software se trata de comprobar si los productos construidos en una fase de ciclo de vida, funciona como el usuario quiere y realiza las funciones que se habían solicitado. 1.4.7 CMMI (Capability Maturity Model Integration). Modelo de madurez de mejora de los procesos para el desarrollo de productos y de servicios. Consiste en las mejores prácticas que tratan las actividades de desarrollo y de mantenimiento que cubren el ciclo de vida del producto, desde la concepción a la entrega y el mantenimiento. El propósito de CMMI para desarrollo es ayudar a las organizaciones a mejorar sus procesos de desarrollo y de mantenimiento, tanto para los productos como para los servicios. Las categorías de las áreas de proceso de CMMI son gestión de procesos, gestión de proyectos, ingeniería y soporte. 1.4.8 Scampi. El método SCAMPI se utiliza para la evaluación de las organizaciones que usan CMMI, y un resultado de una evaluación es una calificación [Ahern 2005]. Si en una evaluación se usa la representación continua, la calificación es un perfil de nivel de capacidad. Si en una evaluación se usa la representación por etapas, la calificación es un nivel de madurez (p.ej., nivel de madurez 3).
17
Los métodos de evaluación SCAMPI son generalmente métodos aceptados que se usan para realizar evaluaciones utilizando modelos CMMI. El Documento de definición del método —Method Definition Document (MDD) de SCAMPI— define las reglas para asegurar la consistencia de las calificaciones de la evaluación.
1.4.9 IT-Mark. Su objetivo es brindar un sello de calidad para pequeñas y medianas empresas de Tecnologías de la Información, que acredita su madurez y capacidad. También tiene como objetivo mejorar la efectividad organizacional y el éxito en el mercado mediante la mejora de sus procesos. El servicio proporciona conocimiento sobre las capacidades técnicas y gerenciales de la organización a través de la identificación de fortalezas y debilidades, así como del descubrimiento áreas a mejorar de acuerdo con sus metas de negocio. 6 1.4.10 ISO 9001. es una norma internacional que se aplica a los sistemas de gestión de calidad (SGC) y que se centra en todos los elementos de administración de calidad con los que una empresa debe contar para tener un sistema efectivo que le permita administrar y mejorar la calidad de sus productos o servicios.7 1.4.11 ITIL. es un conjunto de conceptos y prácticas para la gestión de servicios de tecnologías de la información. ITIL da descripciones detalladas de un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI. 1.4.12 MoProSoft. es un modelo de procesos para la industria de software nacional de México promovido por la Secretaría de Economía, que fomenta la estandarización de la operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permite elevar la madurez de los procesos para las organizaciones que desarrollan y/o
6 Resumen modelo IT-Mark web-http://www.fedesoft.org/downloads/Sinertic/RESUMEN_MODELO_IT_MARK.pdf
7 Normas ISO 9000. Web-http://www.normas9000.com/index.html
18
mantienen software para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. 8 1.4.13 Probar software. Determinar la existencia de errores, defectos o fallas en el software. 1.4.14 Depurar software: Detectar el lugar donde existe el error, por consiguiente su eliminación de su origen. 1.4.15 No conformidad y/o hallazgo. Es una desviación de los resultados esperados, en otras palabras, es un error, defecto o falla que va más allá del alcance de las pruebas ejecutadas. Se categorizan de la siguiente forma: - ―Bloqueantes: Es el tipo de no conformidad que detiene la operación de un programa/componente o hace que este arroje resultados que impiden la continuidad de la operación del cliente. - Funcionales: Es el tipo de no conformidad que se presenta cuando al ejecutar una opción particular del sistema creada para dar solución a un requerimiento funcional, no se evidencia que el requerimiento se solucione. - Presentación: Son no conformidades relacionadas con la presentación de los resultados en la ejecución de una opción del sistema. Estos deben ajustarse a los estándares definidos y con las reglas gramaticales y ortográficas del idioma en que es presentada la solución‖9. 1.4.16 Pruebas funcionales. Aquellas evaluaciones que se realizan sobre la ejecución de funcionalidades del sistema, verificando la existencia de errores, defectos o fallas en la solución software comparándola frente a los requerimientos funcionales.
8 Moprosoft web-http://moprosoft.info/Quees.aspx
9 Manual de procedimientos Aseguramiento de calidad del software. Web-http://procesos.univalle.edu.co. Mayo 2009
19
1.4.17 Pruebas no funcionales. Aquellas evaluaciones que se realizan sobre los elementos que están ―presentes en los resultados de la ejecución de funcionalidades del sistema‖10. 1.5 MARCO TEÓRICO Las fábricas de software a lo largo de la historia se ha visto y aún lo hacen, deben estar enfrentándose continuamente a diversos factores económicos, sociales, de entorno, entre otros, que afectan su razón de social o razón de ser, como lo es el entregar un producto software desarrollado a la medida, por lo tanto afectando la calidad del producto elaborado. Cabe mencionar que dichas causas o problemas que se presentan al desarrollar un producto software son los siguientes: - Requisitos mal gestionados - Comunicación ambigua e imprecisa en el equipo - Arquitectura frágil superficial - Complejidad impresionante - Inconsistencia entre requisitos, diseño e implementación - Insuficientes pruebas - Estimación subjetiva - Proceso de desarrollo en cascada - Falta de gestión en la configuración - Ausencia de herramientas de apoyo - No planificar y medir el alcance del proyecto Lo anterior es sólo una muestra de aquellas causas que provocan que la eficiencia y eficacia de las organizaciones desarrolladoras de software, no se alcancen, además de no permitir una conclusión con éxito de sus proyectos propuestos, y que finalmente terminen siendo una pérdida, tanto en presupuesto, como en tiempo tanto por parte del cliente como de la empresa. Afortunadamente en la actualidad el enfoque de algunas fábricas desarrolladoras de software, es hacia el mejoramiento continuo en el proceso, sin embargo, el tema no está tan difundido entre las mismas.
10
Manual de procedimientos Aseguramiento de calidad del software. Web-http://procesos.univalle.edu.co. Mayo 2009
20
Con base al artículo del The Economic Times, ―Testing becoming the fastes – growing niche within the IT space‖11, en el que se confirma que las actividades del desarrollo de pruebas están en continuo crecimiento y que además permite avanzar hacia la calidad en los productos software. Y aún más interesante es conocer la opinión de las organizaciones con experiencia en tecnología, las cuales opinan según este artículo, que los jóvenes están enfocando sus intereses hacia las carreras de ―testing‖, como también que se encuentran con compañías que enfocan sus esfuerzos hacia capacitar sus profesionales en ésta rama, ya que en el mercado no se encuentran profesionales con éstos conocimientos. El director de Sistemas Maveric, Ranga Reddy, comenta que el giro que ha dado el proceso de pruebas sobre el desarrollo software, ha sido drástico, ya que se afecta de forma positiva el tema presupuestal específicamente. Es decir que las compañías de tecnología, se están orientando hacia mejorar la calidad de sus productos software, incluyendo el proceso de pruebas dentro de su estructura organizacional. En concordancia con lo anterior, en 2006 según Fedesoft, ―sólo el 10% de las empresas locales‖12 lograron incursionar en mercados internacionales, puesto que cumplieron con las normas internacionales de calidad, lo cual pocas fábricas de software alcanzaron. Es por ello que se motiva hacia la implementación de procesos que estén enfocados hacia la mejora continua de la calidad del software. Cabe entonces destacar la importancia del desarrollo de pruebas software, puesto que con el mismo se busca dar un apoyo para disminuir el riesgo de ocurrencia de fallos y presencia de errores en producción. Adicionalmente se está disminuyendo la presencia del usuario a lo largo del desarrollo, ya que al implementar pruebas software, no será necesario estar solicitando al cliente su apoyo en probar, o su opinión de si el software está sobre el camino correcto o incorrecto. Finalmente, el no cumplimiento de un requerimiento no funcional puede llegar a que un sistema entero sea inutilizable, ya sea porque este no es fiable, colocando
12
HESHUSIUS RODRÍGUEZ, Karen, Desafíos de una industria en formación. Mayol Ediciones.2009.293p. ISBN 978-958-8307-56.
21
en riesgo a la empresa o personas, un ejemplo de ello es el software realizado para los aviones, el cual sino es confiable expone la vida de la clientes que viajan, es por esto que las pruebas no funcionales son parte importante en el calidad del software, donde se busca explotar al máximo los beneficios de la aplicación y no se incremente su costo. 1.6 MARCO HISTÓRICO La calidad del software afecta no solamente al cliente y al proveedor del producto, sino también a la sociedad. La producción de software inicia, y se convierte en negocio rentable, sin embargo, es entonces cuando se hace necesario tener estándares de calidad para conocer si el producto que se está recibiendo cumple con los requerimientos y atributos de calidad. Debido a la creciente automatización y por ende, su presencia tanto en sistemas de navegación de los submarinos, los sistemas de radiación médicos, software para diagnósticos de médicos, gestión de semáforos, las telecomunicaciones del planeta entero, entre otras innumerables aplicaciones, es decir, que los sistemas a los cuales se expone no a una sola persona, sino millones. Es por ello que un error en producción, provoca no sólo pérdidas millonarias, sino también puede afectar cantidad de vidas humanas, y animales. Por lo tanto al realizar pruebas no sólo disminuye el riesgo de ocurrencia de errores, sino también mejora la arquitectura, diseño, y adicionalmente incrementa el tiempo de vida del software desarrollado, puesto que proporciona facilidad de mantenimiento. 1.6.1 Empresas colombianas de Testing - Choucair Testing S.A. ―Su servicio se realiza de forma paralela a las diferentes etapas de desarrollo de software y comprende pruebas funcionales, de rendimiento, de seguridad en aplicativos y de migración de datos‖13.
13
Ventana informática. Pruebas de software y gestión documental. Julio 2009. 200p. ISSN 0123 – 9678.
22
- Green SQA. ―Ofrece servicios de Pruebas de Software, Aseguramiento de Calidad y Consultoría a la industria del software, contribuyendo al aumento de la productividad y competitividad de las empresas mediante la optimización de sus procesos de desarrollo. Brindan acompañamiento en el desarrollo y/o mantenimiento de aplicaciones, así como en la implementación de sistemas de gestión de calidad tales como la norma ISO9001 y el modelo CMMI. Está vinculado como miembro del HASTQB (HispanicAmerica Software TestingQualificationBoard) desde Febrero de 2011‖14. - Software Quality Assurance, SQA S.A. ―Dedicada a prestar servicios de consultoría y aseguramiento de calidad de software, cuyo enfoque es entender las necesidades de los clientes para brindar soluciones enfocadas en contribuir a la disminución de costos generando mayor confianza de los productos de software en producción‖15. - Litsa Consulting Ltda: ―Dedicada a la consultoría en sistemas, desarrollo de software especializados y a la medida‖16 - Galia Technologies Ltda. ―GaliaTech fue creada con el fin de ofrecer al mercado regional el conocimiento y experiencia que sus socios han obtenido a lo largo de sus años como consultores del área de TI. Cuya visión es la de convertirse en una de las empresas de tecnología con mayor cobertura y conocimiento en procesos de calidad; apoyando a las compañías de la región en mejorar sus servicios de TI, logrando así, el fortalecimiento de estas y la satisfacción de sus usuarios‖.17 - Indudata Ltda. Lleva 20 años en el mercado colombiano prestando servicios profesionales en Ingeniería de requerimientos, Testing, Gestión de la configuración, ISO 27000, Gestión de proyectos, buscando ―apoyar los proveedores de tecnología y a las áreas de TI de las compañías en facilitarles el
14
Green SQA .Web- http://www.greensqa.com/. Septiembre 2010. 15
Software Quality Assurance, SQA S.A.Web - http://www.sqasa.com/ 16
Litsa Consulting Ltda. Web - http://www.litsacnsulting.com/ 17
Galia Technologies Ltda .Web- http://www.galiatech.com/empresa.htm
23
logro de sus objetivos y alcanzar el éxito en informática, la manera de hacerlo siempre ha sido apoyándonos en los estándares mas reconocidos y con mayores resultados a nivel mundial, por este motivo nos hemos convertido en un referente en la utilización de las buenas. Buscan garantizar a nuestros clientes la exitosa formulación, operación y sostenibilidad de la Gestión y Calidad en proyectos y procesos de Software‖18 Para finalizar, ―la calidad es la piedra angular sobre la cual todas las otras estrategias necesitan descansar, tales como la innovación, administración financiera y planificación‖19.
18
Indudata . Web- http://www.indudata.com/ 19
HAMMOND,Joshua. Presidente American Quality Foundation
24
2.LAS PRUEBAS NO FUNCIONALES.
2.1 CARÁCTER DE LAS PRUEBAS NO FUNCIONALES 2.1.1 Estándares relacionados con las pruebas de software -IEEE 829 – 1998. Documentación de pruebas de software. ―El propósito de esta norma es describir una serie de documentos de prueba de software. Un documento de prueba estándar puede facilitar la comunicación, proporcionando un marco común de referencia‖. -IEEE 982.1. Diccionario estándar de medidas para producir software fiable. Se describe el proceso de prueba compuesto por una jerarquía de fases, actividades y tareas y define un conjunto mínimo de tareas para cada actividad. La norma es aplicable a la unidad de pruebas digitales de cualquier software. Los conceptos de ingeniería de software y pruebas en la que esta norma se basa es en el enfoque, la orientación y los recursos de información para ayudar con la implementación y uso de la unidad estándar de prueba. -Pruebas de unidad del software. Es la conducta que toman las pruebas locales frente a un modulo del sistema, es decir, sirven para demostrar o determinar si el funcionamiento de un modulo es el correcto. Estas pruebas también son conocidas como pruebas unitarias. -Verificación y validación del software. Es el nombre dado a los procesos y pruebas de software, en donde la verificación satisface los requerimientos funcionales o no funcionales. La validación determina si el sistema satisface las expectativas del cliente sobre el producto realizado. -ISO/IEC 25051 – 2006. Requisitos de calidad de productos de software y las instrucciones para las pruebas: Esta norma determina como probar los productos de software con los requerimientos de calidad establecidos.
25
-ISO/IEC 29119. Estándar de pruebas software: sirve de base a las pruebas en el mundo de desarrollo del software eliminando inconsistencia entre algunas normas actuales, las cuales no cuentan con pruebas establecidas. -ISO/IEC 25000:2005. Ingeniería del software, SQuaRE: es un conjunto de normas las cuales se fundamentan a través de la ISO 9126 y la ISO 14598 (Evaluación del Software), la cual tiene como objetivo primordial el de guiar el desarrollo de productos de software con las especificación de calidad. ISO/IEC 9126 Factores de calidad del software. El estándar ISO/IEC 9126 fue reemplazado por SQuaRE, ISO 25000:2005 el cual contiene los identicos parámetros. Este estándar se divide en cuatro partes las cuales son modelo de calidad, métricas externas, métricas internas y calidad en las métricas de uso. Esta norma fue creada con el fin de evaluar los productos de software, señalando las propiedades de la calidad, también puede ser de utilidad para definir los requerimientos de calidad. 2.1.2 Ingeniería de requerimientos. Ya nombrados algunos de los actuales estándares relacionados con las pruebas de software, se procederá a definir el concepto de Ingeniería de requerimientos, la cual ―trata de establecer lo que el sistema debe hacer, sus propiedades emergentes deseadas y esenciales, y las restricciones en el funcionamiento del sistema y los procesos de desarrollo del software‖.20 Es decir, es la interpretación por parte del equipo desarrollo, de las necesidades, restricciones de los clientes y/o usuarios. Un requerimiento es una característica que debe cumplir el sistema para alcanzar un objetivo. El conjunto de éstos crea un prototipo del sistema final, el cual es extraído de las ideas abstractas que representan las necesidades. Quedando establecidos en un documento denominado especificación de requerimientos, el cual se define luego de pasar de un previo análisis, estudio de viabilidad, entre otros procesos relacionados y pertinentes. Para lograr definir estos requerimientos se dispone de varias técnicas, como lo son los siguientes:
20
SOMMERVILLE, Ian, Ingeniería de software . Séptima edición.Madrid, España: Pearson Educación S.A, 2005. 667p.
26
- Entrevistas. - Intercambio de opiniones entre el equipo de trabajo. - Lluvia de ideas entre el grupo de trabajo (Brainstorming). - Cuestionario (Check-List) Es típico confundir un requisito con la forma de solución a una necesidad, como lo es por ejemplo, el decir, para el sistema se debe tener una tabla en base de datos denominada de X forma. En la etapa Inicial de un proyecto se debe establecer en un documento, de una manera informal, las necesidades del cliente, de tal forma que quede descrita de forma abstracta lo que éste desea. Por consiguiente se establece en un documento formal, filtrando lo descrito en el informal, transformándolo en tareas viables, escrito en una forma detallada, y comprensible tanto para el cliente como para el equipo de trabajo, por ende, se define lo que se conoce como requerimientos. -Especificación de los requerimientos Tanto los requerimientos funcionales como los no funcionales ―se especifican como sentencias declarativas‖21 y usando casos de uso, ya que éste último facilita la comprensión tanto para el cliente como para el equipo de trabajo, permitiendo una mejor comunicación entre los mismos. Como recomendación, para la definición de cada requisito se debe seguir la siguiente estructura: Sujeto + verbo activo. Como ejemplo las siguientes sentencias: - El sistema debe … - Se requiere que el sistema … - El sistema hará … En dicha definición de los requerimientos, se debe identificar cada uno según el tipo de requerimiento al que pertenece, con base a la siguiente clasificación:
21
CLAVIJO RODRÍGUEZ, Diana Lucia. Gestión de requisitos, Junio 2011. Pág. 22.
27
Figura 1. Tipos de requerimientos.
Fuente: Sommerville, Ian. Ingeniería del software, en [1].
-Requerimientos del usuario: Sentencias de la visión que el cliente tiene del qué debe hacer el sistema, declarado en su lenguaje natural, conteniendo también las restricciones que éste establece, las cuales no afectan la parte operativa del sistema. -Requerimientos de software: este define cómo debe funcionar el producto, en donde se especifican las limitaciones o restricciones sobre la funcionalidad del mismo, teniendo en cuenta que se debe tener total claridad en lo descrito, evitando ambigüedades. Estos son tan importantes ya que se establece el comportamiento del producto. Los requerimientos de software se dividen en requerimientos de dominio, en funcionales, no funcionales, o también conocidos como componentes FURPS+, modelo propuesto por Robert Grady y Hewlett Packard (HP): Figura 2.Tipos de requerimientos de software.
Fuente: Sommerville, Ian. Ingeniería del software, en [1].
28
Tabla 1.Requerimientos funcionales y no funcionales
Funcionales
Funcionalidad UsabilidadReability
(Confiabilidad)
Performance
(Rendimiento)
Supportability
(Soporte)
Especificaciones
que debe ser capaz
de ejecutar el
sistema
Facilidad de uso Capacidad de
recuperación a
fallos
Tiempo de
respuesta a
solicitudes
Facilidad de
someterse a
mantenimient
o
Eficiencia Configurable
No funcionales (URPS)
Tabla 2. Restricciones.
Requisitos de implementación Estándares de codificación, Lenguajes de
Implementación, Políticas de integridad de BD
Requisitos de diseño Restricciones de diseño -
Sistemas operativos
-Ambientes
-Compatibilidad
-Estándares
Requisitos de interfaces Elementos externos con los que no interactuar,
Restricciones de formato y otros factores usados por
una interacción
+ (Restricciones)
-Requerimientos de dominio (+): ―Son requerimientos de alto nivel que quizás se describen mejor como requerimientos ―no debería‖, definen el comportamiento del sistema que no es aceptable―22, es decir, son aquellas especificaciones que son restricciones para el sistema. -Requerimientos funcionales (F): Son las capacidades o características que debe cumplir, en cuanto a funcionamiento, definidas a través de las entradas y salidas esperadas.
22
SOMMERVILLE, Ian, Ingeniería de software . Séptima edición.Madrid, España: Pearson Educación S.A, 2005. 667p.
29
-Requerimientos no funcionales (URPS): ―Describen atributos del sistema o atributos del ambiente del sistema‖23. Éste tipo de requisitos se divide en ―requerimientos del producto, requerimientos organizacionales, requerimientos externos‖24. Figura 3. Categorías de requerimientos no funcionales.
Fuente: Sommerville, Ian. Ingeniería del software, en [1]. -Requerimientos del producto: Definen el comportamiento del producto:
Fiabilidad (Reliability)
Usabilidad (Usability)
Portabilidad
Eficiencia
Capacidad de soporte (Supportability) -Requerimientos Organizacionales: hacen parte de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. -Requerimientos Externos: Este incluye en los requerimientos que derivan factores externos al sistema y su proceso de desarrollo.
23
SCALONE, Fernanda. Estudio comparativo de los modelos y estándares de calidad del software.Buenos Aires,
Argentina. junio 2006. 138p. 24
SOMMERVILLE, Ian, Ingeniería de software . Séptima edición.Madrid, España: Pearson Educación S.A, 2005. 667p.
30
De los tres anteriores se derivan a su vez de la manera como se observa en la figura 1. Figura 4. Tipos de requerimientos no funcionales y sus categorías.
Fuente: Sommerville, Ian. Ingeniería del software, en [1].
Para finalizar, el origen de los requerimientos no funcionales parten de diversos factores, entre ellos a restricciones de ―presupuesto, a políticas de la organización, a la interoperabilidad del sistema con otros sistemas software o hardware, también surgen de los otros factores externos como la seguridad o la legislación sobre la privacidad‖[1]. Es pertinente aclarar que el proceso de pruebas es distinto a la depuración, ya que
el primero hace referencia a determinar la existencia de errores en el producto,
31
mientras que el segundo, se define para encontrar el lugar de origen del error y
erradicarlo. Donde primero se prueba para luego depurar.
Se toma entonces como concepto de pruebas de software al ―proceso
empleado para identificar que una aplicación sea correcta, completa, segura y de
buena calidad en el desarrollo‖25. Es considerado un proceso complejo de aplicar
dentro del ciclo de vida del desarrollo es, significando un alto costo, pero de igual
considerado ―elemento crítico para determinar la calidad del producto‖26.
Teniendo claro lo anterior, se pasa entonces a definir que para mejorar la calidad
del producto, se inicia por el proceso de pruebas, y para fines del presente
proyecto monográfico, sólo se hace énfasis en pruebas no funcionales. Las cuales
se deben realizar a lo largo del ciclo de vida del desarrollo de software, es decir,
debe ser transparente al ciclo de vida:
Figura 5. Ciclo de vida del desarrollo de software.
Fuente: PRESSMAN, Roger S. Ingeniería del software, en [2]. Se realizan para garantizar entregas de calidad y liberación de un producto con un número mínimo de fallas, errores o defectos, asegurando así una mayor confiabilidad tanto para las áreas de desarrollo, como para lograr la satisfacción de los usuarios finales. Sin embargo en la actualidad a éste proceso no se le da la verdadera importancia que tiene, es menospreciado, puesto que aún se tiene la concepción de que este
25
Definición de testeo de software. Santa fé.Web-http://www.alegsa.com.ar/Dic/testeo%20del%20software.php. 2008. 26
VENTANA INFORMÁTICA. Pruebas de software y gestión documental. Julio 2009.197p. ISSN 0123 – 9678.
32
proceso va siempre al final de cada fase del ciclo de vida del desarrollo (Figura 1). Pudiéndose inferir que la baja calidad de un producto, se observa con la cantidad de reporte de errores, por ende, mayor soporte al cliente. Reiterando que en todo proyecto es difícil cumplir con el cronograma establecido, por ende le huyen a ésta fase, con la argumentación de ―no disponer del recurso tiempo‖, adicionalmente, porque no encuentran como demostrar el aporte del proceso de pruebas no funcionales sobre la calidad del producto desarrollado, puesto que se espera tener un valor que indique el nivel de calidad alcanzado, en cuanto a los aspectos no funcionales del sistema, como ocurre con las pruebas funcionales, cuyo resultado es medible y alcanzable, contrario de las pruebas no funcionales, a las cuales se les asigna valores subjetivos. Debido a lo antes expuesto, se dificulta la verificación del impacto que generan las pruebas sobre los requerimientos no funcionales, y por tanto no se cuenta con indicadores verídicos, con los cuales se le pueda demostrar al cliente la justificación de su gran importancia sobre la calidad del producto final. Adicionalmente porque para ―verificar de forma objetiva los requerimientos no funcionales cuantitativos puede ser muy alto el coste‖27 y el cliente que adquiere el aplicativo no encuentra justificación a los altos costos del proceso. Sin embargo, es necesario persuadir a las organizaciones de la importancia de éste proceso sobre los requerimientos no funcionales, buscando justificar que deberían invertir por lo menos un ―50% de los recursos del proyecto a éste, y un 80% cuando el software a desarrollar es de misión crítico‖28. Puesto que el valor agregado es en calidad y fiabilidad, logrando garantizar la disminución en la ocurrencia de errores. El proceso de pruebas es una técnica de la verificación y la validación, donde
estos últimos son los nombres que se le dan a los procesos de análisis y pruebas.
27
SOMMERVILLE, Ian, Ingeniería de software . Séptima edición.Madrid, España: Pearson Educación S.A, 2005. 667p. 28
AGUIAR FERNÁNDEZ , María del Mar. Ingeniería del software y pruebas.. Revista española de electrónica. Septiembre
2000. 90p. Número 550.
33
Es válido aclarar que la verificación tiene como principal objetivo, determinar si el
producto cumple con los requerimientos funcionales y no funcionales
especificados por el cliente, mientras la validación determina si el software
funciona correctamente y satisface las expectativas que el cliente tiene sobre este.
Por ende el proceso de pruebas no funcionales, permite validar y verificar el
producto desarrollado, de tal forma, que se inicia la planeación y ejecución del
proceso al iniciar el proyecto, es por ello, que se realizan revisiones a
requerimientos levantados, a revisión de diseño.
2.1.3 Estrategias de pruebas de software en general. Se disponen de dos tipos, la detección y la prevención, donde en la primera tiene como objetivo encontrar errores y pasar a corregirlos, antes de liberar el software a producción, mientras que en la segunda, se realiza al terminar cada etapa del desarrollo, para prever errores antes de su ocurrencia, sin continuar a la siguiente etapa, hasta no garantizar la eliminación de los orígenes de los errores hallados en la etapa actual. En cuanto a costos, es claro que al realizar tempranamente una eliminación de un error es menos costoso, que encontrar el mismo en la última etapa del desarrollo, ya que en ese punto, se han generado a partir del mismo, nuevos errores. Es por tanto que el usar la estrategia de Prevención es menos costoso, ya que se resuelve el problema antes de su ocurrencia, sin tener que esperar a finalizar todas las etapas para corregirlo. Es por ello que hay que realizar bien las actividades desde la primera vez, o también conocido como RFT.
34
Figura 6. Estrategias de pruebas.
Fuente: Revista española de electrónica, en [3]
2.1.4 Descripción del proceso de pruebas no funcionales. Las actividades a desarrollar para la aplicación de pruebas no funcionales del software a implementar, son las siguientes: - Planeación de las pruebas, se debe realizar desde el mismo momento en que se definen fechas de entrevistas con el cliente para definir los requisitos. Uno de los principios básicos que se debe tener en la planificación de pruebas de software es designar los recursos apropiados para la ejecución de las pruebas, determinar los grupos de personas que van a participar en las pruebas y estimar el calendario de las pruebas, siendo todo esto de gran utilidad para los ingenieros de software.
35
La planeación de pruebas logra enfocar al grupo que realiza estas cual es la situación aplicativo y así prepararlos a los diferentes tipos de pruebas que se van a emplear. Los planes de pruebas están constituido por un conjunto pruebas, en donde se determina que atributos de pruebas se desean llevar acabo como la fiabilidad, usabilidad, entre otros. El plan de pruebas tiene los siguientes elementos: -Identificador del plan -Alcance -Ítems a probar -Estrategias -Categorización de la configuración -Documentación -Procedimientos especiales -Recursos -Calendario -Riesgos -Responsables
36
Tabla 3. Estándar de la IEEE 829-1983.
Fuente: Plan de pruebas, en [4]
- Diseño de las pruebas29 Las pruebas pueden ser planteadas por componentes o módulos, de tal forma que se inicie desde lo más pequeño hacia lo más grande e integrado El diseño de los casos de pruebas se hace con el principal objetivo de buscar una gran cantidad de errores, en un plazo corto y con el mínimo esfuerzo. Con el diseño de estos casos de pruebas se determina cuales son los mejores procedimientos a seguir, las técnicas a emplear y sus medidas que aplicar. En estas también se miran los datos a ingresar y las respectivas salidas que están tendrán.
29
Proyecto de grado, plan de negocios para la creación de servicio y asesoría de pruebas de software. Web-
http://recursosbiblioteca.utp.edu.co/tesisdigitales/texto/65811M828.html
37
La realización del diseño de los casos de pruebas tiene un objetivo más, en el cual se busca determinar si estas cumplen con la verificación y validación de los requerimientos no funcionales. Los productos de software se pueden probar utilizando dos criterios los cuales son:
El conocimiento del funcionamiento del producto, este se efectúa aplicando las pruebas de caja blanca.
El conocimiento de la función especifica para la que fue diseñado el producto, este se realiza por medio de las pruebas de caja negra. - Ejecución de las pruebas, se deben ejecutar antes de iniciar el desarrollo y se debe definir criterios de finalización del proceso de pruebas, Idealmente se da por finalizado cuando los casos de pruebas son ejecutados y se han corregido los errores hallados. Ejecutando nuevamente los casos de pruebas, usando o no los mismos datos, pero buscando garantizar la eliminación del error, defecto o falla. Y verificando que no se hayan generado nuevos. Otro criterio de finalización para este proceso es el número de ciclos de pruebas
- Control, seguimiento y retroalimentación Es decir que inicialmente se debe definir un plan de pruebas, estableciendo los artefactos a probar, el alcance, asignando recursos, luego establecer los casos de pruebas a ejecutar. Realizando posteriormente un ciclo de pruebas, de tal forma que éste será exitoso si se haya errores. Finalmente será un buen proceso o en particular un buen caso de prueba, si detecta defectos, errores, o fallas antes no halladas en el producto. Pero si por el contrario, al finalizar el proceso de pruebas no funcionales, no se encuentran errores, será un proceso que habrá agregado sólo costos y pérdidas de tiempo en el proyecto.
38
Es fácil desviarse del objetivo principal de las pruebas no funcionales, como ya se había mencionado antes, ya que se puede visualizar como que su prioridad es la de demostrar que no hay errores de este tipo, es decir, que toman como el proceso exitoso al no hallar errores, fallas o defectos, estando en una total equivocación. El ejemplo más claro lo presentan los desarrolladores, puesto que éstos al ejecutar sus pruebas unitarias, se conocen el camino común y sin errores, saltando sobre los mismos, una y otra vez, es decir, que no están buscando los errores, sino que están demostrando que el software funciona correctamente y por tanto que corresponde a una confiabilidad total del mismo. Sin embargo, el ejecutar el ciclo y casos de pruebas, no garantizan la ausencia de errores en el producto desarrollado, es decir, no se certifica que los defectos desaparezcan en su totalidad, ya que sus causas son múltiples. Dentro de dichas causas de los errores, se encuentran los relacionados con la tecnología elegida, es decir, no realizar una elección correcta de la herramienta de desarrollo, fallas en el estudio de viabilidad, mala distribución de recursos del proyecto, la equivocada asignación de roles, la mala comunicación entre el equipo de trabajo, también debido a la poca experiencia del desarrollador, es decir, falta de conocimiento, o por el contrario por demasiada experiencia, lo que genera confianza en sí mismo, obviando errores por creer que no ocurrirán. Por otra parte, quien debe realizar las pruebas, no debe ser el mismo personal involucrado en el desarrollo del producto, ya que éstos no guardan una madurez lo suficientemente firme, como para criticar de forma constructiva su propia creación, además no visualiza más allá de lo que ya conoce del producto, lo cual genera que siempre ejecute el mismo curso, obviando caminos distintos, por donde posiblemente se encuentren fallas, errores, defectos. El proceso de pruebas es más productivo si es realizado por personal que conoce la lógica del negocio y del proyecto, con facilidades de adaptar su experiencia al proceso. Mientras que en el proceso de depuración, la presencia del autor del producto, es decir, del desarrollador, es una parte fundamental. En cuanto a las entradas del proceso de pruebas, se debe establecer una bitácora de datos, los cuales no deben ser datos reales, acatando la circular externa 052
39
del 2007, ―No utilizar datos de producción en los ambientes de pruebas‖30. Esta bitácora de datos permite visualizar distintas situaciones. Cada entrada es conocida como caso de prueba, el cual debe tener definidas los objetivos, tanto las respuestas esperados, como las equivocadas, por cada caso de prueba. Los ingenieros probadores o tester son quienes toman los requerimientos como
base para desarrollar las pruebas de verificación y validación para el sistema. Por
lo tanto son los encargados de definir los casos de pruebas, los cuales deben
tenerlos bien documentados, teniendo un conocimiento previo del producto e
informándose con el equipo desarrollador.
2.1.5 Desarrollo de caso de prueba El caso de prueba permite a la persona encargada de probar la aplicación, definir si el producto cumple con los requerimientos establecidos. Para esto no se tiene una plantilla establecida como estándar, algunos ítems que se recomiendan tener en cuenta al realizar un caso de prueba son los siguientes: - Id caso de prueba - Módulo a probar - Descripción del caso - Pre-Requisitos - Data necesaria (valores a ingresar) - Pasos o secuencia lógica - Resultado esperado (Correcto o Incorrecto) - Resultado Obtenido - Observaciones o comentarios - Analista de Pruebas (Responsable de las pruebas) - Fecha de ejecución - Estado (concluido, pendiente, en proceso)
30
. Superintendencia financiera de Colombia. Web-http://www.netsecuritysuite.com/pdf/Norma-052.pdf .Circular externa
052 del 2007
40
Tabla 4. Plantilla recomendada para caso de prueba.
Campo a diligenciar
Id caso de prueba
Nombre de caso de prueba
Descripción
Precondiciones
Relaciones de caso de uso
Pasos y condiciones ejecución
Resultado esperado
Estado de caso de prueba
Resultado obtenido
Errores asociados
Responsable del diseño
Responsable ejecución
Comentarios
Plantilla para casos de pruebas
Fuente: Plantilla para caso de prueba, en [5].
41
3.MÉTODOS DE PRUEBAS.
Aunque existen dos tipos de métodos de pruebas, los estáticos y los dinámicos, se orientarán hacia su aplicación a atributos no funcionales para esta monografía. Por ende se explican los niveles de pruebas y los actores respectivos. -Niveles pruebas del modelo Algunos de los niveles de pruebas que existen son las pruebas unitarias, integración, sistema y aceptación. Pruebas unitarias: son las que realiza el desarrollador del producto. Pruebas de Integración: son realizadas por el desarrollador del producto Pruebas de Sistema: las realiza el equipo de pruebas. Pruebas de Aceptación-Usuario: se realiza al final de todas las pruebas antes mencionadas, cuando el producto se encuentra listo.
42
Tabla 5. Niveles de pruebas.
Pruebas Objetivos Integrantes Ambiente Método
Unitarias
Encontrar errores
de logica y
algoritmosProgramadores Desarrollo Caja Blanca
Integración
Encontrar errores
de interfaz y las
relaciones
existente entre los
componentes
Programadores Desarrollo
Caja Blanca,
Ascendente,
Descendente
Funcional
Encontrar errores
en la
implementación
de requerimientosTester,Analistas Desarrollo Funcional
Sistema
Encontrar fallas en
los requerimientos Tester,Analistas Desarrollo Funcional
Aceptación
Encontrar falla en
la implementacion
del sistemas
Tester,Analistas,
ClienteProductivo Funcional
Niveles de Pruebas
3.1 MÉTODOS ESTÁTICOS 3.1.1 Inspecciones. Las inspecciones de software son conocidas en el mundo como inspecciones de código, estas surgieron en IBM donde se lleva un registro a los problemas que se presenta en el software, como los errores o defectos que tenga el aplicativo. -Inspecciones Formales de usabilidad Los métodos de inspección cuentan con 4 hasta 8 inspectores, donde se delegan roles a cada uno de estos. Luego que se designan los roles se reparten ―los documentos del diseño a inspeccionar y las instrucciones pertinentes‖, 31 donde cada uno tiene asignados unos objetivos y propósitos, basados en las necesidades del usuario, cada uno debe dar cumplimiento con su labor individual.
31
Inspecciones. Web-http://www.sidar.org/recur/desdi/traduc/es/visitable/inspeccion/FUInsp.htm
43
Los datos recolectados serán informados o intercambiados en reuniones formales, así, cuando se ha encontrado los defectos por el equipo inspector, serán pasados al equipo diseño. El equipo de trabajo de las inspecciones formales es conformado por personas que estén en el proyecto como en la parte de diseño, desarrollo, documentación, supervisión, calidad, entre otros. En las reuniones formales que se realizan, cada inspector deberá asumir uno de los siguientes roles:
Moderador: son los encargados de pasar los materiales solicitados y recogerlos, planificar las reuniones laborales, y delegar funciones para las respectivas correcciones de los defectos.
Propietario: este es el que diseña el sitio web y se le delegan las respectivas modificaciones de defectos que se encontraron.
Secretario: toma un documento formal el cual tiene los defectos usabilidad planteados en las reuniones laborales realizadas.
Inspector: las personas faltan pueden tomas varios roles, los cuales son inspeccionar el diseño presentando documentación de las deficiencias La asignación de documentos de trabajo entre los inspectores, son los siguientes32 : - Descripciones del site. - Pantallas con sus correspondientes distribuciones de objetos. - Perfiles de usuarios. - Tareas de usuario. - Heurísticos a usar. - Formulario de recogida de deficiencias de usabilidad. 32
Inspecciones. Web-http://webusable.com/useTechniques_B.htm
44
Estas técnicas de inspección se pueden realizar usando diferentes medios de evaluación, entre ellos los siguientes: - Evaluación Heurística: las personas encargadas de los aspectos de la usabilidad determinan la interfaz de usuario, ya sea de algún sitio web y ―luego lo evalúan contra una lista de principios heurísticos mayoritariamente aceptados‖ 33. Se ha determinado que 5 inspectores de usabilidad detectan un 80% de los defectos de una aplicación web, mientras 15 inspectores podrían determinar un 100%. Para la evaluación se establecen unas categorías en donde colocan los problemas dándoles así una clasificación, y cada uno de los inspectores analiza estos sin intercambiar ideas. Las evaluaciones heurísticas se pueden ejecutar en cualquiera de las fases del ciclo de vida, pero son de gran aporte al principio de este ciclo. - Ensayo cognoscitivo: los evaluadores son personas con un alto grado de experiencia donde recrean los escenarios de acuerdo a las especificaciones del sitio web, además se ponen en la posición del usuario a través analizando cada una de las interfaces que hay de usuarios. - Ensayo Pluralista: se realizan reuniones con los desarrolladores, diseñadores, usuarios y expertos de usabilidad, donde estos últimos son los que las coordinan para tratar temas acerca de las respectivas funciones que realiza el usuario en el sitio web y sobre las interfaces de usuario 3.1.2 Walkthroughs (Paseos cognitivos). Son revisiones que se llevan a cabo sin la ejecución de código. 3.2 MÉTODOS DINÁMICOS
33
Inspecciones. Web-http://webusable.com/useTechniques_B.htm
45
3.2.1 Pruebas de unidad. ―Se puede decir que una prueba unitaria es una actividad mediante la cual se ejecuta un proceso a partir de unos datos de entrada, que son los casos de prueba, y que llega a una salida determinada, buscando detectar los posibles defectos de su interior‖34. Se ejecutan hasta alcanzar un nivel definido como óptimo. Se dividen en pruebas de caja negra y de caja blanca, donde la primera es realizada por el personal de desarrollo, y está orientada a demostrar que cumple con cada función operacional, mientras se buscan los errores de cada función, y la segunda busca asegurar que las operaciones procedimentales y codificadas correspondan a las especificadas. No se analiza este tipo de pruebas, ya que su aplicación al producto software no aporta a la calidad de los requerimientos no funcionales. Puesto que ésta centra sus esfuerzos en verificar la lógica del procesamiento interno del software. 3.2.2 Pruebas de integración. Este tipo de pruebas es aplicable para aquellos productos desarrollados por componentes o módulos. Se realiza para garantizar que al integrar dichos módulos funcionen según lo especificado, probando hallar los errores asociados al proceso de ensamblaje, para comprobar sus interfaces en el trabajo en conjunto. - Pruebas de integración ascendente Estas pruebas empiezan desde el modulo inferior hasta llegar al modulo superior de la jerarquía. A medida que las pruebas avanzan desde el nivel inferior hasta el superior se reducen el número de pruebas que se realizan por separado. Algunas de las ventajas que se encuentran en las pruebas ascendentes son las desventajas de las pruebas descendentes y viceversa. La selección de la prueba ya sea descendente o ascendente depende primordialmente del producto a desarrollar y en otras ocasiones del plan que se tenga del proyecto. - Pruebas de integración descendente
34
AGUIAR FERNÁNDEZ , María del Mar. Ingeniería del software y pruebas.. Revista española de electrónica. Septiembre
2000. 94p. Número 550.
46
Esta se realizan empezando desde el modulo principal hasta llegar a los módulos inferiores en jerarquía. Las pruebas se encuentran manejado por el modulo de control principal y estas a su vez estas se van desplazando a módulos inferiores, se debe tener en cuenta que las pruebas se realizan cada vez que un nuevo modulo ingrese o se cree. En estas pruebas se pueden generar problemas en los resultados, si el un modulo de jerarquía superior depende de los cálculos realizados por módulos de jerarquía inferior y estos producen fallas, el tester o encargado de realizar las pruebas tendrá un retraso en el tiempo para las otras pruebas hasta encontrar las fallas de los módulos faltantes. 3.2.3 Pruebas de sistema. Tienen como objetivo principal hallar los errores en integración. Son aplicables a los cinco atributos de calidad de software. - Pruebas de validación alfa Éstas se pueden iniciar posteriormente a la culminación de las pruebas de integración, si fueron realizadas, y se centran principalmente en las acciones visibles para el usuario, y en la salida del sistema que éste puede reconocer. Se realizan para comprobar si el software ensamblado, da cumplimiento a requerimientos de eficiencia, portabilidad, usabilidad, Mantenibilidad, fiabilidad. - Pruebas de validación beta Estas pruebas son realizadas en el equipo que va a quedar finalmente instalada la aplicación, en donde esta será probada directamente por usuario final y no tendrá control sobre esta el desarrollador. Los clientes se encargan de comunicar los problemas encontrados a los desarrolladores, los cuales tomaran las precauciones para corregir los problemas presentados en la versión beta. Después de corregir estos problemas en la aplicación, se sacara otra versión nueva al mercado mejorada para diferentes clientes.
47
-Pruebas de desempeño Diseñadas para probar el sistema en tiempo de ejecución en ambientes contextualizados al real. Éste tipo de pruebas proveen información acerca de lugares donde se generan los cuellos de botella del sistema. Son realizadas en cualquier nivel de desarrollo, es decir, se debería evaluar cada módulo individual. Sin embargo, esto no garantiza que el sistema quede estable, es por ello, que se espera hasta la integración de la arquitectura software que se realiza, puesto que es allí donde se puede asegurar el verdadero desempeño del producto software. - Pruebas de tensión o stress Con este tipo de pruebas se busca llevar al límite la capacidad de tolerancia del sistema, a través de diversas formas, puede ser, iniciando sesión con una cantidad de usuarios al sistema, y ―si el sistema debe gestionar x mega – bits por segundo de una línea de comunicaciones, probar a aumentar ese ancho de banda‖35 de tal forma que se llegue a un dato que indique dicho límite del sistema. Se enfrenta el sistema a situaciones anormales, es decir, enfrentarlo a peticiones de usuario con una frecuencia definida, para determinar su uso de recursos en dichas circunstancias y su reacción ante la misma. Busca sobrecargar el sistema, para hallar estados de inestabilidad o procesamiento inapropiado. 3.3 ATRIBUTOS DE CALIDAD DEL SOFTWARE QUE SON EVALUABLES AL APLICAR PRUEBAS NO FUNCIONALES A continuación se describe la jerarquía de los requisitos no funcionales en la figura:
35
RAMÓN ÁLVAREZ, José - ARIAS CALLEJA, Manuel. Análisis, diseño y mantenimiento del software.Departamento de
Inteligencia-Artificial–ETSI-Informática-UNED. Web- http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node49.html. Consulta [20/09/2011]
48
Figura 7. Jerarquía de requisitos no funcionales.
Fuente: Requisitos no funcionales, en [6]. Figura 8. ISO/IEC 9126.
Fuente: Calidad de componentes software, en [7].
Al analizar la jerarquía de requerimientos no funcionales y al realizar una integración de lo establecido en la ISO/IEC 9126 – Calidad del producto de software, la cual define seis categorías de requerimientos, como se puede observar en la figura 2, los cuales garantizan la calidad del software, donde cada uno a su vez tiene asociados diferentes requerimientos no funcionales, lo que según Ian Sommerville, en su libro Ingeniería de requerimientos séptima edición, define los mismos como requerimientos del producto y el modelo FURPS+, los
49
establece como cinco categorías, siendo los mismos requerimientos. De lo anterior se determinan las categorías y atributos que interesan para la actual monografía. - Funcionalidad - Usabilidad - Eficiencia - Fiabilidad - Portabilidad - Mantenibilidad A partir de los requerimientos antes mencionados, exceptuando el requerimiento
de funcionalidad, puesto que no entra en el alcance de éste proyecto, se procede
a describir los atributos principales que se pueden llegar a medir a una medición
del nivel de aporte de los distintos tipos de pruebas mencionados en el numeral
3.1 y 3.2, de tal forma que se pueda inferir su aporte hacia la calidad del producto
software desarrollado.
Entendiéndose como atributo, aquella entidad que tiene un producto software, que
posee la característica de poder ser verificada o medida. Donde la medición
implica asignar un valor a dicha entidad.
Dichos atributos no se encuentran definidos como estándares ya que se
diferencian entre uno y otro producto software, dependiendo de la lógica del
negocio y por tanto del producto que se requiere desarrollar.
Debido a la dificultad para identificar y cuantificar con objetividad dichos atributos no funcionales, es por ello que se requiere conocer las técnicas para medirlos, de tal forma que se pueda intentar estudiar el impacto de los mismos sobre la calidad del software, independiente del modelo o metodología de desarrollo. Finalmente, estos atributos son evaluados de forma subjetiva, debido a su difícil identificación en la recolección de requerimientos, ya que su levantamiento se realiza de igual forma para los funcionales como para los no funcionales. Es por ello que la identificación de errores en producción, relacionados a estos atributos, según la experiencia de empresas reconocidas, son los más difíciles de resolver estando ya en operación y afectando unos altos costos.
50
Adicionalmente, se hace necesario reconocer la alta dificultad para independizar los requerimientos funcionales de los no funcionales, ya que esto también depende del nivel de detalle al que se quiera llegar en su recopilación. 3.3.1 Características evaluables del requerimiento de Fiabilidad
Tabla 6. RFN fiabilidad.
Requerimiento (Categoría) Características evaluables
Recuperabilidad
Frecuencia de fallas
Disponibilidad
Severidad de fallas
Fiabilidad
Características evaluables
Relacionado a la capacidad de la aplicación para recuperarse en el menor tiempo
ante la ocurrencia de una falla del sistema, además de garantizar no perder datos
en el envió hacia el servidor o hacia los clientes.
De este atributo se derivan las características de disponibilidad.
Madurez: Capacidad del producto software para evitar fallar como resultado de
fallos o defectos en el software.
Recuperabilidad: Capacidad del producto software para reestablecer un nivel de
desempeño especificado y de recuperar los datos afectados luego de la ocurrencia
de una falla
51
Tolerancia a fallos: Capacidad del software para mantener un nivel especificado
de desempeño en caso de fallos del software o de infringir sus interfaces
especificados.
Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a
normas, convenciones o regulaciones relacionadas con al fiabilidad.
3.3.2 Características evaluables del requerimiento de Portabilidad
Tabla 7. RFN portabilidad
Requerimiento (Categoría) Características evaluables
Adaptabilidad
Instalabilidad
Facilidad de adaptación al cambio
Co - existencia
Portabilidad
Características evaluables
Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes
entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos
proporcionados para este propósito por el propio software considerado.
Instalabilidad: Capacidad del producto software para ser instalado en un entorno
especificado.
Coexistencia: Capacidad del producto software para coexistir con otro software
independiente, en un entorno común, compartiendo recursos comunes.
Capacidad para reemplazar: Capacidad del producto software para ser usado en
lugar de otro producto software, para el mismo propósito, en el mismo entorno.
52
Cumplimiento de la portabilidad: Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la portabilidad.
Como en todo proceso responsable se debe definir la(s) persona(s) responsable(s) de hacer la planeación de la medición de los atributos, encargados también de hacer pública esa planeación, buscando la aceptación, compromiso del equipo de trabajo, y solicitando al líder del proyecto, la asignación del recurso tecnológico, humano, presupuestal.
3.3.3 Características evaluables del requerimiento de Eficiencia
Tabla 8. RFN eficiencia.
Requerimiento (Categoría) Características evaluables
Tiempo de respuesta
Desempeño
Tráfico generado en las comunicaciones
Tiempo de recuperación a fallas
Utilización de recursos (Memoria)
Eficiencia
Características evaluables
Comportamiento temporal o en relación al tiempo: Capacidad del producto
software para proporcionar tiempos de respuesta, tiempos de procesamiento y
velocidad en la ejecución de funciones, bajo condiciones determinadas.
Comportamiento en relación al uso de recursos: Capacidad del producto software
para usar las cantidades y tipos de recursos adecuados cuando el software lleva a
cabo su función bajo condiciones determinadas.
Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la eficiencia.
53
De este atributo se derivan las características de rendimiento, escalabilidad.
Características que enmarcan entre otros, los tiempos de respuestas solicitados
por el cliente, capacidades de ofrecer un servicio de acuerdo lo solicitado.
Es también pertinente recordar el concepto de requerimientos de desempeño para
un sistema, el cual se define como que ―Un sistema con buen desempeño es
aquel que realiza su función en el menor tiempo posible y utilizando la menor
cantidad de recursos. Para efectos prácticos, y a pesar de las diversas categorías
de requisitos de desempeño que pueden existir, los desarrolladores que
construyen sistemas en los cuales el desempeño es un requisito importante, se
enfocan fundamentalmente en la velocidad a la cual el sistema puede realizar su
función, teniendo en cuenta los recursos finitos y sus características de Calidad
del software‖36.
Al momento de probar este atributo, se evalúa la conformidad del sistema o
componente con respecto a los requerimientos de desempeño de este tipo
especificados.
Generalmente se llevan a cabo la aplicación de pruebas a éste requerimiento,
usando herramientas de pruebas automáticas (scripts o robots). Puesto que para
valorar éste atributo es necesaria la simulación de altas cantidades de
transacciones al tiempo, simulando carga y volumen de información, buscando
monitorear el desempeño del aplicativo frente a esto.
Se ejecutan sobre los procesos críticos del aplicativo. Donde los procesos críticos
deben ser definidos por el director del proyecto y el equipo de trabajo.
3.3.4 Características evaluables del requerimiento de Mantenibilidad
36
SERNA, Sergio. Especificación formal de requisitos temporales no funcionales. Web-
http://www.bdigital.unal.edu.co/3928/1/98553427_2011_1.pdf. Consulta [21/09/2011]
54
Tabla 9. RFN Mantenibilidad.
Requerimiento (Categoría) Características evaluables
Analizabilidad
Facilidad de cambio
Facilidad de prueba
Estabilidad
Mantenibilidad
Características evaluables
Capacidad para ser analizado: Es la capacidad del producto software para serle
diagnosticadas deficiencias o causas de los fallos en el software, o para identificar
las partes que han de ser modificadas, es decir, es el grado de complejidad para
diagnosticar deficiencia y causas de falla
Capacidad para ser modificado: Capacidad del producto software que permite que
una determinada modificación sea implementada.
Estabilidad: Capacidad del producto software para evitar efectos inesperados
debidos a modificaciones del software.
Capacidad para ser probado: Capacidad del producto software que permite que el
software modificado sea validado, es decir, facilidad de ser probado
Cumplimiento de la mantenibilidad: Capacidad del producto software para
adherirse a normas o convenciones relacionadas con la mantenibilidad.
3.3.5 Características evaluables del requerimiento de Usabilidad
55
Tabla 10. RFN Usabilidad.
Requerimiento (Categoría) Característicasevaluables
Operabilidad
Aprendizaje
Atractividad
Comprensibilidad
Usabilidad (Usability)
Características evaluables
Capacidad para ser entendido: Capacidad del producto software que permite al
usuario entender si el software es adecuado y cómo puede ser usado para unas
tareas o condiciones de uso particulares.
Capacidad para ser aprendido: Capacidad del producto software que permite al
usuario aprender sobre su aplicación.
Capacidad para ser operado: Capacidad del producto software que permite al
usuario operarlo y controlarlo.
Capacidad de atracción: Capacidad del producto software para ser atractivo al
usuario.
Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a
normas, convenciones, guías de estilo o regulaciones relacionadas con la
usabilidad.
En la actualidad se ha avanzado con respecto a concienciar sobre la importancia
de realizar pruebas a este factor de calidad, así lo indican Beatriz E. Florián,
Oswaldo Solarte, Javier M. Reyes, de la Escuela de Ingeniería de Antioquia, al
56
afirmar que “las pruebas y evaluaciones durante el desarrollo del producto han
ganado amplia aceptación como estrategia para mejorar la calidad del
producto‖37. Es decir, que ya se considera como uno de los atributos
fundamentales para alcanzar el éxito de un proyecto. Lo cual ha generado ―un
interés creciente en el mundo del desarrollo de software como factor de calidad‖38.
Sin embargo, aunque se reconozca la importancia de lograr un producto de
software de calidad en el uso, no ha sido fuerte su difusión, lo que conlleva a que
dicho proceso aún no sea un factor incondicional en el ciclo de desarrollo software.
Por otra parte no es de desconocer que la aplicación de pruebas a este factor de
calidad del software, al ser realizado en etapas tempranas del desarrollo, como lo
es en levantamiento de requisitos, diseño del software y posteriormente la
ejecución de prueba de usabilidad, finalizando con la verificación de la interfaz,
proporciona al producto mejoras visibles en cuanto a calidad, tanto para
desarrolladores como para probadores (Tester).
Entre tanto para valorizar la usabilidad, se hace necesario describir brevemente las estrategias de clasificación de usuarios, debido a la necesidad de identificas según el orden jerárquico de desempeño de los mismos, frente a las herramientas computacionales39, teniendo en cuenta que el usuario hace parte fundamental del proceso de desarrollo y sus ideas son valiosas para valorar este atributo, buscando obtener a lo largo del desarrollo una retroalimentación por parte de éste. - Estrategia de conocimiento y experiencia: Basada en el uso de las herramientas computacionales - Estrategia de estructuración de las tareas de interacción: Basada en los modelos mentales de los usuarios con respecto al uso de las tecnologías en su trabajo.
37
Revista EIA. Escuela de Ingeniería de Antioquia, Medellín (Colombia). Julio 2010. 123p .Numero 13. ISSN 1794-1237. 38
FERRÉ, 2003; CHEIKHI, Abran y SURYN, 2006. 39
SHNEIDERMAN y PLAISANT. 2006
57
Grupos de usuarios de pruebas: - ―Usuario novato o inexperto: Es aquel cuyo nivel de conocimiento en uso de herramientas computacionales es bajo, es decir, que dentro de sus actividades cotidianas, su interacción con aplicativos se encuentra entre 0% y 20%. - Usuario intermedio: Es aquel cuyo nivel de conocimiento e interacción con aplicativos, se encuentra entre un 20% y un 80%. - Usuario avanzado: Es aquel cuyas actividades cotidianas le exigen estar en interacción con aplicativos, entre 80% y más. - Desarrollador: Se propone al desarrollador como un integrante más del proceso de evaluaciones de usabilidad. Para evitar las observaciones técnicas que se alejan un poco de los criterios de interacción humano – computador (IHC). - Auditor: Es quien realiza la verificación del sistema desde el punto de vista funcional, pero teniendo en cuenta criterios de usabilidad. Es el experto en usabilidad, que además debe tener conocimientos en ingeniería del software y en las tecnologías utilizadas en el desarrollo del producto. El auditor no participa en las etapas de análisis e implementación del software. Permite que la evaluación se desarrolle de una manera menos subjetiva y evita la posibilidad de tener apreciaciones que estén descontextualizadas respecto a la interacción de los usuarios potenciales con la aplicación―40. Métodos de evaluación del atributo de usabilidad.
Existen métodos empíricos y no empíricos, dentro de los que se conciben los
siguientes métodos:
- Métodos de análisis: En ésta se busca observar la facilidad con que los usuarios
realizan determinadas operaciones en el aplicativo. 40
Revista EIA.Escuela de Ingeniería de Antioquia, Medellín (Colombia). Julio 2010.127p. Numero 13.ISSN 1794-1237
58
- Métodos de inspección: Principalmente se busca evaluar la interfaz
- Métodos de indagación: se busca ―obtener información con respecto a los
gustos, disgustos, necesidades y comprensión del sistema de parte de los
usuarios‖41.
Adicionalmente, como forma de valoración de este factor se usan también las
evaluaciones heurísticas y las pruebas de usuario. En donde las primeras hacen
parte de los métodos no empíricos, proporcionando la visión que posee el
desarrollador sobre la interfaz, mientras que las segundas, hacen parte de los
métodos empíricos totalmente, permitiendo obtener la visión que posee el
usuario sobre la interfaz. Aunque ambas pertenezcan a métodos diferentes,
forman un complemento ideal de retroalimentación, permitiendo alcanzar una
mayor calidad en la definición de la interfaz requerida.
Tao establece un modelo con base en estados de máquina y heurísticas de
usabilidad. Donde los estados de máquina permiten modelar la interacción del
usuario con el aplicativo, mientras que la heurística de usabilidad aporta mejoras
en el diseño en las interfaces de usuario.
Por otro lado, Singh incluye pruebas de usabilidad en la metodología ágil
SCRUM, lo que definió como U-SCRUM, en la cual propone como artefactos a
probar, ―los roles de usuario, la visión de experiencia de usuario y el plan del
producto‖. Se tiene también la propuesta de Granollers et al (2005), de Juristo,
Moreno y Sánchz – segura (2007), y Aveledo, de la Rosa y Moreno (2008).
En la tabla 8, se encuentran la plantilla o lista de chequeo para evaluar la
usabilidad, la cual contiene por cada etapa de desarrollo (Ingeniería de requisitos,
análisis y diseño, codificación y pruebas, pruebas con usuarios, y verificación), las
actividades propuestas por cada etapa, donde cada actividad se relaciona a uno o
41
Revista EIA. Escuela de Ingeniería de Antioquia, Medellín (Colombia). Julio 2010.125p. Numero 13.ISSN 1794-1237
59
varios artefactos entregables, quienes a su vez cada uno tiene asignado un
identificador. Finalmente esta plantilla permite realizar una evaluación consistente
y objetiva hacia el atributo de usabilidad.
Adicionalmente, se cuenta con unos actores involucrados en cada etapa del
proceso de desarrollo de software, los cuales a su vez tienen asignados unas
responsabilidades con respecto a los artefactos establecidos.
Para la propuesta, cada etapa genera unos resultados, los cuales se toman como
entradas para la etapa siguiente. Donde dicho ciclo de desarrollo se toma de
forma cíclica e iterativa, beneficiándose por las retroalimentaciones que se
generan por cada ciclo de ejecución.
En esta propuesta para el evaluador, se valoran las características de usabilidad
de la plantilla, según el nivel de realización o nivel de cumplimiento desde 1 – poco
importante, hasta 5 – Fundamental. No se define como nivel de cumplimiento
valorado 1 o 0, es decir, un si cumple o no cumple, puesto que esto es radical,
generando resultados imprecisos. Además para el evaluador se asigna un peso a
cada característica de usabilidad de la plantilla, según el nivel de importancia,
desde 0 – La característica no se cumple en absoluto, 100 – La característica se
cumple por completo, proporcionando un indicador de cada característica
evaluada desde el punto de vista de los evaluadores de la interfaz.
Con la justificación de la calificación se busca hallar las causas de las valoraciones
altas, bajas, según el nivel de cumplimiento y la ponderación de importancia
asignada por el usuario.
60
Tabla 11. Esquema general de las listas de chequeo modificadas.
Característica de
usabilidad por
comprobar
Ponderación de
importancia 1 (poco), 5
(fundamental)
Nivel de
cumplimiento
(0 -100)
Justificación
Pregunta que
indaga sobre el
cumplimiento de
una características
de usabilidad
Opción 1
Opción N
.
.
.
Fuente: Revista de la Escuela de Ingeniería de Antioquia, en [8].
61
Fuente: Revista de la Escuela de Ingeniería de Antioquia, en [8].
Tareas de usabilidad Artefactos entregables
Revisión de escenarios actuales o
deseados (usuarios, tareas, ambientes)
Descripción de características de
usabilidad deseadas
Definición de las funciones del software
con mayor impacto en las tareas de los
usuarios
Definición de requisitos de uso y su
validación
Modelado para la especificación del
contexto de uso (MEC)
Lista de características de usabilidad para
tener en cuenta dentro del desarrollo
(LCU)
Documento de requisitos validado
teniendo en cuenta aspectos de
usabilidad (DRV)
Documento de priorización de requisitos
de usabilidad del producto (DPR)
Diseño de escenarios y tareas de los
usuarios (diseño de interacción)
Diseño de la ayuda
Diseño de listas de chequeo de
usabilidad (Plantillas)
Especificación funcional del producto con
énfasis en el diseño detallado de la
interacción (EF)
Diseño de la interfaz de usuario (DIU)
Plantillas de las listas de chequeo (PLC)
Implementación de las interfaces de
usuario
Validación de los prototipos del
software contra la especificación,
utilizando las listas de chequeo y la lista
de características de usabilidad para
tener en cuenta
Reporte de la evaluación de usabilidad
realizada por los desarrolladores (REUD)
Diagnósticos de los defectos de
usabilidad (DDU)
Lista de inconformidades para ser
depuradas (LID)
Interfaz de usuario validada y depurada
(IUV)
Validación de funciones teniendo en
cuenta aspectos de usabilidad utilizando
listas de chequeo
Resultados de las pruebas de usabilidad
realizadas por los usuarios (RPUU)
Diagnósticos de los defectos de
usabilidad (DDU)
Lista de inconformidades para ser
depuradas (LI)
Verificación de funciones teniendo en
cuenta aspectos de usabilidad utilizando
listas de chequeo
Resultados de las evaluación de
usabilidad realizadas por los auditores
del sistema (REUA)
Diagnósticos de los defectos de
usabilidad (DDU)
Lista de nuevos requisitos de usabilidad e
inconformidades (LI)
Ingeniería de requisitos (Análisis del negocio, especificación de requisitos
funcionales y no funcionales, validación de requisitos)
Análisis y diseño (Subsistemas, componentes, módulos de software, diseño de
Codificación y pruebas (Código fuente, ejecución de pruebas de los
Pruebas con usuarios (Ejecución de pruebas α y β con usuarios seleccionados)
Verificación (Verificación funcional, verificación del producto, verificación del
Tabla 12. Tareas y artefactos de usabilidad propuestos.
62
3.4 ANÁLISIS DEL PAPEL ASIGNADO A LAS PRUEBAS NO FUNCIONALES EN LAS METODOLOGÍAS ÁGILES Y EN LAS METODOLOGÍAS TRADICIONALES. 3.4.1 Pruebas no funcionales según Metodologías ágiles. Las metodologías agiles asigna más responsabilidades a su grupo de trabajo y una continua comunicación con el cliente, donde este brinda una colaboración. Esto se debe para tener una mejor efectividad en el desarrollo de los proyectos. Lo que se busca con estas metodologías ágiles es que se adapte a ambientes donde se presenten requerimientos cambiantes y los tiempos de entrega sean demasiado cortos, manteniendo así una alta calidad en sus productos. Estas metodologías agiles son muy criticadas por las personas que aun manejan metodologías tradicionales. Las metodologías tradicionales se caracterizan por ser muy rígidas y por su alta documentación en cada una de las actividades desarrolladas. El software sin documentación es un desastre, tanto en las metodologías ágiles como tradicionales, en donde las primeras documentan los procesos, si estos son de vital importancia, los cuales deben ser cortos y centrarse en lo fundamental. Las metodologías ágiles se encuentran orientadas más al cliente que a los procesos. XP es una las metodologías ágiles que han tenido gran a aceptación en el mundo de desarrollo de software, donde se cuenta con cuatro variables que son costo, tiempo, calidad y alcance. No hay una metodología, ya sea ágil o tradicional que proporcione una total garantía en el desarrollo de un proyecto de software cualquiera, debido a que se tiene que observar el ambiente donde se va a desarrollar este. Existen varias diferencias entre las metodologías agiles y las metodologías tradicionales las cuales se muestran a continuación:
63
Tabla 13. Diferencias entre metodologías ágiles y metodologías tradicionales.
Metodologías Ágiles Metodologías Tradicionales
Basadas en heuristicas
provenientes de practicas de
producción de código.
Basadas en normas provenientes
de estándares seguidos por el
entorno de desarrollo.
Especialmente preparadas para
cambios durante el proyecto.
Cierta resistencia a los cambios.
Impuestas internamente ( por el
equipo de desarrollo).
Impuestas externamente
Procesos menos controlados, con
pocos principios
Procesos mucho mas controlado,
con numerosas politicas/normas
No existe contrato tradicional o al
menos es bastente flexible.
Existe un contrato prefijado.
El cliente es parte del equipo de
desarrollo
El cliente interactúa con el equipo
de desarrollo mediante reuniones.
Grupos pequeños (<10
integrantes) y trabajando en el
mismo sitio.
Grupos granddes y posiblemente
distribuidos.
Pocos artefactos. Más artefactos.
Pocos roles Más roles.
Menos énfasis en la arquitectura
del software.
La arquitectura del software es
esencial y se expresa mediante
modelos. Fuente: Metodologías ágiles para el desarrollo de software: eXtreme Programming, en [9]. -Pruebas no funcionales según Metodología ágil XP (Programación Extrema) Metodología centrada en el trabajo en equipo, promovido por un buen clima laboral, excelente comunicación, sencillez para la codificación, y preocupación en el crecimiento personal de los profesionales implicados en el proyecto. XP busca que haya una mejor interacción con el cliente, con cual se debe estar en constante comunicación. XP se desenvuelve bastante bien en proyecto donde sus requerimientos son cambiantes e imprecisos.
64
Para XP las pruebas son inseparables del desarrollo42, y es por ello que XP
sugiere que a lo largo del ciclo de desarrollo se realicen test continuos, de tal
forma que sea posible la adaptación del producto a los cambios solicitados por el
cliente, y por tanto define que:
1. Desarrollado previamente probado
2. Desarrollo de pruebas incremental a partir de los escenarios
3. Participación del usuario en el desarrollo de las pruebas y en la validación
4. El uso de bancos de pruebas automatizados
Encargado de pruebas (Tester) ―El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.‖ 43
Encargado de seguimiento (Tracker) ―El encargado de seguimiento proporciona realimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones . También realiza el seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración.‖ 44
Programación dirigida por las pruebas (―Test-driven programming‖)
42
SOMMERVILLE, Ian. Ingeniería de software. Séptima Edición. Madrid, España: Pearson Educación S.A, 2005. 677 p 43
Metodologías ágiles para el desarrollo de software: eXtreme Programming (XP).Web -
http://www.willydev.net/descargas/masyxp.pdf 44
Metodologías ágiles para el desarrollo de software: eXtreme Programming (XP).Web -
http://www.willydev.net/descargas/masyxp.pdf
65
Ya sean pruebas funcionales o no funcionales en las metodologías ágiles como XP se cuenta con un diseño de pruebas bien estructurado antes de comenzar a desarrollar el producto, luego de esta fase el programador empezará a desarrollar la aplicación donde tendrá que hacer un esfuerzo para que su software pase el nivel requerido al aplicarse las pruebas diseñadas, es por esto que facilita al desarrollador a moldearse a los requerimientos que el cliente exige. Estas pruebas a las que se enfrenta el aplicativo desarrollado, son las pruebas unitarias, las cuales son diseñadas por otro integrante del equipo, donde cada módulo tiene que realizarlas para lograr su posterior liberación. - Detección y corrección de errores Cuando se encuentran un error (bug), inmediatamente es corregido por el equipo desarrollador, teniendo en cuenta la prevención de no volverlos a cometer. Luego de que el error fue eliminado se generan más pruebas para determinar si este fue eliminado en su totalidad. - Pruebas de aceptación Estas se consideran como pruebas de caja negra, donde se ingresan unos datos y se esperan unas determinadas salidas. En esta prueba se espera que el cliente sea que verifique si los resultas son los esperados. Si se hallan fallas en los resultados se deberá indicar cual tiene mayor prioridad, sin obviar a las otras. El fallo de estos resultados se debe informar al equipo para que tengan en cuenta lo sucedido. 3.4.2 Pruebas no funcionales según metodologías tradicionales - Metodología Rational Unified Process (RUP) Esta metodología se encarga de delegar tareas y responsabilidades su organización de desarrollo de software, contando con un numeroso grupo de programadores. Lo que se busca con RUP es tener un software de alta calidad
66
donde se satisfaga las necesidades de los clientes, con un calendario establecido y unos costos predecibles. Los procesos de esta metodología valoran las tareas y el calendario a través de la velocidad de iteraciones de acuerdo a las estimaciones originales. RUP cuenta con grandes ventajas frente a XP donde se hace realce en los requerimientos y su diseño. Su principal ventaja es que cuenta con buenas prácticas las cuales se prueban en el área desarrollada, contrario a XP ya que sus prácticas son inestables. La metodología RUP cuenta con cuatro fases las cuales son45: -Inicio: en esta se define el alcance del proyecto. -Elaboración: definición, análisis y diseño. -Construcción: implementación. -Transición: fin del proyecto y puesto en producción. Las fases de RUP se pueden descomponer en iteraciones, entendiéndose en este caso por iteración el ciclo de desarrollo completo en donde se obtendrá como resultado una aplicación ya sea interna o externa.
45
Metodología Rational Unified Process (RUP). Web -
http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/RUP%20vs.%20XP.pdf
67
Figura 9. Iteraciones de RUP
Fuente: Metodología Rational Unified Process (RUP), en [10] Figura 10. Miembros del equipo de RUP.
Fuente: Metodología Rational Unified Process(RUP), en [10]
68
Características de RUP -Cuenta con un detallado orden en el levantamiento de requerimientos. -Busca defectos en sus fases iníciales. -Procura disminuir en gran medidas los cambios. -Sigue un orden total en el análisis y diseño. -Las necesidades que presentan los clientes no son fáciles de comprender. -Una de las grandes diferencias con XP, es que se reúne con los clientes con citas formales, mientras que en XP hace parte del equipo de desarrollo. Los Test en esta evalúan la calidad que tiene el producto desarrollado, ―El papel del testeo no es asegurar la calidad, pero sí evaluarla, y proporcionar una realimentación a tiempo, de forma que las cuestiones de calidad puedan resolverse de manera efectiva en tiempo y coste.‖46 Los aspectos de fiabilidad, funcionalidad y el rendimiento, son algunos de los que busca RUP evaluar en los productos.
3.4.3 Metodología de pruebas en V
Figura 11. Relaciones entre productos de desarrollo y niveles de prueba.
Fuente: Metodología Rational Unified Process, en [10]
46
Metodología Rational Unified Process (RUP).Web-http://www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Trabajo-
Guia%20RUP.pdf
69
Este modelo tiene una gran ventaja por su intuición, ya describe los procesos del
ciclo de desarrollo contando en cada una de sus fases, con diferentes clases de
pruebas, es decir, se realiza el análisis y el desarrollo en paralelo con las pruebas.
El modelo V empieza por los requerimientos de los usuarios y a la vez se van
determinando los casos de prueba de aceptación que este va a tener, en la
siguiente fase del modelo se establece si cumple con las especificaciones y se
define cuales serán los primeros casos de pruebas de sistemas que se harán en
esta fase, ya cuando se a cumplido con la fase anterior se pasara a la próxima, la
cual es la fase de de modularidad del diseño y se generara un bosquejo de los
casos de pruebas de integración, luego de pasar todas las otras fases
mencionadas con sus respectivos casos de pruebas se analizaran los algoritmos y
establecerán los casos de prueba de unidad.
Una de las desventajas que tiene este modelo es que es muy detallado, en donde
la documentación que debe tener es demasiada y puede generar inconsistencias,
debido a los cambios que pueden generar los proyectos, siendo tedioso y
complicados corregirlos.
70
4. METRICAS PROPUESTAS PARA LA MEDICIÓN DE LOS REQUERIMIENTOS NO FUNCIONALES.
4.1 RECOPILACIÓN DE MÉTRICAS PARA ATRIBUTOS DE CALIDAD VISTOS COMO REQUERIMIENTOS NO FUNCIONALES Antes de iniciar se plantea la siguiente cuestión, ¿Por qué se mide un atributo de calidad software implicado como un requerimiento no funcional?, la respuesta es sencilla, porque se requiere verificar en qué grado satisface las necesidades del cliente. Como se requiere verificar el grado de satisfacción, es necesario medir ese valor agregado que ofrecen las pruebas a los atributos de calidad, vistos como requerimientos no funcionales, puesto que ―cuando puedes medir lo que estás diciendo y expresarlo en números, sabrás algo acerca de eso; pero cuando no puedes medirlo, cuando no puedes expresarlo en números, tus conocimientos serán escasos y no satisfactorios‖47, es decir, que no basta con decir qué beneficios proporcionan las pruebas a atributos no funcionales, sino también es necesario conocer el valor aproximado que aporta cada atributo de la calidad al producto software. Es por ello que se pretende con la recopilación de métricas llegar a un acercamiento de valoración de los atributos no funcionales, luego de aplicársele pruebas, siendo continua su valoración durante el ciclo de vida del software, pero no en todo momento, puesto que se torna complejo y exhausto. Se busca que sea independiente de la metodología de desarrollo, para así determinar el nivel de aporte a la calidad que ofrecen dichos atributos al aplicársele las pruebas. Es pertinente también recordar la dificultad para definir medidas adecuadas a cada atributo de calidad, asociado a requerimientos no funcionales, sin embargo para este estudio se tomaron como base las medidas establecidas por Ian Sommerville, y Pressman.
47
LORD, kelvin
71
Se trae como referencia algunas métricas para la medición, y adicionalmente se decide fragmentar cada atributo en características más pequeñas, tomando como referencia la ISO/IEC 9126. Se aclara que no es fácil definir las características para cada atributo, cuando cada uno tiene una concepción diferente, dependiente del contexto en el que se interprete, sin embargo, de forma global se presentan los más generales en la tabla 14.
72
Tabla 14. Atributos de calidad fragmentados en características.
Atributo de calidad como RNF Concepto medible y evaluable
Operabilidad
Aprendizaje (Tiempo de formación)
Atractividad
Comprensibilidad (Número de ayudas)
Analizabilidad
Facilidad de cambio
Facilidad de prueba
Estabilidad
Recuperabilidad
Frecuencia de fallas (Tiempo medio entre fallos)
Disponibilidad (Porcentaje de no disponibilidad)
Severidad de fallas (Tasa de ocurrencias de fallos)
Adaptabilidad
Instalabilidad (Número de sistemas operativos o
navegadores sobre los que funciona)
Facilidad de adaptación al cambio
Peso del aplicativo (Kbytes)
Co - existencia
Tiempo de respuesta por transacción (promedio,
máximo)
Desempeño (Número de usuarios activos que permite
el sistema)
Tráfico generado en las comunicaciones ( cantidad de
datos que pueden ser transferidos en un segundo)
Tiempo de recuperación a fallas
Utilización de recursos (Memoria)
Rendimiento (Transacciones procesadas por segundo)
Tiempo de actualización de interfaces
Usabilidad (Usability)
Mantenibilidad
Fiabilidad
Portabilidad
Eficiencia
73
4.2 MÉTRICAS PARA VALIDAR LOS REQUISITOS NO FUNCIONALES
Aunque sea reiterativo, es importante recordar la dificultad para cuantificar el nivel
de cumplimiento de los requerimientos no funcionales, y en sí, del aporte a la
calidad del software de esto, ya que éstos generalmente se cuantifican de forma
subjetiva; sin embargo a continuación se describen algunas métricas para
cuantificar dichos atributos de calidad vistos como requerimientos no funcionales.
A continuación se describen algunas métricas establecidas para cuantificar los
cinco factores, usabilidad, eficiencia, fiabilidad, portabilidad, mantenibilidad, los
cuales generalmente son utilizados como medidas indirectas, haciendo parte de
una excelente lista para determinar su aporte a la calidad del software.
4.2.1Usabilidad. Para evaluar y medir éste atributo, se deben principalmente
realizar checklist sobre los ítems que se encuentran a continuación, para luego
ponderar y definir un nivel de calidad y cumplimiento con respecto a los
requerimientos iníciales establecidos.
Evaluar interfaces graficas de usuarios (IGU)
Evaluar prototipos de Interfaces de Usuario: Cada uno de los prototipos de Interface de usuario representa un ejemplo de la interface de usuario que será construida para el sistema. Estos prototipos sirven para validar el diseño de la interface de usuario.
Evaluar la compatibilidad de interfaces entre componentes del software.
Encontrar errores de interfaces
74
Tabla 15. Esquema general de las listas de chequeo modificadas.
Característica de
usabilidad por
comprobar
Ponderación de
importancia 1 (poco), 5
(fundamental)
Nivel de
cumplimiento
(0 -100)
Justificación
Pregunta que
indaga sobre el
cumplimiento de
una características
de usabilidad
Opción 1
Opción N
.
.
.
Fuente: Revista de la Escuela de Ingeniería de Antioquia, en [8].
4.2.2 Fiabilidad. Lo que busca la fiabilidad es que el software se encuentre
funcionando de manera consistente y en forma correcta durante el tiempo que se
necesita emplearlo, y logrando que este si este falla, su facilidad de recuperación
sea ágil y fácil
Los usuarios que utilizan el aplicativo desarrollado buscan tener un software que su funcionamiento sea el adecuado, mientras los desarrolladores además de que su funcionamiento sea el correcto, también esperan que el números de fallos presentados puedan ser solucionados sin causar problemas al sistema mientras se realizan las pruebas, haciendo que crezca la confiabilidad en el software. La confiabilidad en relación con la incertidumbre, es tomada de tipo -1 (incertidumbre), en donde nos muestra la utilización del sistema, es por ello, que en un determinado instante de tiempo hasta la próxima falla es incierto y lo cual se tomara como una variable aleatoria. En el estudio de una variable aleatoria se utiliza la distribución exponencial encausada en las pruebas que tenga fallas cero, derivando una función de cifras de fallas, suponiendo que el número de fallas en el t debe ser igual:
a = constante
75
b = constante Con ello se puede determinar el número de horas que se deben probar para satisfacer los objetivos propuestos por la confiabilidad, es por ello, que se establecen 3 entradas: - Número proyectado promedio de fallas (fallas) - Número total de fallas observadas en las pruebas (fallas probadas) - Número total de horas de ejecución de pruebas hasta la última falla. Fórmula de las horas necesarias de prueba para cero fallas
Ln[(fallas)/(0,5 + fallas)] * (horas hasta última falla) Ln[(0,5 + fallas) / (fallas probadas + fallas) ]
4.2.3 Portabilidad. Es la facilidad del software para ser utilizado de una plataforma a otra, la cual cuenta con unos determinados atributos, entre ellos están la facilidad de instalación, ajuste, adaptación a los cambios La facilidad de instalación puede ser la medida de acuerdo a la siguiente relación:
X = A / B
A: es el número de instalaciones exitosas que el usuario realizó. B: es el número total de instalaciones que realizó el usuario. 4.2.4 Mantenibilidad. El índice de madurez de software (IMS) establecido por la
IEEE 982.1-1988 determina la estabilidad de un producto de software basada a los
diferentes cambios presentados durante las versiones.
Variables del índice de madurez de software (IMS):
76
-MT = Número de módulos en la versión actual. -Fc = Número de módulos en la versión actual que se han cambiado. -Fa = Número de módulos en la versión actual que se han añadido. -Fe = Número de módulos en la versión actual que se han eliminado. Fórmula del índice de madurez del software:
IMS= [MT - (Fc + Fa + Fe)]/MT
A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar48
4.3 PROPUESTA DEL MÉTODO DE EVALUACIÓN DE LOS REQUERIMIENTOS NO FUNCIONALES.
El método propuesto está orientado a fortalecer la calidad del producto de
software que se desarrolla, de manera independiente de la metodología. El
método pretende ser aplicado a lo largo del ciclo de vida del desarrollo, buscando
ser lo más sencillo posible, y de forma iterativo.
A lo largo del ciclo de vida del desarrollo se definen unas actividades específicas por cada etapa del ciclo de vida del desarrollo, respetando la metodología o modelo de desarrollo:
4.3.1 Fase 1. Levantamiento de requerimientos.
1. En esta se deben registrar y documentar:
2. Se debe identificar los requerimientos funcionales de los no funcionales sin
desligarlos obligatoriamente de los funcionales, puesto que de muchos
48
PRESSMAN, Roger S. Ingeniería del software. Un enfoque práctico. Sexta Edición. Estados Unidos: McGraw Hill, 2005.
900 p.
77
requerimientos funcionales parten los no funcionales, es por ello, que se deben
diferenciar mas no aislarlo uno del otro si no es necesario.
En esta etapa se aplican pruebas estáticas como lo son las inspecciones,
revisiones y/o walktroughs
4.3.2 Fase 2. Análisis
1. Cada requerimiento debe ser especificado de forma clara, consistente,
verificable, cuantificado en cifras verídicas, medibles y reales. De tal forma que no
queden abiertos a un amplio rango de interpretaciones subjetivas, es decir,
evitando dejarlos registrados en términos pobres, ni difusos.
Específico: sin ambigüedad, usando terminología consistente, simple y con el
apropiado nivel de detalle.
Medible: es posible verificar que el requerimiento ha sido encontrado. Entonces,
¿qué tests deben ser realizados? ¿O qué criterio debe tomarse para verificar que
se encuentra el requerimiento?
Accesible: se refiere a técnicamente factible. Cabe la pregunta ¿cuál es su juicio
profesional sobre la ―habilidad técnica para hacer‖ del requerimiento?
Realizable: es realista, si se dan los recursos
Rastreable (ubicable): se lo puede vincular desde su concepción (a través de su
especificación), a su diseño siguiente, implementación y test.
78
Puesto que cuando un requerimiento no funcional no está especificado en valores
medibles, es difícil saber si será realizable y verificable.
2. Clasificarlos por categorías, según correspondan a los siguientes atributos de
calidad software:49
- Usabilidad
- Fiabilidad
- Eficiencia
- Mantenibilidad
- Portabilidad
3. Priorizar los requerimientos no funcionales según las perspectiva del
stakeholder, ya que se deben identificar que requerimientos.
En esta etapa se aplican pruebas estáticas como lo son las inspecciones,
revisiones y/o walktroughs.
4.3.3 Fase 3. Diseño
1. Partiendo de la documentación de los requerimientos no funcionales, se
procede en esta fase a la modelación de éstos en casos de uso extendido para
los requerimientos no funcionales.
49
DIGIÓN DE GRIMALDI, Leda Beatriz. Departamento de Informática. Fac. de Ciencias Exactas y Tecnologías,
Universidad Nacional de Santiago. del Estero. Belgrano 1900. Santiago del Estero (CP. 4200).
79
Tabla 16. Modelo de caos de uso para requerimientos no funcionales.
Caso de uso # identificar el caso de uso a partir de un numero de referncia
Descripcion Se refiere al objetivo a cumplirse a traves del caso de uso y las
fuente de requerimiento.
Actores Se define una lista de actores que participan en el caso de uso
SuposicionesSon las condiciones que deben ser verdaderas para el caso de
uso se ejecute con el éxito.
PasosSon las acciones interactivas necesarias entre los actores y el
sistema para que se alcance el objetivo.
Variaciones
(Optativo)Indica cualquier variacion de los pasos en el caso de uso.
No funcionales
Define la lista de requerimientos no funcionales que el caso de
uso debe reconocer. Los requerimientos no funcionales se
listan en la forma:
<palabra-clave>:<requerimiento>, donde palabra-clave incluye
(pero no está limitado) a Perfomance, Confiabilidad, Tolerancia
de falla, Frecuencia, Prioridad. Cada requerimiento se expresa
en lenguaje natural o con un formalismo apropiado.
Aspectos Se refiere a situaciones puntuales pendientes de resolver
Fuente: Un estudio inicial de requerimientos no funcionales a través del caso de uso, en [11]
2. Priorizar los casos de usos para así definir los elementos críticos a probar.
3. Partiendo del diseño de casos de uso extendidos, se registra y documenta el
diseño de los casos de pruebas, mínimamente uno por cada caso de uso,
definiendo con el líder de calidad el número de máximo o limite de casos de
prueba a diseñar, buscando no tornar a un proceso complejo y exhausto
4.3.4 Fase 4. Implementación
En esta fase como se cuenta con un producto o módulo, se realizan pruebas
cortas que fueron diseñadas en la etapa anterior, es decir, se ejecutan teniendo en
80
cuenta que en su diseño se categorizó dependiendo del atributo de calidad a
evaluar, para verificar el nivel de cumplimiento de los requerimientos no
funcionales.
4.4 DEFINICIÓN DEL MÉTODO DE EVALUACIÓN. En cada etapa del desarrollo se debe ejecutar los siguientes pasos del método, y desempeñado por los roles que se describen a continuación:
4.4.1 Roles y responsabilidades
Líder de calidad
Analista de sistemas. Encargado de la administración y especificación de requerimientos, modelado del negocio
Ingeniero desarrollador. Encargado de codificación del aplicativo, definiendo el alcance de los módulos del proyecto o del producto software,
Analista de pruebas. Encargado de realizar las actividades del método propuesto para la evaluación de los requerimientos no funcionales, ejecutando las pruebas con regularidad y difundir los resultados al equipo de desarrollo
Cliente. Establece y define la prioridad de los requerimientos no funcionales a implementar, según al beneficio a recibir de los mismos, de tal forma que quedan para futuras iteraciones los que sean menos impactantes para el sistema y que se determinen como críticos.
Adicionalmente, se tienen en cuenta que en cada etapa del desarrollo se tienen
los siguientes suministros:
81
Figura 12. Método propuesto para la evaluación de los atributos no funcionales.
4.4.2 Planificación de las pruebas. Inicialmente describe las metas y objetivos
para cada iteración del ciclo de pruebas, teniendo en cuenta los elementos a
probar, asignación de recursos requeridos y finalmente obtener la documentación
recopilada de la ejecución de las pruebas realizadas según la fase del desarrollo,
tal como se definió anteriormente.
A continuación se define los pasos y documentación entregable
82
- Definir el Propósito, es necesario leer la documentación recolectada del sistema solicitado - Definir el alcance Establecer artefactos o elementos a probar y priorizarlos, es decir, determinar según el impacto sobre el aplicativo si ocurriese un error de determinado atributo - Definir objetivos de la evaluación - Definir un cronograma Estimar el cronograma, dentro del cual se definan tiempo por validación de cada componente o producto elegido - Identificar las características del ambiente de pruebas Este se debe establecer de acuerdo al ambiente final en el que se deberá implantar el producto, por ende, el ambiente de pruebas debe ser lo más exacto posible al real
Se realiza la planeación para validar los elementos, de tal forma que se asegure que el producto o componente sea apropiado para ser liberado a producción. 4.4.3 Diseño de las pruebas
- Diseñar los casos de pruebas a aplicar o en su defecto las inspecciones, revisiones a realizar, especificando los resultados esperados. -Definir criterios de validación, teniendo en cuenta las características de los productos a validar, y las restricciones del cliente - Definir criterios de finalización de la validación
83
Se debe establecer el plan de pruebas, de tal forma que se limite el tiempo y se evite incrementar costos por falta de planeación del tiempo. 4.4.4 Ejecución de las pruebas. Se aplican las pruebas con los datos que se
tienen.
4.4.5 Análisis de los resultados. En esta etapa se deben analizar los resultados de
las evaluaciones propuestas, según la categoría y se compara con los resultados
esperados, para determinar un nivel de cumplimiento
-Resumen de evaluación de pruebas
Al finalizar la ejecución de las pruebas planeadas y diseñadas, se organizan en un
documento, de tal forma que se le presenta el análisis de los resultados de las
pruebas, como también los casos de pruebas usados y las métricas utilizadas para
definir si pasaba o no las pruebas.
4.4.6 Validar criterios de aceptación. Se analizan los resultados uno por uno,
determinando que va y que no va. Después se analizan todos los resultados para
determinar si se puede aceptar o no, los requerimientos no funcionales en el
software, éstos deben ser aceptados por el cliente final, quien evalúa los
entregables por cada iteración de pruebas.
Todo debe quedar registrado en un reporte donde se tenga constancia de cuáles
fueron los errores habidos y su posible falla, así dando a conocer al desarrollador
cuales fueron las inconsistencias presentadas durante la etapa de pruebas.
4.4.7 Certificación
-Actividades de cierre: gestión de las pruebas.
84
Los ciclos de pruebas deben estar coordinados con los ciclos de desarrollo,
porque esto puede causar un retraso en el producto del software y por ende va en
detrimento de la percepción del cliente.
Los atributos no funcionales se conocen como características de calidad, las
cuales se deben tener en cuenta tanto al diseñar como al implementar el software.
Por ende en el presente documento, se propone un modelo que sirva de
orientación hacia la evaluación de éstos, que a su vez afectan la calidad del
software desarrollado.
Las siguientes fases propuestas, se deben realizar a lo largo del ciclo de vida del producto o componente, independiente de la metodología de desarrollo. 4.5 AUTOMATIZACIÓN DE PRUEBAS A ATRIBUTOS NO FUNCIONALES, USANDO HERRAMIENTAS PARA LA EVALUACIÓN DE LOS ATRIBUTOS Debido a que las pruebas manuales son exhaustivas y por tanto toman tiempo en su aplicación, requiriendo además recursos en personal, reprocesos en máquina, entre otros. Se recomienda la utilización de herramientas libres disponibles para reducir tiempos en ejecución de pruebas a atributos no funcionales: Tabla 17. Herramientas.
Aspecto a medir Herramientas
Calidad de Codigo
SONAR,Maven,Hudson,PMD,C
heckStyle,SourceMonitor
Seguridad Yasca Reports,FindBugs
Funcionales TestLink
Strerss y rendimiento Jmeter,Selenium
Seguridad Acunetix,ParosProxy
Regresion QTP
Gestion de incidencias y de
demanda
JIRA
Reporting OHM QA Portal,Excel,ppt.
Prue
bas
Esta
tica
s
Prue
bas
Din
amic
as
Otr
as
85
-Yasca Reports: es una herramienta que busca cuales son las vulnerabilidades en
la seguridad, la calidad del código, su rendimiento, sus informes los genera en
html,xml , entre otros formatos
-TestLink: esta herramienta permite generar y gestionar casos de pruebas,
lográndose hacer un seguimiento de los resultados obtenidos a través de la
prueba en una forma dinámica. Con esta herramienta se permite determinar los
requerimientos e indicar el orden y la asignación de tareas que se tengan.
-JMeter: es una herramienta realizada como proyecto de Apache Jakarta encargada para la realización de pruebas de carga, donde se mide y se analiza la eficiencia y el desempeño de las aplicaciones a probar, siendo una herramienta que hace su mayor énfasis a aplicaciones web. -Selenium: permite realizar grabaciones, editar y la depuración de pruebas. Esta herramienta es una extensión de Firefox. Las pruebas generadas las guarda en formato HTML, script de Ruby o en cualquier otro formato. Las pruebas realizadas con Selenium son compatibles con muchos browser, con pruebas de regresión, sirve de apoyo a metodologías ágiles, su documentación es disciplinada con los casos de pruebas. -Acunetix: encuentra los posibles fallos y vulnerabilidades que no permitan el buen
funcionamiento de la web en su seguridad, también comprueba el estado del
servidor. Esta herramienta informa como pueden ser reparados las posibles fallas
encontradas en su ejecución.
-ParosProxy: esta herramienta sirve para evaluar la seguridad en aplicaciones web
y se encuentra escrito en java
-QTP (Quick Test Professional): se centra en la calidad de sus productos haciendo
automatización de pruebas de regresión. Esta herramienta por lo general se
86
utiliza en interfaces graficas de los usuarios teniendo en cuenta la automatización
de los casos de prueba.
-JIRA: hace un completo seguimiento a proyectos y problemas de software con el
fin de mejorar la calidad y su desempeño del software. JIRA es utilizado en
algunas compañías como eje central en un grupo de desarrolladores.
-Excel: es una aplicación en la cual hace referencia al manejo de hojas de
cálculos, en donde su función es la realizar tareas de reportes, estadísticas,
financieras, contables, matemáticas, entre otras funciones. Esta herramienta fue
desarrollada por el equipo de Microsoft.
-PPT (Microsoft PowerPoint): fue desarrollada por Microsoft, se utiliza para hacer
presentaciones con imágenes, audio y texto. Las funciones de esta herramienta
son varias, pero el en caso de pruebas no funcionales se tiene como fin el de
mostrar informes a los desarrolladores, tester, clientes y personas que tengan que
ver con el producto de software a desarrollar.
87
5. CONCLUSIONES Y RECOMENDACIONES.
Durante proceso de desarrollo del producto de software, se debe realizar la documentación y registro de requerimientos no funcionales, para determinar el impacto sobre el aplicativo si ocurriese un error de determinado atributo. Se debe estar abiertos a las expectativas de los clientes, definiendo y evaluando las características de los requisitos funcionales y no funcionales, para definir: si son o no realizables, su claridad, conveniencia, pertinencia, etc. Cuando un equipo de desarrollo realiza pruebas intensivas, con los estándares de codificación, se empezará a tener un producto de calidad más rápido y más seguro. Se debe evitar la tentación de entregar el trabajo más rápido, omitiendo procesos de pruebas. Entregas de producto con fallos, repercutirá en la confianza de los clientes. Las empresas desarrolladoras de software se deben concientizar que las pruebas no funcionales son parte fundamental en el impacto del producto final. Los errores detectados a tiempo pueden evitar el incremento de costos, los cuales afectan directamente a la organización. El proceso de pruebas genera costos, por tanto se debe seleccionar de manera
cuidadosa tanto las pruebas a realizar, como los componentes a probar. Esto es
posible determinarlo, con base en la importancia de las piezas de software en el
producto final.
No se encuentra una diferencia significativa en el empleo de las herramientas y técnicas que se utilizan para la realización de pruebas funcionales o no funcionales, entre metodologías ágiles y robustas.
88
No todas las pruebas se pueden aplicar a los proyectos de software, lo que se
busca es tener un software de alta calidad y que las empresas desarrolladoras
aumenten su prestigio.
Las pruebas no aseguran la ausencia de errores, sólo demuestran que existen
defectos en el software, para así ser corregidos por los desarrolladores.
Como recomendaciones finales, se proponen: Es evidente la ausencia de profesionales recién egresados de las universidades colombianas, que se encuentren capacitados en estos temas; lo cual, no sólo genera desmotivación por parte de los empresarios que requieren personal en esta área, para solicitar egresados de las universidades, sino que prefieren traer profesionales de otros países latinoamericanos. En el programa de Ingeniería de sistemas y computación, se debería enfatizar y no sólo perfilar profesionales capacitados en codificación y desarrollo, sino en profesionales con habilidades de Ingenieros de software, analistas de calidad del software y probadores (tester).
89
BIBLIOGRAFÍA [1]. SOMMERVILLE, Ian. Ingeniería de software. Séptima Edición. Madrid, España: Pearson Educación S.A, 2005. 677 p. [2]. PRESSMAN, Roger S. Ingeniería del software. Un enfoque práctico. Sexta Edición. Estados Unidos: McGraw Hill, 2005. 900 p. [3]. REVISTA ESPAÑOLA DE ELECTRÓNICA. (Número 550: 2000: Pág. 90). Ingeniería del software y pruebas. María del Mar Aguilar Fernández. [4].PLAN DE PRUEBAS. Internet (www.ldc.usb.ve <http://ldc.usb.ve/~teruel/ci4713/clases2001/planPruebas.html>) [5]. Plantilla para caso de prueba. Internet (www.scielo.unal.edu.co http://www.scielo.unal.edu.co/scielo.php?pid=S1692-33242009000300004&script=sci_arttext ) [6].REQUISITOS NO FUNCIONALES. Internet (www.ecured.cu <http://www.ecured.cu/index.php/Archivo: Requesitos_no_funcionales.JPG>)
[7].CALIDAD DE COMPONENTES SOFTWARE. Internet (www.eduardoleyton.com <http://www.eduardoleyton.com/apuntes/ISO_9126_12207_UST.pdf>) [8]. REVISTA EIA, ISSN 1794-1237. (Número 13: Julio 2010: Pág.131). Escuela de Ingeniería de Antioquia, Medellín -Colombia. [9]. Metodologias ágiles para el desarrollo de software: eXtreme Programming (XP). Internet (www.willydev.net/descargas/masyxp.pdf <http://www.willydev.net/descargas/masyxp.pdf>)
90
[10]. Metodología Rational Unified Process (RUP).Internet (www.usmp.edu.pe <http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulosRUP%20vs.%20XP.pdf>) [11]. Un estudio inicial de requerimientos no funcionales a través del caso de uso. Internet (Www.jidis.frc.utn.edu.ar/papers/141242db4850df4caa8b371faf07.pdf < http://www.jidis.frc.utn.edu.ar/papers/141242db4850df4caa8b371faf07.pdf >). [12]. Desafíos y oportunidades de la industria del software en América Latina. Internet (www.eclac.org/publicaciones/xml/5/35655/Capitulo5.pdf <http//: www.eclac.org/publicaciones/xml/5/35655/Capitulo5.pdf>)..[Marzo 2009]. [13]. Departamento Nacional de Planeación, agenda interna para la competitividad y productividad sector software. Internet (www.dnp.gov.co<http www.dnp.gov.co >). [14]. ESI, European Software Institute, Numero de empresas certificadas en CMMI. Internet (www.sei.cmu.edu. <http://www.sei.cmu.edu>).[Marzo 2009]. [15]. European Software Institute. Industrialización en la producción de software. ―Situación actual del desarrollo de software‖. España: Citado de (Jones & Curtis, US DoD, Ben-Menachemand & Marliss). [2008]. [16]. Fedesoft, federación Colombiana de la industria del software y tecnologías relacionadas. Internet (www.fedesoft.org /index.php/tic+colombia/newest. <http://www.fedesoft.org/index.php/tic+colombia/newest.>) [Octubre 2008]. [17]. Fedesoft, federación Colombiana de la industria del software y tecnologías relacionadas.Internet(www.dis.eafit.edu.co/EstrategiasTIC/attachments/193_Fedesoft%20Colombia.pdf<http://www.dis.eafit.edu.co/EstrategiasTIC/attachments/193_Fedesoft%20Colombia.pdf>). [Marzo 2006]. [18]. Instituto Colombiano de Normas Técnicas y Certificación. Presentación y elaboración de trabajos y tesis de grado: compendio de normas técnicas colombianas sobre documentación. Bogotá, ICONTEC 2008. 112 p. ISBN 958-938-307-6
91
[19]. JOYANES AGUILAR, Luis. Investigación doctoral ―Modelo para la industrialización del software en el triangulo del café- Colombia [Marzo 2009].,. [20]. Lerma, Héctor Daniel; Metodología De La Investigación. Pereira. Postergraph.1999. ISBN958-33-0913-3 [21]. University of Michigan-dearborn. (2007). Software engineering program. Department of Computer and Information Science. Estados Unidos: College of Engineering and Computer Science. [22]. Circular externa 052 del 2007. Superintendencia financiera de Colombia. Internet(netsecuritysuite.com/pdf/Norma-052.pdf <http://www.netsecuritysuite.com/pdf/Norma-052.pdf>).