• Author / Uploaded
• Carlos Robayo

Citation preview

Propuesta de un "Plan de desarrollo de calidad del área de pruebas” para una empresa colombiana de desarrollo de software, soluciones de mantenimiento IM

Carlos Alberto Robayo Caicedo. Código: 1411026685 Fernando Rodríguez Caro. Código 1311070271 Rincón Martínez Luis Alfredo. Código: 1011000115 Diego Alejandro López Garzón. Código: 1821982429 Michael Alexander Espinosa Rico. Código: 1821981046

Septiembre 2019. Institución Universitaria Politécnico Gran Colombiano. Ingeniería, Diseño e Innovación. Pruebas y calidad de software

2 Tabla de Contenidos

1. Introducción 5 2. Objetivos 7 3. MODELOS DE CALIDAD DE SOFTWARE 8 McCall: 8 Boehm 10 Arthur 12 Modelo de FURFPS 14 Modelo de CMM 15 Modelo de Gilb 16 Modelo de Dromey 17 Modelo ISO 9000 19 Modelo Mosca 20 4. Línea de tiempo modelos de calidad 22 5. Selección de modelos para trabajar en soluciones en mantenimiento IM 22 Modelos a nivel de productos 26 6. Evaluación de la organización encuestas 27 7. DOFA ORGANIZACIONAL 28 9. Aseguramiento de la calidad del software 30 9.1 Pruebas 30 9.2 Principios de las pruebas 31 9.3 Modelo en V en pruebas de calidad de software 32 9.4 Tipos de Pruebas del SQA 32 9.4.1 Pruebas Software Funcionales: 32 9.4.2 Pruebas no funcionales 33 9.4.3 Pruebas estructurales 33 9.4.4 Pruebas de Aceptación 34 9.4.5 Pruebas de Integración 34 9.4.5 Pruebas de Sistema 34 9.5 Técnicas de caja negra 34 10. Metodología de actividades y procedimientos para aplicar en “soluciones de mantenimiento IM” 1 11. ACTIVIDADES PROCESOS Y PROCEDIMIENTOS PLAN DE PRUEBAS 1 Lista de referencias 9

3 Lista de tablas Tabla 1, Características modelo Arthur, elaboración propia 14 Tabla 2, Atributos modelos FURPS, elaboración propia 15 Tabla 3, características modelo dromey, elaboración propia 19 Tabla 4, Cuatrecasas,Luis, "Gestion Intgral de la Calidad", Gestion 2000, Barcelona, 2005, 3d ed, 356p ,ISBN 84-8088-609-9 23

4 Lista de ilustraciones Ilustración 1, Características modelo de Boehm, elaboración propia. Ilustración 2, Esquema general modelo dromey

11 18

5

1. Introducción En la actualidad las empresas de desarrollo de software se ha convertido en uno de los principales aliados en las organizaciones a nivel mundial, dando soluciones a diferentes necesidades, optimizando y mejorando procesos, razón por la cual el software debe contar con criterios que garanticen su calidad, siendo esto un factor fundamental para el desarrollo de las mismas como expresa (Valencia 2009): “La industria del software está directamente relacionada con la globalización, proporcionando a las empresas herramientas para dar cuenta de los desafíos de la internacionalización de la economía, tales como la innovación, el control logístico, la transformación productiva, la posibilidad de comunicarse rápidamente con todo el mundo, la necesidad de asegurar la calidad de productos, entre otros. De acuerdo con lo anterior, y si se considera que la Calidad del Software es: “La concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo documentados y con las características implícitas que se esperan de todo software desarrollado profesionalmente” (Pressman 2002). De acuerdo con esto, diferentes investigadores han propuesto varios modelos, metodologías y normas de calidad que brindan apoyo al desarrollo de un producto software y permiten evaluar si efectivamente tiene un nivel de calidad durante su ciclo de vida. En este documento se contextualiza inicialmente diversos modelos de calidad que se pueden aplicar al desarrollo de productos de software, realizando un comparativo entre ellos,

6 posteriormente se realizaron una serie de entrevistas con el objetivo de realizar la evaluación en la empresa “soluciones de mantenimiento IM” En los diferentes procesos de la empresa. Este trabajo se centrará en ofrecer una propuesta de mejora en los diferentes procesos de software de esta pyme.

7

2. Objetivos 2.1 Objetivo general. Establecer un plan detallado y la documentación necesaria para realizar un plan de pruebas con estándares de calidad que faciliten y optimicen los procesos de software en la empresa “soluciones de mantenimiento IM” 1.2.2 Objetivos específicos.  Diagnosticar la situación actual de la empresa con respecto a un modelo de calidad y pruebas de software.  Proponer un plan de acción para mejorar el proceso de calidad y pruebas actual.  Identificar y comparar diferentes modelos de calidad asociados al desarrollo de software.

8

3. MODELOS DE CALIDAD DE SOFTWARE Modelos Fijos McCall: Tiene varios nombres uno es modelo GE (General Electric) debido al patrocinio de esta empresa; también se conoce como FCM (Factores, Criterios, Métricas). Fue desarrollado primeramente para la Fuerza Aérea de los Estados Unidos, aparte es el más antiguo y ha servido como guía para otros modelos y consiste en acortar el camino entre el usuario y el desarrollador y su planteamiento va encaminado a un número de factores de calidad que muestren las prioridades de los dos. Factores: Se determinan entre el cliente y la administración para así poder conformar el punto de vista externo del software, que es lo que le importa al usuario. Estos factores pueden ser: confiabilidad, mantenibilidad y usabilidad. Criterios: Se establece en el nivel de la persona encargada de diseñar el software y es como se debe construir los componentes de este, ósea las tecnologías, aspectos y funciones que solo le competen a él. Acá es donde vemos la característica de Prueba y Eficiencia. Métricas:

9 Son quienes usan el producto final y consiste en preguntas cuyas respuestas (alfabéticas o numéricas) indican la presencia del atributo evaluado. Por ejemplo, si evaluamos el criterio de Simplicidad, vamos a verificar que las funciones en la prueba sean fáciles de experimentar. McCall Propuso dividir la suma de las métricas que cubrían aspectos de calidad entre el número total de ellas, para llegar al resultado del criterio. Este modelo ofrece tres factores para definir la calidad del producto del software: Operación del producto: El cual hace referencia a las características de operación las cuales se dividen en: Corrección: Es aquel que mide el grado de satisfacción de un programa consiguiendo los objetivos del usuario. Fiabilidad: Este mide el grado de lo que se espera que un programa haga. Ventajas: Se enfoca en el producto final teniendo en cuenta el punto de vista del usuario y buscando los atributos claves. También identifica criterios como simplicidad, capacidad de expansión, rastreabilidad, etc. Desventajas: A veces no existe relación lineal entre las características que se estiman con los valores métricos.

10 Los factores de calidad siempre serán los mismos, y se asume que algunos de ellos serán suficientes para realizar cualquier evaluación.

Boehm Este modelo fue propuesto por Barry Boehm en el año de 1978 y se basa en que el software debe hacer lo que el usuario quiere que haga. Esto es lo que se espera del software:

● Que utilice los recursos del computador correcta y eficientemente. ● Que sea fácil de usar y de aprender para los usuarios. ● Que esté bien diseñado, codificado y que sea probado y mantenido de una manera fácil. La estructura presenta 3 niveles para las características: de alto nivel, de nivel intermedio y características primitivas. Cada una de estas características contribuye al nivel general de calidad.

11 Características de alto nivel Estas características representan requerimientos generales de uso: •

Utilidad: cuando es usable, confiable y eficiente el producto en sí mismo.

•

Mantenimiento: cuando es fácil modificarlo, entenderlo y resetearlo.

•

Utilidad general: se puede seguir usando así se cambia el ambiente.

Características de nivel intermedio Estas características representan los factores de calidad de Boehm: •

Portabilidad (Utilidad general)

•

Fiabilidad (Utilidad per-se)

•

Eficiencia (Utilidad per-se)

•

Usabilidad (Utilidad per-se)

•

Capacidad de prueba (Mantenibilidad)

•

Flexibilidad (Mantenibilidad)

Características Primitivas: Este es el nivel más bajo y corresponde a características directamente asociadas a una o dos métricas de calidad: Portabilidad •

Independencia de dispositivos

•

Autocontención de confiabilidad.

•

Autocontención

12 •

Exactitud

•

Completitud

•

Consistencia

•

Robustez/Integridad

Ventajas •

Involucra menos criterios y factores lo que nos lleva a usar menos tiempo en el

desarrollo y se puede utilizar uno a uno y no para varios proyectos. Desventajas •

No es específico con todo lo relacionado con el usuario.

Arthur Creado por Arthur Andersen en 1985 cuyo objetivo es favorecer la transmisión de información, determinándola como valiosa, esto desde el usuario hacia la institución y generando que esta vuelva al usuario generando beneficios para él. Este modelo presenta una variable propuesto por Mc Call que consta de dos acciones: Añadir tres nuevos criterios de valoración que son complejidad, seguridad y audibilidad. Permite la auditoria lo que implica un mayor grado de confiabilidad ante el riesgo. Ventajas •

Tiene en cuenta el factor de calidad de corrección que muchos modelos no tienen.

•

Permite la auditoria; lo que implica un mayor grado de confiabilidad ante el

riesgo. Desventajas

13 •

Incluye criterios; lo que hace que se incluyan más métricas y esto conlleva más

esfuerzo, tiempo y costo. Algunas de sus características: Tabla 1, Características modelo Arthur, elaboración propia Factores Corrección

Fiabilidad

Eficiencia

Integridad

Utilizable Mantenible

Criterios Complejidad Consistencia Seguimiento Complejidad Consistencia Modularidad preciso Simplicidad Tolerante a errores Concisión Eficiencia de ejecución Operatividad Audibilidad Instrumentación seguridad Entrenamiento Operatividad Autodocumentado Concisión Consistencia Instrumentación Modularidad

14

Modelo de FURFPS

Desarrollado por Hewlett-Packard (1987). Vemos en este modelo que se desarrollan un conjunto de factores de calidad de software, bajo el acrónimo de FURPS: funcionalidad, usabilidad, confiabilidad, desempeño y capacidad de soporte. La tabla 2 que relacionamos a continuación trae la clasificación de los atributos de este modelo y las características asociadas a cada uno:

Tabla 2, Atributos modelos FURPS, elaboración propia Factor de Calidad Funcionalidad

Facilidad de uso

Confiabilidad

Rendimiento

Capacidad de Soporte

Atributos Capacidad y características del programa Generalidades de las funciones Seguridad del sistema Factores humanos Factores estéticos Consistencia de la interfaz Documentación Frecuencia y severidad de las fallas Exactitud de las salidas Tiempo medio de fallos Capacidad de recuperación ante fallas Capacidad de predicción Velocidad del procesamiento Tiempo de respuesta Consumo de recursos Rendimiento efectivo total Eficacia Extensibilidad Adaptabilidad Capacidad de pruebas Capacidad de configuración

15 Compatibilidad Requisitos de instalación

Ventajas •

Antes de comercializarlo este modelo dispone de una serie de test para las

diferentes etapas del producto y así obtener un ledd-back. •

Cuenta con un plan de soporte definido que incluye una base de datos con los

errores registrados. •

Este modelo también incluye restricciones de diseño y requerimientos de

implementación físicos y de interfaz. •

También cuenta con criterios claros para su fácil utilización.

Desventajas •

Este diseño no tiene en cuenta la portabilidad de los productos de software que se

estén considerando, algo que se debe considerar en función de las exigencias actuales que recaen sobre el proceso de desarrollo del software •

Necesita muchas métricas lo que implica mayor esfuerzo en tiempo y económico.

Modelo de CMM Es el máximo estándar en ingeniería de software ya que tiene innovación, velocidad y lo más importante satisfacción del usuario. En el principio este modelo fue aplicado en programas de defensa teniendo una gran aceptación, llegando a realizar modelos para diversos ámbitos más allá del software.

16 Cuenta con cinco niveles definidos que son: Inicial, Repetible, Definido, Gestionado y Optimizado. Ventajas •

La gestión y la ingeniería de las actividades se encuentran entrelazadas de una

manera explícita, tan es así que facilita el reconocimiento de los objetivos del negocio. •

Permite hacer la incorporación de la experiencia adquirida en otras zonas de las

mejores prácticas. •

Se puede aplicar prácticas de alta madurez mucho más robustas.

•

Cumplir de forma mucho más completa con las normas ISO.

Desventajas •

El gran problema es su falta de adecuación al enfoque del servicio que está

experimentando en el sector de la T.I en todas sus líneas de actividad, así como el alto esfuerzo de implementación que exige. Modelo de Gilb Aparece entre los años 1986-1988 y este modelo utiliza el termino de “atributos”, lo que hace referencia a la medida de calidad que determinado sistema a evaluar tiene. Este modelo muestra particular interés en atributos de calidad para satisfacer las necesidades del usuario. Este modelo se puede dividir en: Capacidad de trabajo: busca medir la capacidad del sistema para ejecutar tareas, para lo cual tiene en cuenta almacenamiento, proceso y respuesta. Disponibilidad: capacidad para desarrollar un trabajo de manera útil. Adaptabilidad: capacidad del sistema para sufrir modificaciones.

17 Usabilidad: facilidad con el cual las personas serán capaces para hacer uso del sistema. Este modelo proporciona algunas características que muestran indicadores útiles la cual describe la calidad de la aplicación del sistema.

Ventajas Evalúa el producto de manera independiente. También utiliza niveles de jerarquía para delegar trabajos, facilidad en su mantenimiento y su uso e integridad. Desventajas Evalúa demasiados factores lo que ocasionan mayor trabajo en tiempo y costos.

Modelo de Dromey Este es un modelo de calidad a medida propuesto en 1995 y su propósito es trabajar con una estructura que permita construir y utilizar un modelo práctico con el fin de evaluar las etapas de los requerimientos. Adicional a esto debemos tener en cuenta que esta información se puede usar para elaborar, comparar y evaluar la calidad de los productos de software. Este modelo también plantea la calidad del producto a través de sub características, las cuales se pueden medir y evaluar como características. Dromey propone 3 modelos para cada etapa del proceso de desarrollo, ver ilustración 2

18

Tabla 3, características modelo dromey, elaboración propia Propiedades del producto Corrección Internas

Contextuales

Descriptivas

Características de calidad Funcionabilidad Confiabilidad Mantenibilidad Eficiencia Confiabilidad Mantenibilidad Reusabilidad Portabilidad Confiabilidad Mantenibilidad Reusabilidad Portabilidad Usabilidad

Ventajas Resalta que la calidad del producto es altamente determinada por los componentes de este tales como documentos de requerimientos, guías de usuarios, diseños y códigos. Sugiere el uso de cuatro categorías implícitas en la calidad que son: correctitud, internas, contextuales y descriptivas. Desventajas Se basa solo en la calidad del producto y no en su desarrollo ni en su análisis. Modelo ISO 9000

19 El estándar ISO 9126 presenta su primera versión en 1991 y después, en el año 2001 se reemplaza por la ISO 9126:1.

Este modelo cuenta con 8 principios básicos de gestión los cuales son: •

Enfoque al cliente

•

Liderazgo

•

Participación del personal

•

Enfoque basado en procesos

•

Enfoque de sistema para la gestión

•

Mejora continua

•

Enfoque basado en hechos para la toma de decisión

•

Relaciones mutuamente beneficiosas con el proveedor

Ventajas •

Modelo de carácter internacional. Tecnología clara y precisa. Involucra el uso de

la ISO. Se puede usar en varios proyectos. Desventajas •

Como casi todos los modelos, en este se destaca el mucho tiempo y dinero, pero

de todos este es el más costoso.

Modelo Mosca

20 (Modelo Sistémico de Calidad de Software): es en el LISI-USB (Mendoza et al., 2001), que integra el modelo de calidad del producto (Ortega, et al., 2000) y el modelo de calidad del proceso de desarrollo (Pérez et al., 2001), y soporta estos conceptos de calidad sistémica (Callaos y Callaos, 1993; Pérez et al., 1999). De acuerdo al producto este modelo plantea 6 características de acuerdo a categorías, características y métricas asociadas que miden la calidad y hacen de este modelo un instrumento de gran valor. Ya en cuanto al proceso este modelo se hizo sobre la base de 5 características de calidad del estándar internacional, las cuales son: Nivel 0 Dimensiones: Eficiencia del proceso y del producto. Efectividad del proceso y del producto. Solo una buena interrelación entre ellas garantiza la calidad sistemática global de la organización. Nivel 1 Categorías: dividida en 6 pertenecientes al producto que son funcionabilidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad y 5 al proceso de desarrollo que son cliente-proveedor, ingeniería, soporte, gestión y organizacional. Nivel 2 Características: cada categoría tiene asociadas un conjunto de características (56 al producto y 27 al proceso), las cuales definen las áreas claves a satisfacer para lograr, asegurar y controlar la calidad tanto en el producto como en el proceso. Entre las características asociadas a cada categoría del producto, se proponen en el modelo MOSCA, una serie de características del proceso. Esto se debe a que algunas características de la calidad del proceso impactan directamente en las categorías del producto, al igual que ciertas características de la calidad del producto definen categorías del proceso. Nivel 3 Métricas: la cantidad de métricas asociadas a cada una de las características que conforman MOSCA es de 587 en total. Adicionalmente, MOSCA cuenta con un algoritmo que

21 facilita su operacionalización y permite estimar la calidad de software. El algoritmo contempla tres fases: Estimación de la calidad del producto de software con un enfoque sistémico Estimación de la calidad del proceso de desarrollo de software con un enfoque sistémico Integración de las mediciones de los sub-modelos de la calidad del producto y la calidad del proceso. Ventajas El enfoque es tanto en el proceso como en el producto Es una herramienta efectiva de análisis y estimación de la calidad global Desventajas Se vuelve un proceso bien complicado si no se tiene una guía adecuada para la aplicación del modelo.

4. Línea de tiempo modelos de calidad

1977 MacCall: acá se describe la calidad como un concepto que se hace a través de relaciones jerárquicas, entre factores de calidad, basándose en criterios y métricas de calidad. Esta se divide en: -

Determina los factores que influyen sobre la calidad del software.

22 -

Identifica los criterios para juzgar cada factor.

-

Define métricas de criterios y establece una función de normalizar, que define la relación entre la métrica el factor.

-

Evaluación de las métricas.

Existe una variante presentada por Arthur Andersen, con respecto al modelo propuesto por MacCall, añadir 3 niveles uevos de valoración (Complejidad, Seguridad y Audiabilidad) y variar las relaciones de factores y criterios. 1978 Boehm: representa una estructura jerárquica con características las cuales llevan a la calidad total. Consiste en un modelo de descomposición con tres características de calidad, previos a la aplicación de métricas. Tiene como finalidad varios aspectos como son: utilizar recursos informáticos de manera correcta y eficiente; es fácil de utilizar y aprender; debe ser bien diseñado, codificado, probado y de fácil mantenimiento. 1987 Furps: es aplicado teniendo en cuenta asignación de prioridades y definición de atributos de calidad los cuales pueden ser medidos. 1988 Gilb: plantea crear requisitos específicos de calidad para cada proyecto, los cuales deben ser escritos por el usuario y el analista, conjuntamente. Se conocen dos tipos, los originales y los de modelos tradicionales. Sus características se miden teniendo en cuenta los siguientes conceptos: -

Nombre y definición de la característica

-

Unidades o escalas de medición

-

Recolección de datos

-

Valor previsto

-

Valor óptimo

-

Valor en el sistema actual

-

Comentarios

23 1991 ISO 9126: describe el modelo de calidad del producto de software y en su primera parte especifica 6 características de calidad, tanto interna como externa, las cuales se dividen en subcategorías y se manifiestan externamente cuando el software se utiliza como parte de un sistema y dan como resultado atributos internos del software. Esta calidad es medible y su parte externa evalúa la satisfacción de las necesidades, por parte del usuario, también evalúa el total de atributos que un software debe satisfacer de acuerdo con condiciones específicas. Las características y subcaracterísticas proveen terminología consistente respecto de la calidad del producto del software. 1995 Dromey: es quien propone un marco de referencia para construir un modelo de calidad basado en como las propiedades medibles de un producto de software pueden afectar los atributos de calidad como por ejemplo mantenibilidad y confiabilidad. El problema que planteó era cómo conectar estas propiedades del producto con los atributos de calidad de alto nivel. Por eso Dromey sugiere usar cuatro categorías que implican propiedades de calidad, estas son correctitud, internas, contextuales y descriptivas. 2001 ISO 9126 1: pensando en las aplicaciones web se desarrolla un modelo, el cual debe ser gestionado y dirigido de forma rigurosa y cualitativa, haciendo necesario establecer mecanismos que garanticen la calidad. Para esto se definió un Modelo de Calidad para la Web y cun conjunto de métricas, de tal manera que cubran la mayor parte de tipos de sitios web. 2005 ISO 25001: conocida también como SQuaRE, las cuales son una serie de normas cuyo objetivo es la creación de un marco de trabajo común para evaluar la calidad del producto del software.

5. Selección de modelos para trabajar en soluciones en mantenimiento IM

24 Después de estudiar los diferentes modelos en este trabajo nos centraremos en el modelo CMMI ya que tiene muchas prácticas de otros modelos mencionados y es muy utilizado para el mejoramiento de los procesos de software en las organizaciones, dedicadas tanto al desarrollo como a subcontratación de productos y servicios de software. CMMI (Capability Maturity Model Integration), es un modelo para la mejora o evaluación de los procesos de software, desarrollado por el instituto de ingeniera de software (SEI) de la universidad de Carnegie Mellon en enero del 2002. CMMI se compone de dos elementos básicos: Modelos: Descripción de las mejores prácticas para que los procesos que permiten la consecución de objetivos de negocios definen el que hacer. Métodos de Evaluación: Permite medir los procesos de una organización a través de estándares, niveles de madurez, capacidad de un área de proceso, entre otros. El modelo CMMI contiene dos formas de representar los niveles de madurez y capacidad son escalonada y continua.

25 Estos niveles hacen relación a dos enfoques para la mejora de un proceso, entonces el uso de la representación continúa permite alcanzar niveles de capacidad y la representación por etapas alcanza la madurez los niveles. Como vimos en la imagen anterior, en la representación continua, las áreas de proceso se dividen en cuatro categorías, las cuales destacan algunas de las principales relaciones que hay entre las áreas de proceso.

Modelo Ideal El modelo IDEAL fue originalmente concebido como un modelo de ciclo de vida para mejoramiento del proceso software basado en el Modelo de Capacidad y Madurez (CMM). A continuación, se describe un poco más sobre el modelo, que en general ha mostrado gran potencial en áreas fuera del dominio de los procesos. IDEAL ofrece una aproximación útil y comprensible para la mejora continua, al exponer los pasos necesarios para establecer un programa de mejora exitoso. El modelo proporciona un enfoque disciplinado de ingeniería para la mejora, enfocándose en la gestión del programa de mejora y estableciendo las bases para una estrategia de mejora a largo plazo. El modelo consta de cinco fases: I - Iniciación: Establecimiento de las bases para un exitoso esfuerzo de mejora. D - Diagnóstico: Determinar dónde se está respecto a dónde se quiere estar. E - Establecimiento: Planificación de los detalles de cómo se va a llegar al destino. A - Actuación: Realizar el trabajo de acuerdo con el plan.

26 L - (Learning) Aprendizaje: Aprender de la experiencia y mejorar la capacidad para adoptar nuevas tecnologías en el futuro.

Modelo Ideal, tomado dehttp://normas--iso.blogspot.com/2009/11/normas-isoiec-12207.html

27

Modelos a nivel de productos Tabla 4, Cuatrecasas,Luis, "Gestion Intgral de la Calidad", Gestion 2000, Barcelona, 2005, 3d ed, 356p ,ISBN 84-8088-609-9

28

29

6. Evaluación de la organización encuestas Por favor marque de 1 a 4, donde cada valor significa: 1. 2. 3. 4.

No hay practica definida Existe una práctica, pero no está implementada Existe una práctica, pero con resultados incompletos Existe una práctica la cual se aplica con buenos resultados

Tabla 5, Encuesta – elaboración propia 1

Administración de requisitos

Planificación de proyectos

Se conocen los requisitos de los proyectos Existen documentos que soporten estos requisitos entre el cliente y la compañía Se realiza registro de cambios en los requisitos en cada proyecto Existe una política de manejo de requisitos Se define el alcance del proyecto con estimaciones formales Se definen las actividades a realizar Se garantiza el ciclo de vida del proyecto Se cuenta con un cronograma y presupuesto

2

3 x x

x

x x

x x

x

x Se cuenta con un plan de riesgos Se realizan actas en todas las reuniones

4

x

30 Existen Lideres en la ejecución de proyectos

x

x

Se asignan roles de acuerdo a las habilidades de las personas Existe un control de versiones Control y monitoria de proyectos

Existe una política de monitoreo en cada proyecto

x x

Existe control de riesgos del proyecto Existen control de los actores del proyecto Existe un plan de pruebas en las diferentes etapas del proyecto

x

x x

7. DOFA ORGANIZACIONAL A Continuación, se presenta una lista de Debilidades, Oportunidades, Fortalezas y Amenazas (DOFA), la cual busca entender mejor la realidad actual de la empresa, e identificar cuales son los estímulos para el cambio. 7.1 Fortalezas: ● El clima organizacional es muy ameno al ser una organización de menos de 20 empleados. ● Ofrece una solución integral, facilitando la fidelización de los clientes. ● La compañía proyecta seriedad y organización. ● El conocimiento técnico en soluciones de mantenimiento facilita el desarrollo de nuevos planes.

31 7.2 Debilidades: ● La documentación del software desarrollado no es clara. ● El proceso de software después de la etapa de requisitos no está bien definido ● Los recursos humanos son muy limitados, haciendo que la organización no pueda atender a muchos clientes a la vez. ● El servicio post venta no está completamente estructurada. ● El proceso de aseguramiento de la calidad el producto está en una edad temprana de implementación, pues existe una práctica con resultados incompletos ● Hace falta un modelo financiero. 7.3 Oportunidades ● Por el aumento del dólar es más difícil la compra de nuevas máquinas industriales, lo que lleva a las empresas a invertir más en mantenimiento ● Existe la tendencia a tercerizar los servicios de mantenimiento ● Las industrias colombianas son apoyadas por el gobierno. 7.4 Amenazas ● Las soluciones integrales de los proveedores de máquinas, respuestas o servicios ● Los inversionistas extranjeros ya vienen con las soluciones de mantenimiento ● Posibles pérdidas de contratos por no tener una certificación de calidad ejemplo ISO.

32

9. Aseguramiento de la calidad del software

El Aseguramiento de la Calidad del Software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza que el software satisfará los requisitos dados de calidad, según la norma ISO 9000:2000 es parte de la gestión de la calidad.

En este conjunto de actividades no son únicamente responsables el equipo de calidad, sino todo el equipo de trabajo y deben considerarse dentro de la gestión de riesgo, un defecto o falla en alguna parte del ciclo de vida del producto pueden generar riesgos.

9.1 Pruebas En 1957 se conoce la prueba del Debugging1 , y Dijkstra en 1970 presenta una afirmación: “La prueba de software puede ser usada para mostrar la presencia de bugs, pero nunca su ausencia”. Según Swebook: “Es una actividad realizada para evaluar la calidad del producto y mejorarla, identificando defectos y problemas”

Normalmente la mayoría de las empresas dejan el proceso de pruebas para la última etapa, consolidando la calidad de su producto es el caso de “soluciones de mantenimiento IM” 1

la depuración es un proceso para encontrar y reducir el número de errores o defectos en un programa de computador.

33 esto debería dejarse a un lado, pues como se menciona anteriormente debe hacer parte de todo el ciclo de vida del producto. 9.2 Principios de las pruebas ISTQB ha propuesto establecer unas pautas comunes para que las empresas de desarrollo de software las conozcan y adapten a sus procesos de pruebas

Principio La presencia de defectos Las pruebas exhaustivas Pruebas tempranas Paradoja del pesticida Las pruebas dependen del contexto

Descripción Permiten identificar presencia de fallos; sin embargo, no garantiza que no existan defectos ocultos en el software Probar un producto de software de extremo a extremo es muy complicado lo mejor es analizar riesgos y tomar decisiones Es la mejor forma de ahorrar recursos, pues identificarlas de manera temprana evitara un mayor desgaste a futuro Si se repite un mismo tipo de prueba, no se encontrar nuevos errores, la idea es probar nuevos casos Las pruebas dependen del tipo de producto, por ejemplo, un software financiero necesitara un mayor nivel de complejidad

Tabla 6, principios de pruebas, elaboración propia

34

9.3 Modelo en V en pruebas de calidad de software

Ilustración Modelo V, tomado de Sh. Lawrence Pfleeger y J. M. Atlee, Software Enginnering. Estados Unidos: Pearson; 2009 9.4 Tipos de Pruebas del SQA Según las directrices de ISTQB2, los tipos de prueba de software se centran en:

9.4.1 Pruebas Software Funcionales: “Se basan en funciones, prestaciones y en su interoperabilidad con sistemas específicos, y pueden llevarse a cabo en todos los niveles de prueba” (T. Müller, 2013)

2

International Software Testing Qualifications Board

35 Se orientan en el comportamiento externo de un producto o aplicativo software, en las pruebas de caja negra3 Se consideran Pruebas de Caja Negra (“black-box testing”) puesto que valoramos el comportamiento externo del sistema. Las Pruebas de Seguridad o las Pruebas de Interoperabilidad entre sistemas o componentes son casos especializados de las pruebas funcionales.

9.4.2 Pruebas no funcionales Hacen referencia a las pruebas necesarias “para medir las características de los sistemas y software que pueden cuantificarse según una escala variable”. (ieee, “Software Engineering. Product quality. Part 1: Quality Model” 2001) Se debe tener en cuenta que se orientan hacia el comportamiento externo del software y en la mayoría de los casos utilizan técnicas de diseño de pruebas de caja negra. 9.4.3 Pruebas estructurales Pueden realizarse en todos los niveles de prueba. Son las más idóneas, después de las técnicas basadas en la especificación, “para ayudar a medir la exhaustividad de las pruebas mediante una evaluación de la cobertura de un tipo de estructura” (T. Müller, 2011)

3

Técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software

36

9.4.4 Pruebas de Aceptación Las pruebas de aceptación se realizan con los usuarios finales con el fin de validar la correcta implementación de los requisitos que fueron solicitados al inicio del proyecto.

9.4.5 Pruebas de Integración Valida la comunicación e interacción correcta entre todos los componentes del sistema.

9.4.5 Pruebas de Sistema Permiten comprobar el funcionamiento del flujo completo del proceso de negocio, validando su operación global.

9.5 Técnicas de caja negra Las pruebas de caja negra, es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software. En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin preocuparnos en tener conocimiento de la estructura interna del programa de software como define Müller

37 “Puede utilizarse para lograr objetivos de cobertura de entrada y salida, con entradas humanas, vía interfaces a un sistema, o parámetros de interfaz de las pruebas de integración” (T. Müller, 2011), basadas únicamente en los requerimientos de software y especificaciones funcionales. Ejemplo tomado de: Pmoinformatica.com," La Oficina de Proyectos de Informática "4 Ejemplo 1: Envió de correo electrónico al registrarse una transacción

Descripción del caso: El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de factura a cliente y registro de cobro al cliente.

Técnica de pruebas de caja negra: Requerimiento funcional / Caso de uso

Caso 1.1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El sistema envía un correo electrónico al cliente como constancia que su pedido se ha recibido.

Caso 1.2: Datos de entrada: Registrar despacho de mercancía al cliente. Resultado esperado (Salida): El sistema envía un correo electrónico al cliente como constancia que se ha realizado el despacho.

4

Servicios de Amazon Associates LLC

38 Caso 1.3: Datos de entrada: Registrar factura de cliente. Resultado esperado (Salida): El sistema envía un correo electrónico al departamento de facturación y al cliente.

Caso 1.4: Datos de entrada: Registrar cobro. Resultado esperado (Salida): El sistema envía un correo electrónico al departamento de cuentas por cobrar y al agente comercial (vendedor) que lleva la cuenta del cliente.

10. Metodología de actividades y procedimientos para aplicar en “soluciones de mantenimiento IM”

Planeación de pruebas/ usuarios y equipo SQA

Ejecución de pruebas / equipo SQA

Reunión de contextualización

Diseño de pruebas /analista de calidad usuarios

casos de pruebas funcionales

Verificación casos de pruebas /usuarios, anialista de calidad/ desarollador

Paso a producción

Validación de hallazgos /analista de calidad - equipo de desarollo

Registro de hallazgos /anaista de calidad equipo de desarollo

Ejecución pruebas funcionales /analista de calidad

Ilustración proceso metodológico, elaboración propia

2

11. ACTIVIDADES PROCESOS Y PROCEDIMIENTOS PLAN DE PRUEBAS El plan de pruebas se compone de los siguientes elementos:      

      

  

Nombre Introducción Objetivo Estrategia Alcance Entregables: o Plan de pruebas funcionales  Introducción  Objeto  Alcance  Trazabilidad de casos de prueba – requisitos  Definición de los casos de prueba  Estrategia de ejecución de pruebas  anexos Documentación a entregar Características a ser probabas Características a no ser probadas Criterios de aprobación y fallo Criterios de suspensión y reanudación Tareas de las pruebas (Cronograma) Necesidades ambientales  Hardware  Planeación de costos  Sistemas bajo pruebas – SUT  Test- ware Capacitaciones Riesgos Laboratorio de usabilidad.

A continuación, se describen cada uno de los elementos mencionados anteriormente:

3 Introducción: Busca informar el alcance de las pruebas para el proyecto en cuestión, dando una breve explicación o resumen de todas las secciones que integraran el plan.

Objetivo General: Busca informar la finalidad genérica del Plan de Pruebas, no debe de señalar resultados concretos ni medibles con la utilización de indicadores

Estrategia De Pruebas: Corresponde al conjunto de decisiones sobre acciones y recursos a utilizar que permitirá alcanzar el objetivo general de nuestro plan

Alcance Corresponde a presentar y delimitar la totalidad del trabajo que es necesitado para dar por terminado nuestro plan de pruebas. Propósito Corresponde a la determinación firme de lo que se espera al momento de llevar a cabo la implementación de nuestro plan de pruebas.

Documentación A Entregar

4 Se listarán todos los documentos que se entregaran como parte de la ejecución del plan, especificando el nombre del documento, la persona quien entrega, la persona quien recibe, así como la fecha planeada y la fecha que fue la entrega para cada uno de los entregables. Para esta sección se recomienda el uso de una tabla cuyo formato del tipo de letra, color de la tabla sean entendibles para que los involucrados en el Plan, puedan identificar rápidamente las características de los entregables. Algunos de los documentos que debes de considerar entregar son: Casos de pruebas, Especificación del diseño de casos, Reporte de errores (defectos), Evidencias de las pruebas, Reportes emitidos por alguna herramienta de administración de las pruebas y cualquier otro documento de carácter importante que sea considerado para su entrega.

Características A Ser Probadas En esta sección se listarán todas las características que serán probadas. Algunas características que se pueden hablar en esta sección son: características de funcionalidad, se interfaz gráfica, seguridad, etc. Es importante definirlas de manera clara y concisa para no tener malas interpretaciones de dichas características.

Características A No Ser Probadas En esta sección se listarán todas las características que no serán probadas, es importante que se justifique el por qué no serán probadas las características y el riesgo que estas pueden ocasionar al no ser probadas, Algunas características que se pueden hablar en esta sección son: características de interfaz gráfica, seguridad, etc. Es importante definirlas de manera clara y

5 concisa para no tener malas interpretaciones y si ocurre algún evento que afecte al proyecto no comenzar a repartir cumplas entre los equipos. Criterios De Aprobación Y Fallo Son los criterios que serán considerados para dar por completado el Plan de Pruebas, por ejemplo: Porcentaje de la cobertura de las pruebas esperado, cierto porcentaje de casos exitosos, cobertura de todos los componentes, porcentaje de defectos corregidos, todo error debe de ir acompañado de un mensaje de validación, entre otros. Cuando un criterio de aprobación fue rechazado se toma acción para el criterio utilizando el criterio de fallo para dicho criterio. Todo criterio de aprobación lo debe de acompañar un criterio de fallo, el cual es la acción que se tomara en la implementación del plan, cuando se ejecuten las pruebas sobre el proyecto.

Criterios De Suspensión Y Reanudación En esta sección se establecen los criterios de suspensión los cuales establece claramente bajo qué condiciones se detienen un conjunto de casos de pruebas, por ejemplo, en caso de existir defectos que impidan la ejecución de más casos de pruebas, cierto porcentaje de casos fallidos, o cualquier otro que se especifique. Los criterios de reanudación establecen bajo qué criterios se reanudarán las pruebas, por ejemplo: cuando nos entreguen una nueva versión de pruebas, cuando nos realicen las configuraciones necesarias, etc. Es importante considerar que para cada criterio de suspensión debe contar su criterio de reanudación.

6 Tareas De Las Pruebas (Cronograma) En este apartado se describirán las tareas y cuando se van a ejecutar, el propósito es mantener una buena administración de las tareas integradas en este plan. Se busca establecer el nombre de la tarea, su descripción corta y precisa, fecha de inicio, fecha de fin, su duración, el responsable de cada tarea y el rol que la desempeñara. Para determinar la duración de las tareas es importe desarrollar un WBS5 en el cual se describen y se asignan las tareas de manera desglosada para obtener dicha duración, o también podemos pedir la opinión de los expertos para determinarla de manera más real. Necesidades ambientales Hardware Se especifican los equipos tecnológicos que son requeridos para poder llevar a cabo nuestras pruebas de software en el proyecto, las necesidades del hardware comienzan desde el análisis de requerimientos, diseños de pruebas, administración de pruebas, ejecución de pruebas y algún otro dispositivo necesario que es parte fundamental del proyecto, como pueden ser, impresoras, terminales bancarias, teléfonos, que son algunos ejemplos. Se debe considerar que los equipos y/o dispositivos con los que no se cuentan, que tan requeridos son, para ello te debes de contestar las siguientes preguntas: ¿Es requerido el equipo y/o dispositivo?, ¿Urge la adquisición del equipo y/o dispositivo que es requerido?, con el objetivo de justificar porque es necesario la adquisición del equipo y/o dispositivo, de esta manera los involucrados en el proyecto podrán determinar que parte realiza la adquisición del hardware 5

(Estructura de Descomposición del Trabajo)

7 Planeación De Costos Se debe tener en cuenta el costo de la implementación de las pruebas en el proyecto. El costo es uno de los indicadores más importantes a considerar en el plan, por lo tanto, mientras más eficiente sea esta labor, menos recursos se invertirán en la ejecución de las pruebas y, por consiguiente, menor será la cuantía de los gastos. Es importante tener en cuenta los recursos humanos, costo de capacitaciones, cursos, insumos materiales; como puede ser papel, tinta etc. Es importante que clasifiques los tipos de recursos para una mejor organización y presentación de los mismos. También costo de capacitaciones. Sut (Sistema Bajo Pruebas) El sistema bajo pruebas por sus siglas en inglés SUT (System Under Test), se refiere al sistema o modulo del sistema que está siendo probado para su funcionamiento correcto. Es importante considerar la distribución de los módulos en los cuales el proyecto se organizó y la integración de los mismos. El propósito de esta sección es tener bien claro cuáles son los módulos a probar, los requerimientos del proyecto por módulo y los casos de prueba para cada módulo.

Test-ware. En esta sección se especifican los artefactos que son requeridos para la ejecución del proceso de pruebas, se debe de considerar la configuración del ambiente de pruebas, los privilegios de los diferentes usuarios que van a interactuar con el sistema, los accesos a bases de datos, guías de pruebas, casos de prueba y la documentación especifica del proyecto.

8 Capacitaciones En esta sección se deben de especificar las capacitaciones requeridas para los integrantes del equipo, el objetivo principal de esta sección es determinar a qué personas del equipo serán capacitadas. Se debe de considerar las capacitaciones de carácter autodidacta. Es importante considerar al instructor, las personas que recibirán la capacitación, así como los temas, las fechas de inicio y fin, la duración en horas y su costo.

Riesgos En esta sección se especificarán los riesgos que pueden afectar directamente o indirectamente a los resultados de nuestras pruebas. Identificar y tener las acciones preventivas y correctivas de los riesgos anteriormente definidos, nos permiten tomar decisiones rápidas y eficientes, porque anteriormente ya se realizó el análisis de los riesgos y sus acciones a tomar. Es importante que al documentar los riesgos sea de manera organizada y entendible para todos los involucrados del proyecto. A continuación, se mencionan algunas secciones para la organización de los riesgos que son: Id Riesgo, Nombre, Descripción, Estado inicial, Consecuencias, Probabilidad de ocurrencia, impacto, prioridad, clasificación, síntomas, tolerancias, acciones preventivas y correctivas.

9

Laboratorio De Usabilidad En esta sección se especificarán las juntas requeridas en todo el proyecto, las citas se pueden tener de clasificación externa que son con el cliente o internas que son con los integrantes del equipo, es importante determinar las citas y sus objetivos de cada una ya que pueden ser para presentación y validación de diseño de pruebas, como aclaraciones con las reglas de negocio, requerimientos, etc. Algunas opciones de definición son: Junta, clasificación, descripción, duración, fecha y los usuarios.

10

Lista de referencias J. A. Mera-Paz, “Análisis del proceso de pruebas de calidad de software”, Ingeniería Solidaria, vol. 12, no. 20, pp. 163-176, oct. 2016. doi: http://dx.doi.org/10.16925/in.v12i20.1482 Aseguramiento de Calidad - TSI. (s.f.). Recuperado 16 septiembre, 2019, de http://www.tsitecnologia.com.co/calidad-de-software-certificacion/ International Software Testing Qualifications Board [istqb], “Certified Tester Foundation Level Syllabus. Released version 2011”, 2011 [en línea]. Disponible en: http://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-levelsyllabus-2011.html4 E. W. Dijkstra, “Notes on Structures Programming”, Technical University Eindhoven, The Netherlands, departamento de Matemáticas, Technical Report 70-WSK-03 1970, pp. 15-64 [en línea]. Disponible en: https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF ieee Computer Society, “Guide to the Software Engineering Body of Knowledge Swebok”, ieee Computer Society, pp. 10-40, 2004 [en línea]. Disponible en: https://www.computer.org/web/swebok/v3 Carlos García, Modelo de Calidad Mccall, Recuperado 8 de septiembre, 2019, de https://prezi.com/_nr9euumvog2/modelo-de-calidad-mccall/ Devys Damián Fuentes Salas, Modelo Sistémico de Calidad (MOSCA), Recuperado 10 de septiembre , 2019 de https://www.mindomo.com/es/mindmap/modelo-sistemico-de-calidadmosca-e16aae03e1d4418db1b36a5f414de768 Tipos de Modelos. (s.f.). Recuperado 15 septiembre, 2019, de http://evaluaciondered.blogspot.com/p/clasi.html Carmen Ines Baez, Procesos de Desarrollo de Software Version 1,0, Basado en Articulación de RUP y CMMI priorizando su calidad. Boyaca,2013 Cuatrecasas,Luis, "Gestion Intgral de la Calidad", Gestion 2000, Barcelona, 2005, 3d ed, 356p ,ISBN 84-8088-609-9

11 Álvarez Caldas, Héctor Iván, Cárcamo Zuluaga, Juan Gonzalo, Propuesta de mejoramiento del proceso software para una empresa de soluciones integrales, 2010, recuperado 7 de septiembre 2019 de http://hdl.handle.net/10784/407 Aseguramiento de la Calidad de Software. (s.f.). Recuperado 16 septiembre, 2019, de Aseguramiento de Calidad - TSI. (s.f.). Recuperado 16 septiembre, 2019, de http://www.tsitecnologia.com.co/calidad-de-software-certificacion/ T. Müller, Libro Programa de Estudio de Nivel Básico para Probador Certificado, istqb, Version 2013, p. 14. Disponible en: http://www.istqb.org/downloads/send/2-foundation-leveldocuments/3-foundation-level-syllabus-2011.html4 Fernando Ch Ga, F. (2018, 7 diciembre). Plan de Pruebas de Software. Recuperado 29 septiembre, 2019, de https://mundotesting.com/plan-de-pruebas-de-software/ Plantillas Plan de Pruebas | Marco de Desarrollo de la Junta de Andalucía. (s.f.). Recuperado 29 septiembre, 2019, de http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/463 Pmoinformatica.com, P. M. O. (s.f.). Pruebas de software: 10 pasos para elaborar el plan de pruebas. Recuperado 29 septiembre, 2019, de http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-software.html Mejora de la Calidad del Software en el Entorno de microempresas de TI (Tesis de Doctorado). Madrid: Universidad Politécnica de Madrid. http://www.dlsiis.fi.upm.es/docto_lsiis/Trabajos20062007/Caballero.pdf Dirección General de Servicio Civil (2013). Modelo de Calidad de Software para Desarrollo de Sistemas en la DGSC. Área de Desarrollo Estratégico Unidad de Tecnologías de Información http://www.dgsc.go.cr/sitio2/indiceGestion/IGI%202013/6-TECNOL-INF-2013/PREGUNTA6/Modelo-calidad-software-UTIC.pdf Scalone, F. (2006). Estudio Comparativo de los Modelos y Estándares de Calidad del Software. Buenos Aires: Universidad Tecnológica Nacional. http://laboratorios.fi.uba.ar/lsi/scalone-tesis-maestria-ingenieria-en-calidad.pdf