Creación De Una Metodología Óptima Y Eficiente Para La Implementación De Pruebas De Software.”

SEMINARIO GESTIÓN E INTELIGENCIA DE NEGOCIOS

“CREACIÓN DE UNA METODOLOGÍA ÓPTIMA Y EFICIENTE PARA LA IMPLEMENTACIÓN DE PRUEBAS DE SOFTWARE.”

TESIN A

QUE PARA OBTENER EL TÍTULO D E

LICENCIADO EN CIENCIAS DE LA INFORMATIC A

PRESENTA N

DAVID FLORES MENDOZ A

PAOLA TOVAR HERNÁNDE Z

QUE PARA OBTENER EL TÍTULO D E

LICENCIADO EN ADMINISTRACIÓN INDUSTRIA L

PRESENT A

IRVIN EDUARDO MARTELL JIMENEZ

EXPOSITORES

LIC. VICTOR ROCHA MARTINEZ

LIC. GUILLERMO GRANADOS MUCIÑO

LIC. GABRIELA MONTES DE OCA GOMEZ

CIUDAD DE MÉXICO 2019

No. DE REGISTRO c7.1726

INDICE Resumen ...... I Introducción ...... II CAPITULO I MARCO METODOLOGICO ...... 1 1.1 Planteamiento del Problema ...... 1 1.2 Objetivo ...... 2 1.3 Objetivos específicos ...... 2 1.4 Justificación ...... 2 CAPITULO II MARCO TEÓRICO ...... 4 2.1 Teoría del método...... 4 2.2 Sistemas de información ...... 4 2.2.1 Modelos de construcción de software tradicionales ...... 6 2.2.2 Modelos de construcción de software actuales ...... 17 2.3 Calidad del Software ...... 26 2.3.1 Calidad Informática ...... 27 2.3.2 Fundamentos de Calidad de Software ...... 28 2.3.3. Parámetros de la Calidad de Software ...... 29 2.4 Pruebas de Software ...... 39 2.5 Clasificación de las pruebas de software ...... 40 2.6 Aseguramiento de la calidad ...... 42 2.7 Herramientas para pruebas de software ...... 43 2.7.1 JSystem ...... 43 2.7.2 HP LoadRunner ...... 44 2.7.3 WebLOAD ...... 44 2.7.4 NeoLOAD ...... 45 2.6.5 Selenium ...... 46 2.6.7 JMeter...... 47 2.6.8 JUnit...... 47 2.8 Estudio comparativo ...... 48 CAPITULO III SITUACIÓN ACTUAL DE LAS METODOLOGIAS EN LAS EMPRESAS .. 50 3.1 Conceptos de Testing ...... 50 3.1.1 Conceptos Relacionados en la Aplicación de un Proceso de Testing ...... 50 3.1.2 Aplicación de un Proceso de Testing ...... 51 3.1.3 Perfil del Tester ...... 53 3.1.4 Habilidades que debe tener un buen Tester ...... 54 3.1.5 Actividades que ejecuta un Tester ...... 56 3.1.6 Tipos de Testers según su Expertiz (Clasificación) ...... 57 3.1.7 Principales certificaciones y organizaciones certificadoras ...... 61 3.2 Características de las Metodologías actuales ...... 63 3.2.1 ¿Qué es la Calidad del software? ...... 63

3.2.2 Factores que determinan la calidad del software ...... 64 3.2.3. Aseguramiento de la calidad del software ...... 65 3.2.4. Estrategias de Prueba para asegurar la calidad del Software ...... 68 3.2.5 Selección de la Metodología a aplicar...... 69 3.2.6 Criterios de Selección de metodologías de desarrollo de Software ...... 73 3.3. Situación actual en la Implementación de Metodologías de Testing ...... 74 3.3.1 Modus Operandi en la aplicación de Metodologías de Testing ...... 76 3.4 Problemática ...... 79 3.4.1 Principales errores de fallo en el Software ...... 81 3.4.2 Tipos de Fallas ...... 81 3.4.2.1 En algoritmos ...... 82 3.4.2.2 De sintaxis ...... 82 3.4.2.3 De precisión o de cálculo ...... 82 3.4.2.4 De documentación ...... 82 3.4.2.5 De estrés o sobrecarga ...... 82 3.4.2.6 De capacidad o de borde ...... 82 3.4.2.7 De sincronización o coordinación ...... 83 3.4.2.8 De capacidad de procesamiento o desempeño ...... 83 3.4.2.9 De recuperación ...... 83 3.4.2.10 De estándares o procedimientos ...... 83 3.4.2.11 De hardware o software del sistema ...... 83 3.4.3 Clasificación de Defectos ...... 83 3.4.3.1 Clasificación Ortogonal ...... 83 3.4.3.2 Clasificación Ortogonal de IBM ...... 83 3.4.4 Descripción de los principales problemas relativos a la Implementación de un Proceso para pruebas de Testing...... 84 3.4.5. Beneficios en la aplicación de pruebas ...... 85 3.5 Presentación de Hipótesis ...... 86 CAPITULO IV PROPUESTA PARA SOLUCIONAR EL PROBLEMA ...... 87 4.1 Propuesta de solución: Modelo de Pruebas y Calidad de Software ...... 87 4.2 Métricas que se utilizarán dentro del Modelo de pruebas ...... 91 4.3 Análisis Costo-Beneficio ...... 94 4.4 Punto de Equilibrio ...... 97 4.5 Aplicación del modelo de pruebas ...... 98 4.5.1 Pruebas Unitarias...... 99 4.5.2. Versionamiento ...... 101 4.5.3. Integración Continua ...... 101 4.5.4. Criterios de aceptación...... 103 4.5.5. Developer Testing ...... 103 4.5.6. Pruebas de regresión ...... 104 4.5.7. Pruebas nexploratorias ...... 105 4.5.8. Criterios hechos ...... 105 4.6 Demostración de la hipótesis ...... 105 Conclusiones ...... 106

Referencia ...... 107 Glosario ...... 108

Resumen Este estudio plantea una reflexión en torno a los sistemas de información y la relación que estos deben tener con la calidad en términos de su uso cotidiano, con el fin de adaptarse y satisfacer las necesidades para el manejo de información de sus clientes. Esto obedece a la importancia de los procesos de planeación que sirven de referencia funcional para la gestión de los sistemas de información en cualquier organización, y así lograr el incremento gradual en el uso y buen funcionamiento, tomando como apoyo las tecnologías de la información y la comunicación, para lo cual han de tenerse en cuenta las reales y cambiantes necesidades de los usuarios de la información. La aportación de las nuevas tecnologías al paso de este marco es indiscutible.

Actualmente los negocios operan en un entorno global que cambia rápidamente. Tienen que responder a nuevas oportunidades y mercados, condiciones económicas cambiantes y la aparición de productos y servicios competidores. El software es parte de casi todas las operaciones de negocio, por lo que es fundamental que el software nuevo se desarrolle rápidamente para aprovechar nuevas oportunidades y responder a la presión competitiva. Actualmente el desarrollo y entrega de manera rápida son los requerimientos más críticos de los sistemas.

A lo largo de este trabajo se explicarán a gran detalle conceptos básicos de la informática por mencionar algunos: sistemas de información, ciclo de vida del desarrollo de sistemas, fase de pruebas, calidad de software, seguridad informática, entre otros; que permitan tener un panorama completo del tema de estudio; se mostrará también la importancia y aplicación del desarrollo de sistemas de información funcionales en las empresas, focalizando la atención dentro de la etapa de pruebas. Así mismo como apoyo se presentan esquemas, imágenes ilustrativas y tablas estadísticas que soportan esta investigación. Al final se presenta la hipótesis o lo que se desea lograr y se expone ampliamente la propuesta de solución.

A lo largo del tiempo las empresas buscan tener un nivel cada vez más alto de productividad y sin excepción alguna llegar a posicionarse en un lugar privilegiado dentro del mercado (sea cual sea su giro), esto se logra a partir de muchos factores que en conjunto brindan soporte y seguridad, tales como: constancia, disciplina, valores, compromiso e identificación del capital humano, así como el uso y aprovechamiento de nuevas tecnologías. Los beneficios de un sistema de información no estriban únicamente en que el usuario final realice sus tareas básicas en un tiempo y espacio que él defina, sino que además se busca brindarle todas las herramientas necesarias para que dichas tareas sean cumplidas con eficiencia. La innovación y competencia que existe actualmente en las grandes empresas, implica el conocimiento y desarrollo de mejores sistemas para el manejo adecuado de sus extensos volúmenes de información, teniendo en cuanta elementos como seguridad de información, control de versiones, desarrollo de sistemas eficientes y calidad en los productos finales.

Introducción Las Pruebas (Software Testing en inglés) son el proceso por el cual se encuentran bugs y errores en el software, las define como un conjunto de actividades sistemáticas y planeadas para descubrir errores en el software. Con frecuencia requieren mayor cantidad del esfuerzo realizado en un proyecto que cualquier otra actividad. Establece que las pruebas consumen al menos la mitad del tiempo y trabajo requerido para producir un programa funcional.

Por otra parte, las pruebas son el recurso más importante para la evaluación de la calidad de un software; sin embargo, calidad y pruebas no son lo mismo. La calidad se incorpora al software en todo el proceso de ingeniería, si no está ahí cuando empiece la prueba, no estará cuando se termine. Por esta razón, deben enfocarse en la prevención. Un bug prevenido en el software es mejor que un bug detectado y corregido.

Las Pruebas de software son procedimientos formales: las entradas deben ser preparadas, las salidas deben ser predecidas, las pruebas deben ser documentadas y los resultados deben ser monitoreados. Es por ello que se requiere de un proceso sistemático y planeado. Se han propuesto varias estrategias para probar el software; sin embargo, muestra que las características genéricas que se encuentran en cada una de ellas son: a) las pruebas comienzan al nivel de componentes y se dirigen a la integración del Sistema completo, b) las pruebas las dirige el desarrollador de software y un grupo independiente de pruebas y c) se debe fundamentar en una planeación definiendo técnicas y diversos tipos de pruebas.

Este trabajo está dividido en cuatro capítulos. En el primer capítulo se presenta la metodología de investigación que se tomó para elaborar este proyecto y los objetivos que se persiguen al realizar dicha investigación. En el segundo capítulo se expone de manera detallada la parte teórica relacionada en principio con la calidad de software, de la mano con el ciclo de vida y desarrollo de software; mostrando las faces que lo conforman.

El tercer capítulo aborda de manera integral la importancia del desarrollo y uso de software de calidad, así como su impacto en el mundo actual. Se menciona manera global de las nuevas tendencias y tecnologías de software que emplean las s compañías del sector asegurador (del país, de Latinoamérica y del mundo), así como su posicionamiento en el mercado. Se analiza la forma de trabajo del área de Informática y específicamente de la subárea de Desarrollo y Mantenimiento de sistemas. Se expone la problemática

Por último, en el cuarto capítulo se realiza la propuesta de solución, se presenta el desarrollo de un modelo efectivo de pruebas, se hace un estudio de costo-beneficio que en conjunto nos lleva a verificar la hipótesis y dar una conclusión.

CAPITULO I MARCO METODOLOGICO

1.1 Planteamiento del Problema Las áreas de Informática de las empresas asegurados no cuentan actualmente con un modelo definido para las pruebas de software, lo que al final del día provoca retraso en las entregas de requerimientos, aumento en el nivel de errores, el proceso de desarrollo se vuelve más lento e ineficiente. Dicho de otra forma la mayor parte de errores inconsistencias en el sistema son descubiertos hasta que éste llega a manos del usuario, quién los va detectando sobre la marcha.

Aunque todos los requerimientos están foliados y cuentan con un nivel de prioridad y un tiempo estimado de entrega, el número de incidencias aumenta debido a las características antes citadas.

En la empresa se trabaja por medio de BRD (Bussines Requierments Definition), donde el usuario plasma sus requerimientos y envía al área de sistemas para su realización. El primer contacto con el área de Informática es que los jefes reciben, revisan y canaliza al “Champion del Sistema” quien lo prioriza, analiza y asigna. El requerimiento llega como nuevo, el desarrollador trabaja sobre éste, según sea para crear sistemas nuevos o modificar/mejorar los ya existentes.

De manera individual cada desarrollador estima el tiempo que le dedicará a dicho requerimiento, desde el momento en que llega a su bandeja con estatus de nuevo hasta el momento que éste pasa a pruebas; considerará también el tiempo que se quedará su versión en el ambiente de pruebas correspondiente.

Para realizar las pruebas existen dos ambientes: E2E y UAT, los desarrolladores pertenecen a alguno de estos ambientes para agilizar el proceso y que las versiones de pruebas no se traslapen.

Como cada desarrollador es responsable de la realización de sus pruebas, es quién decidirá qué hacer con los resultados obtenidos. Lo que implica cierto grado de desorganización personal e impacta en los resultados del área en conjunto. Así mismo como parte de la problemática general se observa que no se documentan los desarrollos debidamente, lo que genera información incompleta sobre quién y cuándo se realizó algún cambio en los programas.

En la actualidad el no realizar pruebas eficientes y suficientes para una empresa puede representar un sobrecosto y sobre esfuerzo de más del 15%.

Las pruebas funcionales son importantes para el desarrollo del proyecto porque abarcan en su mayoría los requerimientos y solicitudes realizadas por los usuarios, por lo que mediante estas podemos determinar si lo que se está desarrollando cumple con los niveles de aceptación descritos por el cliente.

Dentro de los principales beneficios que tienen este tipo de pruebas está la mitigación del riesgo de aparición de fallos en producción, el cumplimiento de los objetivos de los proyectos en términos de calidad y resultados esperados principalmente, pero también de plazos y costos.

Además, la identificación temprana de riesgos y desviaciones asociadas a la calidad, permiten evitar problemas con proveedores, mayores costos para el cliente y finalmente generar confianza en el producto o sistema bajo test.

1.2 Objetivo Proponer un modelo de pruebas y calidad es lograr una mayor fluidez en la entrega de requerimientos, mayor calidad en los productos finales de software, así como reducir el tiempo de entrega de los mismos.

Con esto ayudar a la toma de decisiones importantes; en primera instancia al área de sistemas y por ende a la empresa en general. Dichas decisiones pueden considerarse como una medida significativa en la gestión de los procesos y ayuda a los directores a alcanzar sus metas y objetivos. Estas decisiones se toman con base en información real, confiable y oportuna, por eso debe existir un control efectivo en los requerimientos de sistema para evitar así errores que traigan graves consecuencias a la operación.

1.3 Objetivos específicos 1. ● Aplicar la metodología propuesta en diversos Sistemas desarrollados en la Escuela Superior de Cómputo. 2. ● Proponer criterios para clasificación de casos de uso. Verificar las hipótesis planteadas. 3. ● Encontrar patrones de comportamiento de los errores detectados. 4. ● Analizar el comportamiento de los errores detectados con base a los criterios propuestos.

1.4 Justificación Un buen proceso de pruebas es dirigido por las preguntas ¿cómo puede este software fallar? ¿En qué situaciones este software puede dejar de funcionar de forma predecible?, sin embargo, es muy difícil cuantificar todas las formas en que un software puede comportarse. Generalmente el proceso de pruebas en el ciclo de vida de desarrollo de Software no lleva una metodología clara o un estándar de desarrollo.

Las pruebas de software consumen una gran proporción de la cantidad de tiempo requerido para producir un software funcional; sin embargo, es importante llevar a cabo un proceso de pruebas que garantice la calidad del software y sobre todo la prevención de errores. Es posible estimar la importancia de la identificación de errores y el impacto que implica la omisión del proceso de pruebas mediante la siguiente métrica según, la cual da una estimación de tal efecto en términos económicos:

Impacto $ = frecuencia × (costocorreccion + costoinstalacion + costoconsecuencias)

Donde frecuencia representa la frecuencia de aparición de un error y los costos, el impacto económico por la corrección del error, la instalación del sistema y las consecuencias derivadas del error.

Probar todo el software es muy costoso. Datos de la industria indican que cerca de la mitad del presupuesto de un Software se gasta en el proceso de Pruebas. Es posible aplicar métodos estadísticos para la realización de pruebas, analizando una muestra representativa para inferir la calidad del sistema completo. Así también, se pueden asociar costos a los casos de prueba, valores ganados a las pruebas realizadas y probabilidades de uso a los estados posibles de un software, con el fin de minimizar costos y maximizar ganancias.

Existen metodologías que indican el procedimiento para realizar pruebas, sin embargo, son complejas y el tiempo que toma entenderlas considerablemente alto, por lo que en muchos casos son omitidas o mal aplicadas.

Este proyecto implica conocer, estudiar, analizar y entender las metodologías que existen, para proponer nuevas estrategias, que sean fáciles de aprender y aplicar en el desarrollo pruebas de software. Es importante destacar que el proceso de pruebas implica costos (tiempo, infraestructura, etc.), no obstante, es conveniente- te implementar el proceso si se considera el gran impacto antes descrito. Así, se busca proporcionar las herramientas necesarias, tanto teóricas como técnicas, para aplicar la metodología, reducir los tiempos de evaluación del rendimiento y la funcionalidad, y garantizar la calidad de un software.

CAPITULO II MARCO TEÓRICO El trabajo tiene como objetivo construir una metodología para realizar pruebas de software, describir las pruebas necesarias y la forma de medir los atributos del software para, de manera sistemática, representar y comunicar la información obtenida. Es por ello que resulta fundamental conocer los conceptos básicos de Calidad de Software, Pruebas de Software y la teoría referente a la creación de metodologías en el área de sistemas de información.

En el presente capítulo se exponen los conceptos básicos de ingeniería del método, que estudia la creación de nuevas metodologías de desarrollo de sistemas de información, para después describir los componentes y características de los Sistemas de Información. El objetivo del trabajo se orienta a la estimación de la calidad del Software en términos de funcionalidad y rendimiento, por lo que se explicarán los conceptos de calidad de software y los modelos utilizados para medir sus atributos.

2.1 Teoría del método Existe una relación conceptual entre metodología y método. El DRAE (Diccionario de la lengua española) define metodología como “ciencia del método”. Por otra parte, define método como “un proceso, planeado y sistemático en términos de sus medios y propósitos, que conduce las habilidades técnicas en la resolución teórica y práctica de tareas”. Para fines de nuestro estudio, se tomará la definición en el área de sistemas de información de que lo define como “cuerpos, sometidos a prueba, de reglas y procedimientos”.

2.2 Sistemas de información La ingeniería de software es una disciplina de la ingeniería cuya meta es el desarrollo costeable de sistemas de software.

Un modelo de procesos del software es una descripción simplificada del proceso del software que presenta una visión de ese proceso. Estos modelos pueden incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucradas en la ingeniería del software. Algunos ejemplos de estos tipos de modelos que se pueden producir son:

1. Un modelo de flujo de trabajo: muestra la secuencia de actividades en el proceso junto con sus entradas, salidas y dependencias. Las actividades en este modelo representan acciones humanas. 2. Un modelo de flujo de datos de actividad: representa el proceso como un conjunto de actividades, cada una de las cuales realiza alguna transformación en los datos. Muestra cómo la entrada en el proceso, tal como una especificación, se transforma en una salida, tal como un diseño. 3. Un modelo de rol: representa los roles de las personas involucradas en el proceso del software y las actividades de las que son responsables.

La mayor parte de los modelos de proceso de software se basan en uno de los modelos generales o paradigmas de desarrollo o construcción (que se expondrán a continuación). Cada uno de los cuales describe un enfoque diferente para realizar diversas actividades que tienen lugar durante el proceso para lograr un objetivo en común. De ahí la importancia de contar con analistas y desarrolladores que permitieran un análisis adecuado de las necesidades que se deberían de implementar.

Estos modelos generales no son descripciones definitivas de los procesos del software más bien son abstracciones de los procesos que se pueden utilizar para el desarrollo del software. Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser adaptados para crear procesos más específicos.

La ingeniería de software requiere llevar a cabo numerosas tareas forzosamente agrupadas en etapas, al conjunto de estas etapas se le denomina ciclo de vida.

El ciclo de vida es un proceso o estructura aplicada al desarrollo de un producto de software.

Para cada proyecto debería elegirse el modelo más apropiado de acuerdo a sus necesidades. En ocasiones cabe la posibilidad de que combinar varios modelos sea apropiado.

Para el ciclo de desarrollo y vida del software existen diversos modelos como, por ejemplo, el modelo de Cascada pura o secuencial, el modelo en Espiral, el modelo Incremental y más recientemente el método Scrum (que se mostrarán más adelante).

Todos los modelos mencionados coinciden en forma genérica que durante la etapa de pruebas el sistema instalado en condiciones normales de operación y trabajo es probado exhaustivamente a fin de encontrar errores, inestabilidades, respuestas erróneas, etc. que hayan pasado desapercibidos a primera vista. Estas son normalmente realizadas por el mismo personal de desarrollo (o en su caso que se cuente con el área especializada de pruebas mencionada anteriormente). Los posibles errores encontrados se remiten para su depuración. En el caso de software de desarrollo bajo requerimientos, el usuario final (también llamado usuario o cliente) es el que realiza la prueba Beta, teniendo para ello un período de prueba pactado con el desarrollador.

Los procesos de desarrollo del software basados en una completa especificación de los requerimientos, diseño, construcción y pruebas del sistema no se ajustan al desarrollo rápido de aplicaciones. Cuando los requerimientos cambian o se descubren problemas con ellos, el diseño o implementación del sistema se tiene que volver a realizar o probar. Como consecuencia, normalmente se prolonga en el tiempo un proceso en cascada convencional y el software definitivo se entrega mucho tiempo después al cliente con el que inicialmente se pactó. En un entorno de negocios tan cambiante, esto puede causar verdaderos problemas. Para cuando esté disponible el software, la razón original de su adquisición puede ser que haya cambiado de forma radical que tal

5 vez lo haga ver obsoleto. Por lo general se busca combinar una filosofía y un conjunto de directrices de desarrollo. La filosofía quiere lograr la satisfacción del cliente y la entrega temprana de software incremental, equipos pequeños con alta motivación, métodos informales y una simplicidad general del desarrollo. Los procesos de desarrollo rápido de software están diseñados para producir software útil de forma rápida. Generalmente, son procesos interactivos en los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas.

2.2.1 Modelos de construcción de software tradicionales Como se explicó en el concepto anterior, un modelo para el desarrollo de software es una representación abstracta de un proceso. Cada modelo representa un proceso desde una perspectiva particular que así proporcione información y avances de forma parcial del proceso.

2.2.1.1 Modelo de Cascada También llamado Cascada Pura: es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software. Considera las actividades anteriores y las representa cada una como fases de procesos separadas o independientes, es decir, sólo después de que cada etapa o fase queda terminada, el desarrollo continúa con la siguiente. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase o no. Este modelo fue el pionero y es la base de todos los demás modelos de ciclo de vida y sigue vigente por su alto nivel de rendimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Las etapas que comprende este modelo son las siguientes (como se ilustra en la figura 1):

1. Autorización del proyecto o Planteamiento del problema 2. Análisis de requisitos o requerimientos 3. Diseño del Sistema/Programa 4. Desarrollo o codificación 5. Integración y Pruebas 6. Implementación 7. Mantenimiento

Figura 1.- Diagrama del Modelo de cascada

Black Rex (2011). Fundamentos de Pruebas de Software. Editorial. RBCS, Inc.

1. Planteamiento del problema: es la primera fase en donde se debe autorizar el proyecto, definir: el alcance, tiempo y recursos que serán necesarios. 2. Análisis de requisitos: en esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante señalar que en esta etapa se debe integrar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software. 3. Diseño: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario, así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación. 4. Desarrollo: Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido. 5. Integración y pruebas: los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final. 6. Implementación: Fase en la que se pone en funcionamiento el sistema. 7. Mantenimiento: es la última etapa del ciclo y posiblemente la de mayor duración. Comprende la tarea de analizar el rendimiento del software después de la implementación y resolver correctamente los posibles problemas que vayan surgiendo. Asegurando así que el software opere continuamente con el máximo rendimiento.

Ventajas:

• Es un modelo lineal y, por supuesto, los modelos lineales son los más simples a ser implementados. • La cantidad de recursos necesarios para implementar este modelo es mínimo. • La documentación se produce en cada etapa del desarrollo. Esto hace que la comprensión del producto diseñar procedimiento sea más sencillo. • Después de cada etapa importante de la codificación de software, se realizan pruebas para comprobar el correcto funcionamiento del código.

Desventajas:

• Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, los cambios generan confusión conforme el equipo del proyecto avanza.

• A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimientos. El modelo de cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre natural que existe al principio de muchos proyectos.

• El cliente debe tener paciencia. No se dispondrá de una versión funcional del (de los) programa (s) hasta que el proyecto esté muy avanzado. Un error grande sería desastroso si se detectara hasta revisar el programa en funcionamiento.

En un análisis interesante de proyectos reales, se encontró que la naturaleza lineal del ciclo de vida clásico llega a “estado de bloqueo” en los que ciertos miembros del equipo del proyecto deben esperar a otros a fin de terminar tareas interdependientes. En realidad, ¡el tiempo de espera llega a superar al dedicado al trabajo productivo! Los estados de bloqueo tienden a ocurrir más al principio y al final de un proceso secuencial lineal.

Hoy en día, el trabajo de software es acelerado y está sujeto a una corriente sin fin de cambios (en las características, funciones y contenidos de información). El modelo de cascada suele ser inapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso útil en situaciones en las que los requerimientos son fijos y el trabajo avanza en forma lineal hacia el final.

2.2.1.2 Modelo en Espiral Es un modelo evolutivo del proceso de software y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada. Tiene el potencial de hacer un desarrollo rápido de versiones cada vez más completas.

El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de sistemas intensivos en software. Tiene dos características distinticas principales. La primera es el enfoque cíclico para el crecimiento incremental del grado de un sistema y su implementación, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones factibles y mutuamente satisfactorias.

Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas.

Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez más completas del sistema cuya ingeniería se está haciendo.

Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

En cada vuelta o iteración hay que tener en cuenta:

• Objetivos: qué necesidades debe cubrir el producto. • Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa. • Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

Se planificarán los siguientes pasos y se comienza un nuevo ciclo del espiral. El espiral tiene forma de caracol y se dice que mantiene dos dimensiones, la radial y la angular:

• Radial: indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando. • Angular: indica el avance del proyecto del software dentro de un ciclo.

Este sistema es muy utilizado en proyectos grandes y complejos, por ejemplo, en la creación de un Sistema Operativo.

Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la experiencia necesaria y habilidad para detectar y catalogar correctamente los riesgos.

Hay una actividad que se hace sólo una vez: la planificación inicial. Sin embargo, para cada ciclo o vuelta habrá cuatro actividades (Figura 3):

1. Determinar Objetivos: asegurar los productos definidos a obtener, como son: requerimientos, especificación, manual de usuario, etc. Establecer las restricciones. Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. 2. Los objetivos se determinan conjuntamente con el cliente. Al mismo tiempo, se discuten posibles alternativas y se especifican las condiciones marco (por ejemplo, sistemas operativos, entornos y lenguajes de programación). 3. Análisis del riesgo: en esta etapa se lleva a cabo el estudio de las posibles amenazas y probables eventos no deseados, así como de los daños y consecuencias que éstas puedan producir. Los riesgos son registrados, evaluados y luego reducidos utilizando prototipos, simulaciones y softwares de análisis. En este ciclo, existen varios prototipos como plantillas de diseño o componentes funcionales. 4. Planificación: en esta parte se revisa todo lo hecho, evaluándolo, para con ello decidir si se continuará con las fases siguientes y así planificar la próxima actividad. 5. Desarrollar y probar: aquí entra el proceso propio de desarrollo o programación y la parte de pruebas para la detección y corrección de errores. Los prototipos se amplían y se añaden funcionalidades. El código real es escrito, probado y migrado a un entorno de pruebas varias veces hasta que el software pueda ser implementado en un entorno productivo.

Figura 2- Diagrama de Modelo en Espiral

Black Rex (2011). Fundamentos de Pruebas de Software. Editorial. RBCS, Inc.

Ventajas:

• El modelo de desarrollo en espiral se utiliza a menudo para proyectos más grandes que están sujetos a riesgos. Dado que estos riesgos tienen un impacto monetario directo, el control de los presupuestos de los clientes y de las empresas promotoras es fundamental. El modelo en espiral se utiliza especialmente en los nuevos entornos técnicos, ya que estos suponen un riesgo.

• Los conflictos entre los requisitos de un software y su diseño se evitan eficazmente mediante el enfoque cíclico, ya que los requisitos pueden comprobarse constantemente y, si es necesario, modificarse.

Desventajas:

• Se puede obtener feedback de los usuarios, desarrolladores y clientes en las primeras fases del proyecto. Sin embargo, esta estructura también requiere una gestión que tenga en cuenta los ciclos del producto y pueda responder rápidamente a los riesgos. El control de tales proyectos es, por lo tanto, relativamente complejo y también requiere una buena documentación para que se registren todos los cambios.

• Aunque el software se prueba bajo varios aspectos durante el ciclo de desarrollo y prueba (unidad, prueba de aceptación e integración), a menudo sucede que los prototipos se transfieren al sistema de producción. Por lo tanto, existe el riesgo de que se introduzcan otros errores e incoherencias conceptuales en el producto final posterior.

• En los lugares donde se toman decisiones sobre los ciclos siguientes, existe el riesgo de que se formen bucles y el proyecto tarde más tiempo si se toman decisiones equivocadas. Por esta razón, las alternativas y su evaluación son importantes.

2.2.1.3 Modelo de desarrollo Incremental El desarrollo incremental es el proceso de construcción que consiste en incrementar nuevas especificaciones de requerimientos al diseño del sistema original (Figura 4).

Típicamente un documento de requerimientos es escrito al capturar todas las necesidades que tiene el usuario para el sistema completo. Sin embargo, este modelo permite agregar nuevas funcionalidades interdependientes a las ya hechas.

El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Provee algunos beneficios significativos para los proyectos de desarrollo de software.

En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”,

11 utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.

El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software.

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.

Figura 3.- Diagrama del modelo de Desarrollo Incremental

Black Rex (2011). Fundamentos de Pruebas de Software. Editorial. RBCS, Inc.

Es el mismo cliente o usuario el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros modelos de desarrollo, el Modelo Incremental es de naturaleza interactiva, pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El desarrollo incremental es útil en particular cuando no se dispone de personal para la implementación completa del proyecto en el plazo establecido por el negocio. Los primeros incrementos se desarrollan con pocos trabajadores. Si el producto básico es bien recibido, entonces se agrega más personal (si se requiere) para que labore en el siguiente incremento. Además, los incrementos se planean para administrar riesgos técnicos. Por ejemplo, un sistema grande tal vez requiera que se disponga de hardware nuevo que se encuentre en desarrollo y cuya fecha de entrega sea incierta. En este caso, tal vez sea posible planear los primeros incrementos de forma

12 que eviten el uso de dicho hardware, y así proporcionar una funcionalidad parcial a los usuarios finales sin un retraso importante.

Ventajas:

• Construir sistemas pequeños • Si un error importante es detectado, sólo el último cambio realizado necesita ser descartado, es decir, la versión anterior a los últimos cambios es la que puede ser utilizada. • Reducción del tiempo de desarrollo, lo cual evita una redefinición del requerimiento. • Los errores de desarrollo cometidos en un incremento o cambio, pueden ser arreglados antes del comienzo del próximo incremento. • Mediante este modelo se genera software operativo de forma rápida y en etapas tempranas del ciclo de vida del software. • Es un modelo más flexible, por lo que se reduce el coste en el cambio del alcance y requisitos. • Es más fácil probar y depurar en una iteración más pequeña.

Desventajas:

Para el uso de esto modelo se requiere una experiencia importante para definir los incrementos y descubrir en ellos las tareas de forma proporcionada. Entre los inconvenientes que aparecen en el uso de este modelo podemos destacar los siguientes:

• El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido o de alto índice de riesgos. • Requiere de mucha planeación, tanto administrativa como técnica. • Requiere de metas claras para conocer el estado del proyecto. • Cada fase de una iteración es rígida y no se superponen con otras. • Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añade, de ser necesario. Por otro lado, los incrementos se pueden planear para gestionar riesgos técnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminará siendo la solución completa requerida por el cliente, pero éstas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con más urgencia, de los puntos más importantes del proyecto, los requerimientos más básicos, difíciles y con mayor grado

13 de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versión.

De este modo podemos terminar una aplicación ejecutable (primera versión) que podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la siguiente versión junto con los demás requerimientos que no fueron tomados en cuenta en la versión anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores.

2.2.1.4 Modelo de desarrollo Evolutivo El software como, como todos los sistemas complejos, evoluciona en el tiempo. Es frecuente que los requerimientos del negocio y del producto cambien conforme avanza el desarrollo, lo que hace que no sea realista trazar una trayectoria rectilínea hacia el producto final; los plazos apretados del mercado hacen que sea imposible la terminación de un software perfecto, pero debe lanzarse una versión limitada a fin de aliviar la presión de la competencia o del negocio; se comprende bien el conjunto de requerimientos o el producto básico, pero los detalles del producto o extensiones del sistema aún están por definirse. En estas situaciones y otras parecidas se necesita un modelo de proceso diseñado explícitamente para adaptarse a un producto que evoluciona con el tiempo.

Los modelos evolutivos son iterativos. Se caracterizan por la manera en que permiten desarrollar versiones cada vez más complejas de software.

Al igual que el modelo de Desarrollo Incremental, el modelo de Desarrollo Evolutivo construye una serie de grandes versiones sucesivas de un producto.

Sin embargo, mientras el modelo incremental asume que el conjunto completo de requerimientos es conocido desde el comienzo. Por otro lado, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo aquellos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del software que recibe únicamente estos requerimientos.

El software es entonces desarrollado, se realizan pruebas con la ayuda de los usuarios para proporcionar de ser necesario retroalimentación a los desarrolladores. De esta manera la especificación de requerimientos es actualizada, y una segunda versión del producto es

14 desarrollada. El proceso se repite tantas veces se requiera cambiar las reglas o procesos del sistema.

Todo lo que los líderes de proyecto tienen que hacer es construir un subconjunto de requerimientos conocidos de forma incremental (Figura 5), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desarrollado.

El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de prueba, etc., desarrollados para distintas versiones del software.

Figura 5.- Diagrama del modelo de Desarrollo Evolutivo

Black Rex (2011). Fundamentos de Pruebas de Software. Editorial. RBCS, Inc.

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.

Existen dos tipos de desarrollo evolutivo:

• Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario. • Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un

prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

Ventajas: • La especificación puede desarrollarse de forma creciente. • Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software. • Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente. • Se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración. Desventajas: • Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema. • Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento. • Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar. • Hacer prototipos plantea un problema para la planeación del proyecto debido a la incertidumbre en el número de ciclos que se requieren para elaborar el producto. La mayor parte de técnicas de administración y de estimación de proyectos se basa en un planteamiento lineal de las actividades, por lo que no se ajustan por completo. • Los procesos evolutivos de software no establecen la velocidad máxima de la evolución. Si las evoluciones ocurren demasiado rápido, sin un período de relajamiento, es seguro que el proceso se volverá un caos. Por otro lado, si la velocidad es muy lenta, se verá perjudicada la productividad. • Los procesos de software deben centrarse en la flexibilidad y capacidad de extensión en lugar de en la alta calidad. Esto suena preocupante. Sin embargo, debe darse prioridad a la velocidad del desarrollo con el enfoque de cero defectos. Extender el desarrollo a fin de lograr alta calidad podría dar como resultado la entrega tardía del producto, cuando haya desaparecido el nicho de oportunidad. Este cambio de paradigma es impuesto por la competencia al borde del caos. En realidad, si parece preocupante un proceso del software que se centre en la flexibilidad, expansión y velocidad del desarrollo por encima de la calidad. No obstante, esta idea ha sido propuesta por varios expertos en ingeniería de software muy respetados.

El objetivo de los modelos evolutivos es desarrollar software de alta calidad en forma iterativa o incremental. Sin embargo, es posible usar un proceso evolutivo para hacer énfasis en la flexibilidad, expansibilidad y velocidad del desarrollo. El reto para los equipos de software y sus administradores es establecer un balance apropiado entre estos parámetros críticos del proyecto, y la satisfacción del cliente (árbitro definitivo de la calidad del software).

2.2.2 Modelos de construcción de software actuales Durante varios años se ha utilizado el modelo tradicional en cascada, demostrando en la práctica que no refleja en la realidad la complejidad inherente al proceso de desarrollo de software. Este problema es derivado de la naturaleza implícita de la estructura de este modelo, definido por una secuencia de grandes etapas que requieren alcanzar hitos que deben ser concluidos antes de continuar con la siguiente fase.

Como una alternativa de solución a este problema, se definieron posteriormente los modelos iterativos e incrementales que trabajan adecuadamente con niveles altos de riesgo, y permiten entregar liberaciones de software en etapas tempranas; tal es el caso del Proceso Unificado propuesto por IBM, que incluye prácticas claves y aspectos relacionados a la planeación estratégica y administración de riesgos; y actualmente guían de forma natural el proceso de desarrollo de software complejo por lo que ha sido considerado como un estándar el desarrollo de software en las empresas.

Para elegir cual es modelo de desarrollo de software más adecuado, debe considerarse el tipo de software a desarrollar (que puede ser el propósito específico, educativo, tiempo real, etc.), la premura y el entorno de globalización, los estándares que se emplean en el sitio de desarrollo (empresa consultora de software o lugar de trabajo), los dispositivos donde correrá el software (móviles) o sí el software será para la web.

Por ejemplo, si el desarrollador trabaja por su cuenta, podría escoger la del Ciclo de Vida, que es la más sencilla y sigue todos los pasos formales para obtener un producto de calidad. Para el caso de productos muy grandes y complejos que requieren revisiones por etapas y que el cliente o usuario las apruebe progresivamente, se recomienda utilizar el modelo de Espiral o Evolutiva. Si es el caso de una empresa que ya cuenta con sistemas funcionales pero es necesario actualizarlos debido a nuevas tecnologías computacionales de hardware y software, entonces se recomienda el modelo de Reingeniería o el desarrollo basado en componentes. Si es necesario entregar los productos de software en tiempo breve y que se adapten de inmediato a los cambios de tecnologías, para lograrlo es necesario un equipo de trabajo conformado por individuos muy comprometidos cuya capacidad y habilidad para colaborar es el fundamento para el éxito del proyecto, entonces es conveniente seleccionar un modelo ágil.

Todas las metodologías tienen ventajas que se pueden aprovechar, dependiendo de las condiciones del software que se pretenden desarrollar; de igual forma presentan desventajas cuando no se consideran todos los factores que intervienen al realizar el trabajo. Lo importante es utilizar siempre un modelo de desarrollo apropiado, para lo cual, si es la primera vez que se empleará, es necesario conseguir información y documentación sobre ella. En el caso de que ya se haya utilizado lo recomendable es actualizarse y adaptarla lo mejor posible para obtener un producto de calidad que cumpla con los requerimientos funcionales y no funcionales.

2.2.2.1 Proceso Racional Unificado (RUP) Es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentación, garantizando el cumplimiento de ciertos estándares de calidad. Aunque con el inconveniente de generar mayor complejidad en los controles de administración del mismo. Sin embargo, los beneficios obtenidos recompensan el esfuerzo invertido en este aspecto.

El proceso de desarrollo constituye un marco metodológico que define en términos de metas estratégicas, objetivos, actividades y artefactos (documentación) requerido en cada fase de desarrollo. Esto permite enfocar esfuerzo de los recursos humanos en términos de habilidades, competencias y capacidades a asumir roles específicos con responsabilidades bien definidas.

Estructura del ciclo de vida del proceso de desarrollo unificado:

1. Fase de concepción: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos potenciales asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones. 2. Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar. 3. Fase de construcción: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo con las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. 4. Fase de transición: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

Este tipo de metodología no ha sido aplicada probablemente por su complejidad de administración o desconocimiento de la misma, desaprovechando sus considerables ventajas respecto a los métodos tradicionales. Por esto, es necesario entonces desarrollar mecanismos de apropiación tecnológica más eficaces, que permitan mantener actualizadas las prácticas organizacionales y los marcos de referencia aquí mencionados. Es aquí, donde es necesario considerar que el conocimiento de la metodología y desarrollo de habilidades de los analistas, programadores, administradores de bases de bases de datos y demás miembros del equipo de desarrollo, comienzan desde su preparación universitaria donde es necesario conocer este enfoque y aplicarlo en proyectos en donde utilicen las guías de trabajo definidas en el RUP y desarrollen los artefactos asociados; esperando que con la práctica alcancen un nivel de madurez en la asimilación del proceso unificado (RUP).

De esta manera en la asignatura de análisis y diseño de sistemas de información II, que se imparte a los estudiantes del programa educativo de Tecnologías de la información y comunicación, se desarrolla un proyecto de simulación tipo basado en la metodología de trabajo del Proceso Unificado Rational, utilizando la herramienta CASE “Rational Unified Process” que es un sitio WEB en línea que los alumnos consultan para entender los términos en que debe ser realizada la documentación y diseño de los programas informáticos que construyen.

Características:

• Dirigido por Casos de Uso: Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema • Centrado en la Arquitectura: La arquitectura es utilizada para conceptualizar, construir, administrar y evolucionar el sistema en desarrollo • Iterativo e Incremental: Maneja una serie de entregas ejecutables e integra continuamente la arquitectura para producir nuevas versiones mejoradas • Conceptualmente amplio y diverso • Enfoque orientado a objetos

Ventajas:

• Requiere de conocimientos del proceso de UML. • Progreso visible en las etapas tempranas. • El uso de iteraciones. • Evaluación de riesgos en lugar de descubrir en la integración final del sistema • Facilita la reutilización de código.

Desventajas:

• Por el grado de complejidad puede resultar no muy adecuado. • Mal aplicado en el estilo de cascada.

2.2.2.2 Modelo PPS Todo desarrollo utiliza algún proceso para elaborar software de cómputo. El proceso puede ser caprichoso o ad hoc; quizá cambie a diario; tal vez no sea eficiente, eficaz o incluso no sirva; pero sí existe un “proceso”. Watts Humphrey sugiere que, a fin de cambiar un proceso personal ineficaz, un individuo debe pasar las cuatro fases, cada una de las cuales requiere capacitación e instrumentación cuidadosa. El proceso personal del software (PPS) pone el énfasis en la medición personal tanto del producto del trabajo que se genera como de su calidad. Además, el PPS responsabiliza al profesional acerca de la planeación del proyecto (por ejemplo, estimación y programación de actividades) y delega en el practicante el poder de controlar la calidad de todos los productos del trabajo de software que se desarrollen. El modelo PPS define cinco actividades estructurales:

• Planeación. Esta actividad aísla los requerimientos y desarrolla las estimaciones tanto del tamaño como de los recursos. Además, realiza la estimación de los defectos (el número de defectos proyectados para el trabajo). Todas las mediciones se registran en hojas de trabajo o plantillas. Por último, se identifican las tareas de desarrollo y se crea un programa para el proyecto. • Diseño de alto nivel. Se desarrollan las especificaciones externas para cada componente que se va a construir y se crea el diseño de componentes. Si hay incertidumbre, se elaboran prototipos. Se registran todos los aspectos relevantes y se les da seguimiento. • Revisión del diseño de alto nivel. Se aplican métodos de verificación formal para descubrir errores en el diseño. Se mantienen las mediciones para todas las tareas y resultados del trabajo importantes. • Desarrollo. Se mejora y revisa el diseño del componente. El código se genera, revisa, compila y prueba. Las mediciones mantienen para todas las tareas y resultados de trabajo de importancia. • Post mórtem. Se determina la eficacia del proceso por medio de medidas y mediciones obtenidas (ésta es una cantidad sustancial de datos que deben analizarse con métodos estadísticos). Las medidas y mediciones deben dar la guía para modificar el proceso a fin de mejorar su eficacia.

PPS – Process Personal de Software: es un esquema de trabajo definido y medible que ayuda a los desarrolladores en la planificación y medición de su trabajo, generando productos de alta calidad. La metodología señala cómo administrar la calidad del producto de software y cómo formular metas

20 alcanzables. Con los datos que se registran en diversos formularios, el desarrollador puede predecir en forma más acertada el tamaño del software (medidas en LOC- Lines Of Code- líneas de código) y al conocer su productividad (LOC/hora) puede estimar en forma más precisa el tiempo que tardará en su desarrollo y, por consiguiente, justificar la planificación de su proyecto.

La metodología PPS se puede aplicar a los diferentes procesos de desarrollo de software, incluyendo el desarrollo de programas pequeños, definición de requerimientos, tareas de documentación de programas, pruebas de sistemas, y a alimentar grandes sistemas.

Se ha podido comprobar que PPS mejora significativamente la habilidad para estimar y planificar los proyectos como, también, reduce en forma importante la cantidad de defectos incluidos en los productos de software generados.

La mejoría en la calidad de los productos de software se refleja a través de la aplicación de la metodología PPS, ya que ésta instruye a trabajar en forma disciplinada. Existen prácticas claves que son inculcadas paulatinamente a medida que se avanza de versión en PPS, tales como:

• Rastreo de los defectos. El hecho de tener que llevar rastro de los defectos incluidos, conlleva a que el desarrollador que sea más cuidadoso en su trabajo. • Costo en la remoción de defectos. Cuando se analiza el formulario de registro de defectos se toma conciencia del costo involucrado (básicamente por tiempo. Esto provoca que el desarrollador logre una mejor comprensión del costo en remover defectos y, de esta manera, aplique métodos más efectivos para encontrarlos y repararlos, como por ejemplo a través de la planificación de la etapa de testing. • Aplicación de prácticas de calidad. La metodología PPS introduce una gama de prácticas de calidad que han demostrado ser efectivas en la prevención de defectos, tales como revisión de diseño de alto nivel y nivel detallado, revisión de codificación y reúso de código.

La metodología PPS se compone de siete versiones, cada una introduce nuevos elementos que son registrados en diversos formularios, cada formulario es usado para registrar los problemas encontrados durante el proceso de desarrollo del software y las propuestas para su solución.

El PPS tiene obsesión por la toma de datos y elaboración de tablas. El PPS se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.

Ventajas:

• Efectuando un paralelo entre la cantidad de LOC totales estimadas contra la cantidad de LOC totales reales de los dos primeros programas, en promedio, en comparación con el promedio de los dos últimos, se obtiene una reducción en un 24.5% de error en la estimación del tamaño del producto de software.

• La estimación de tamaño con 70% predicción es acertada en cinco programas de un total de siete (y no 10, pues para los programas 1A, 2A, y 3A no hay datos suficientes para aplicar la regresión). Los dos restantes tienen acierto dentro del 90% de predicción. • Efectuando un paralelo entre la estimación de la duración de los programas v/s la duración real, de los tres primeros programas en promedio, en comparación con el promedio de los tres últimos, se obtiene una reducción del 56.7%. • Comparando el proceso para efectuar las estimaciones de LOC v/s estimaciones de tiempos, se concluye que es más fácil efectuar los cálculos.

Desventajas:

• Es necesario que cada uno de los miembros tiene que tener el compromiso y la disciplina de seguir el plan. • Debe llenar toda la documentación requerida que incluye sus registros, planificación, las plantillas o formularios. • Se debe de contar con un buen conjunto de métricas y parámetros de calidad, lo cual, para algunas organizaciones, puede ser difícil de definir. • Cada miembro debe estar entrenado en el PPS, si algún miembro se va, es necesario entrenar a los nuevos miembros.

2.2.2.3 Metodologías Ágiles Los métodos ágiles se desarrollaron como un esfuerzo por superar las debilidades reales y percibidas de la ingeniería de software convencional. El desarrollo ágil proporciona beneficios importantes, pero no es aplicable a todos los proyectos, productos, personas y situaciones. No es la antítesis de la práctica de la ingeniería de software sólida y puede aplicarse como filosofía general para todo el trabajo de software.

Cualquier proceso del software ágil se caracteriza por la forma en que aborda cierto número de suposiciones clave acerca de la mayoría de proyectos de software:

1. Es difícil predecir qué requerimientos de software persistirán y cuales cambiarán. También es difícil pronosticar como cambiarán las prioridades del cliente a medida que avanza el proyecto. 2. Para muchos tipos de software, el diseño y la construcción están imbricados. Es decir, ambas actividades deben ejecutarse en forma simultánea, de modo que los modelos de diseño se prueben a medida que se crean. Es difícil predecir cuanto diseño se necesita antes de que se use la construcción para probar el diseño. 3. El análisis, el diseño, la construcción y las pruebas no son tan predecibles como nos gustaría (desde un punto de vista de planeación).

Dadas estas tres suposiciones, surge una pregunta importante: ¿cómo crear un proceso que pueda manejar lo impredecible? La respuesta, como ya se dijo, está en la adaptabilidad del proceso (al cambio rápido del proyecto y a las condiciones técnicas). Por tanto, un proceso ágil debe ser adaptable.

Pero la adaptación continua logra muy poco si no hay avance. Entonces, un proceso de software ágil debe adaptarse incrementalmente. Para lograr la adaptación incremental, un equipo ágil requiere retroalimentación con el cliente (de modo que sea posible hacer las adaptaciones apropiadas). Un catalizador eficaz para la retroalimentación con el cliente es un prototipo operativo o una porción de un sistema operativo. Así, debe instituirse una estrategia de desarrollo incremental. Deben entregarse incrementos de software (prototipos ejecutables o porciones de un sistema operativo) en periodos cortos de tiempo, de modo que la adaptación vaya a ritmo con el cambio (impredecible). Este enfoque iterativo permite que el cliente evalúe en forma segura el incremento de software, dé la retroalimentación necesaria al equipo de software e influya en las adaptaciones del proceso que se realicen para aprovechar la retroalimentación.

Las metodologías ágiles son una serie de técnicas para la gestión de proyectos que ha surgido como contraposición a los métodos clásicos de gestión. Todas las metodologías que se consideran de este tipo deben cumplir con el manifiesto ágil: que es una serie de principios definidos en el año 2001 y se agrupan en 4 puntos:

• Los individuos y su interacción, por encima de las herramientas • El software que funciona, frente a la documentación extensiva • La colaboración con el cliente, por encima de la negociación contractual • La respuesta al cambio, por encima del seguimiento de un plan Debido a un estudio realizado recientemente (2008), fuente Scott W. Metodología Scrum

Es una metodología ágil flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente: la inspección continua, adaptación, auto-gestión.

Con la metodología Scrum el cliente visualiza y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Así mismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema. Ésta es una metodología considerada como de las recientes o actuales, aunque lleva entre 10 años trabajando aproximadamente, con resultados logrados y nuevas tendencias que llevan a la forma ágil cómo una de las mejores.

Scrum parte de un elemento fundamental que es: una lista de funcionalidades o tareas de la aplicación llamada Backlog

En este modelo un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

La lista de objetivos o requerimientos actúa como plan del proyecto. En esta lista el usuario prioriza los objetivos y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversión mediante la re planificación de objetivos del producto, que realiza durante la iteración con vista a las siguientes iteraciones. El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De acuerdo a un estudio realizado en empresas de Estados Unidos de América en 2010, se muestra (ver Figura 5) qué tanto las empresas han adoptado metodologías ágiles como su forma de trabajo:

Figura 6.- Adopción Ágil en las empresas

Bravo Carrasco Juan. (2016). Reingeniería de Negocio. Editorial. Sol.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. Las actividades que se llevan a cabo en el modelo Scrum se explican a continuación:

• Planificación de la iteración: El primer día de la iteración se realiza la reunión de planificación de la iteración. • Selección de requisitos: el usuario presenta al equipo la lista de requisitos priorizada del proyecto. El equipo de desarrollo pregunta al usuario las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración. • Planificación de la iteración: el equipo elabora la lista de tareas necesarias de la iteración para desarrollar los objetivos que se ha comprometido a entregar. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se asignan las tareas.

Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas:

• ¿Qué he hecho desde la última reunión de sincronización? • ¿Qué voy a hacer a partir de este momento? • ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el líder:

• Se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. • Elimina los obstáculos que el equipo no puede resolver por sí mismo. • Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

Inspección y adaptación: el último día de la iteración se realiza la reunión de revisión.

• Demostración: el equipo presenta al usuario los objetivos completados en la iteración, en forma de incremento de producto preparado para ser entregado • Retrospectiva: el equipo analiza cómo ha sido su forma de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El líder se encargará de eliminar los obstáculos identificados.

Ventajas:

Cumplimento de expectativas: el usuario establece sus expectativas indicando el valor que le aporta cada requisito; con esta información el equipo de desarrollo estima sus prioridades.

• Flexibilidad a cambios: alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del usuario. • Reducción tiempos: el usuario puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo. • Mayor calidad del software: la forma de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención mayor calidad. • Mayor productividad: se consigue entre otras razones, gracias a la motivación del equipo de desarrollo que proporciona el hecho de que sean autónomos para organizarse. • Reducción de riesgos: el hecho de llevar a cabo las tareas de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

Desventajas:

• Existe la tendencia que si se deja una tarea sin terminar y que por las exigencias del Dueño del Producto se deban realizar otras nuevas. Estas tareas no terminadas pueden obstaculizar la planeación de nuevas sprints y se deba volver al problema original. • Alto nivel de stress de los miembros del equipo, el desgaste puede ser excesivo y estresante lo que puede disminuir el rendimiento. • La necesidad de contar con equipos multidisciplinarios puede ser un problema, porque cada integrante del equipo debe estar en capacidad de resolver cualquier tarea y no siempre se cuenta con este perfil en la empresa. • El equipo puede estar tentado de tomar el camino más corto para cumplir con un sprint, que no necesariamente puede ser el de mejor calidad en el desarrollo del producto.

Esta forma de trabajo promueve la innovación, motivación y compromiso de todos los integrantes del equipo al llevar a cabo cada proyecto, por esto los profesionales encuentran un ámbito propicio para desarrollar sus capacidades y cumplir sus objetivos.

2.3 Calidad del Software La calidad en términos generales se describe como el grado en que un sistema, componente o proceso se ajusta con los requerimientos especificados y la manera en la que éste se ajusta con las necesidades y expectativas de cualquier cliente o usuario.

Es en otras palabras se refiere a la totalidad de características que una entidad debe brindar, teniendo como principal soporte su habilidad de satisfacer estados y necesidades implicadas.

El concepto de calidad no es algo nuevo, ya que a lo largo de la historia la humanidad ha buscado la perfección en los productos o servicios que ofrecen; ésta búsqueda ha sido constante, de forma

26 que el interés por el trabajo bien hecho y la necesidad de asumir responsabilidades sobre la labor efectuada derivó gradualmente en la noción que hoy tenemos de calidad.

2.3.1 Calidad Informática Entre los retos persistentes para triunfar en el desarrollo de software, se encuentran el de resolver problemas como bajo rendimiento o usabilidad, así como el de atacar funcionalidades deficientes; estos problemas pueden impedir que el software cumpla con las necesidades de mercado y los objetivos de negocio, es decir, mermar su calidad.

Debido a las tendencias actuales como son: elevados costos, complejidad y la velocidad del desarrollo de software, las empresas tienen que encontrar un equilibrio entre las prioridades de los proyectos sin comprometer la calidad del software.

La calidad de software busca alcanzar dentro de un producto de software características tales como: confiabilidad, soporte de logística, agilidad de respuesta, flexibilidad, facilidad de adopción, integridad, constancia, congruencia de diseño-producto, sencillez de uso, entre otros.

Otras características que debe cumplir un producto de software son: corrección, fiabilidad, eficiencia, facilidad de uso, facilidad de mantenimiento, entre otras. Mientras éste producto reúna más características durante el proceso de desarrollo, mayor será su calidad.

La calidad del diseño se refiere a las características que los diseñadores especifican para un producto. En el desarrollo de software, la calidad del diseño incluye el grado en el que el diseño cumple las funciones y características especificadas en el modelo de requerimientos. La calidad de la conformidad se centra en el grado en el que la implementación se apega al diseño y en que el sistema resultante cumpla sus metas de requerimientos y desempeño.

Como vemos la calidad es un aspecto de suma importancia, y si bien la preocupación por la calidad de los sistemas basados en software ha aumentado a medida que se integran en cada aspecto de nuestras vidas cotidianas, es difícil hacer la descripción exhaustiva de la calidad de software.

Existen varios modelos de calidad muy útiles que pueden ser usados para evaluar y medir la calidad de software, algunos de ellos son: el modelo SPICE, el modelo CMM, el modelo PROSOFT y MOPROSOFT, entre otros.

Con el tiempo se han propuesto varias dimensiones y factores de calidad del software. Todos ellos tratan de definir un conjunto de características que, si se logran, llevarán a un software de alta calidad. McCall y los factores de calidad de la norma ISO 9126 establecen características tales como confiabilidad, usabilidad, facilidad de dar mantenimiento, funcionalidad y portabilidad, como indicadores de la existencia de calidad.

Toda organización de software se enfrenta al dilema de la calidad. En esencia, todos quieren elaborar sistemas de alta calidad, pero en un mundo dirigido por el mercado, sencillamente no se dispone del tiempo y el esfuerzo requeridos para producir software “perfecto”. La cuestión es la siguiente: ¿debe elaborarse software que sea “suficientemente bueno”?. Aunque muchas compañías hacen eso, hay una desventaja notable que debe tomarse en cuenta.

La calidad tiene un costo que puede estudiarse en términos de prevención, evaluación y falla. Los costos de prevención incluyen todas las acciones de la ingeniería de software diseñadas para prevenir los defectos. Los costos de evaluación están asociados con aquellas acciones que evalúan los productos del trabajo de software para determinar su calidad. Los costos de falla incluyen el precio interno de fallar y los efectos externos que precipitan la mala calidad.

La calidad de software se consigue por medio de la aplicación de métodos de ingeniería de software, prácticas adecuadas de administración y un control de calidad exhaustivo, todo lo cual es apoyado por la infraestructura de aseguramiento de la calidad.

Para aumentar la calidad se establecen una serie de metodologías formales y buenas prácticas que permiten tener control sobre lo que está ocurriendo en todos los niveles del ciclo de vida del software y así poder evaluarlo y mejorarlo. Gracias a ellas se consigue no solo que el producto final tenga las características deseadas (mencionadas arriba) sino que los procesos asociados sean positivos, los tiempos de entrega disminuyan, los costos se reduzcan y la satisfacción del usuario final sea la esperada.

Por supuesto existen modelos, métricas y herramientas que completan estos procesos y ayudan a la mejora de la calidad.

2.3.2 Fundamentos de Calidad de Software La palabra calidad tiene varios significados, aunque dentro de la Ingeniería del Software podemos adoptar la definición de la norma ISO-8402, que luego se repite en otras (por ejemplo, en ISO- 14598): “La totalidad de aspectos y características de un producto o servicio que tienen que ver con su habilidad para satisfacer las necesidades declaradas o implícitas”.

Aunque la calidad es un objetivo importante para cualquier producto, no debemos olvidar que los productos, y también los productos software, se construyen para ser utilizados. Por tanto, el principal objetivo de un producto es satisfacer una necesidad (o varias) de un usuario y, por consiguiente, ofrecer al usuario algún beneficio por su utilización. Es decir, la calidad no es el objetivo último del producto, sino satisfacer las necesidades de un cliente.

También es importante señalar que esto implica que la calidad de un producto software no se puede referir únicamente a obtener un producto sin errores. La especificación de la calidad del software debe ser más detallada y exacta, y el camino para ello es la formalización de la calidad mediante un

28 modelo de calidad que, como veremos a continuación, define las características de un producto que influyen a la hora de medir su calidad.

Otro aspecto importante que frena a los desarrolladores de software en cuanto a lograr la calidad en sus productos es que esta industria exige y crece más rápido que las mismas metodologías y capacidad de las personas, porque aunque todo se facilita poco a poco por ejemplo el uso de herramientas CASE (Software de Ingeniería asistida por Computadora), la ingeniería de software requiere todavía de mucho capital humano altamente capacitado.

La calidad en el desarrollo y el mantenimiento del software se ha convertido hoy en día en uno de los principales objetivos estratégicos de las organizaciones, debido a que cada vez más, sus procesos principales (y su supervivencia) dependen de los sistemas informáticos para su buen funcionamiento.

Es claro que todas las aplicaciones que pueden tener el software deben ser productos de alta calidad: fáciles de usar, confiables y seguros, tan rápidos como necesite el cliente, baratos en relación con sus prestaciones, flexibles y fáciles de mantener y modificar.

En las tecnologías de la información es necesario basarse en una alineación a las estrategias empresariales. En particular cabe destacar la importancia del planeamiento empresarial. La calidad se logra revisando los procesos formales de reingeniería. Reafirmando existen tres elementos que se deben de tomar en cuenta para obtener calidad informática: el plan empresarial, la arquitectura de procesos y la arquitectura delas tecnologías de la información.

2.3.3. Parámetros de la Calidad de Software La definición de atributos y métricas para componentes, dentro de un modelo de calidad, tiene como objetivo la mejora de los procesos.

COTS

El modelo COST se compone de cuatro sub modelos que recogen las cuatro principales fuentes de los costes de integración de componentes:

• Valoración (Assessment) es el proceso mediante el cual los componentes COTS son seleccionados para ser integrados en el sistema que se está desarrollando. • Adaptación (Tailoring) se refiere a las actividades que siempre hay que realizar para particularizar el componente, independientemente del producto donde se va a integrar. Por ejemplo, inicializar los valores de los parámetros, especificar pantallas de E/S o formato de los informes, configurar protocolos de seguridad, etc. • Código de Integración (Glue Code) es el código nuevo que hay que desarrollar y probar, externo a los COTS, pero necesario para integrar los componentes COTS en un sistema.

• Finalmente, la volatilidad (Volatility) tiene en cuenta la frecuencia con la cual aparecen en el mercado nuevas versiones o actualizaciones de los componentes COTS que se están utilizando en el sistema durante su desarrollo y puesta en funcionamiento. • Una desventaja de este modelo es que no se llega a definir ningún conjunto de atributos de calidad (es decir, un modelo de calidad), lo cual limita bastante su utilización práctica.

QESTA

Otro trabajo de gran interés relativo a los temas de calidad en DSBC (Desarrollo de Software Basado en la Calidad) es el presentado por Hansen, el cual plantea un proceso de evaluación para seleccionar el mejor candidato de los posibles componentes que se puedan utilizar. Este proceso se denomina QESTA: “Quantification, Examination, Specification, Transformation, Aggregation”. QUESTA está basado en un conjunto de “operaciones” básicas, que son las que van a definir un proceso que permita realizar una evaluación efectiva de componentes software. A su vez, cada operación viene determinada por sus datos de entrada, sus datos de salida, y una descripción de su objetivo y comportamiento básico. Se concentra en las siguientes fases:

• Cuantificación • Examen • Especificación • Transformación • Integración

Esta propuesta tampoco concreta los atributos de calidad (o “métricas” en su terminología) que se deben medir dentro del proceso QESTA. Esto limita su aplicación inmediata, aunque posiblemente esta sea la propuesta que presenta el proceso de evaluación mejor especificado.

COTS-Based Requirements Engineering (CRE)

El método CRE se desarrolla para facilitar el proceso de selección y evaluación basado en los requisitos, prestando una especial atención al análisis de los requisitos extra-funcionales.

La selección de componentes se realiza por rechazo, es decir, los componentes candidatos que no cumplen alguno de los requisitos del cliente van siendo rechazados y retirados de la lista de candidatos. Conforme esta lista va decreciendo, es necesario aumentar el número y el detalle de los requerimientos. El resultado es un proceso iterativo mediante el cual el proceso de adquisición de los requisitos permite la selección de productos y, adicionalmente, el propio proceso de selección genera información para la obtención de nuevos requisitos de calidad.

CRE es un método orientado a objetivos, es decir, cada fase se orienta hacia conseguir unos objetivos predefinidos. Para ello, cada fase tiene unas plantillas que incluyen guías y técnicas para la adquisición o modelado de requisitos y para la evaluación de productos.

Este método tiene cuatro fases iterativas

• Identificación • Descripción • Evaluación • Aceptación

Existen dos modelos más para definir las características de calidad en el desarrollo de software, de los cuales sólo se hará una puntual mención:

1. Off-The-Shelf Option (OTSO) 2. Procurement-Oriented Requirements Engineering (PORE)

Si bien son claras las ventajas que reporta disponer de esas métricas, también hay que ser conscientes de las dificultades que esto conlleva. En primer lugar, no pensamos que los fabricantes de componentes alcancen fácilmente un consenso sobre los parámetros de calidad que hay que medir en ellos, y menos que estén dispuestos a facilitar toda esa información. Razones comerciales, de marketing y de imagen van a dificultar que parámetros negativos (como el tiempo de fallos, o la ausencia de alguna cualidad importante) sean publicados por los fabricantes. Por otro lado, cada empresa está más interesada en resaltar aquellos atributos en los que sus componentes sean competitivos, restándole importancia a aquellos que no se implementen o para los que no se alcancen buenos valores. Personalmente creemos que esos factores son principalmente los que ocasionan gran parte de las dificultades con las que se está encontrando ISO a la hora de aprobar las normas sobre métricas –aparte de porque sean demasiado genéricas, por supuesto–, y el problema es que dichas dificultades tienen una difícil solución por el marcado carácter comercial de sus motivaciones.

La calidad total en Informática, es el resultado del movimiento global dentro del proceso de mejoramiento continuo de los estándares de producción en todos los sectores industriales, en particular, cuando éste se concentra en la producción de sistemas de información y software especializado. La calidad total no es un producto sino una actividad.

Un programa de gestión y aseguramiento de la calidad comienza por elegir un modelo y establecer una definición de calidad para identificar componentes de tipo “resultado” y de tipo “contribuyente”.

Los componentes de tipo resultado son unidades bajo las cuales el usuario emite un juicio sobre el producto. Estas unidades son de mucha relevancia a la actividad del usuario. Ejemplos de éstas son: el número de veces que no pudo emitir una póliza porque sus sistemas fallaron o la pérdida de oportunidades de negocio por no contar con la información pertinente.

Las unidades contribuyentes son de tipo técnico y están orientadas a la tecnología informática; como ejemplo de ellas se puede citar el número de veces que se pierde la comunicación en un día o el tiempo que se requiere para levantar una base de datos.

2.3.4 Calidad en los procesos de Ingeniería de Software Un proceso de software se refiere al conjunto de actividades, métodos, prácticas y transformaciones que se utilizan para desarrollar y mantener un software, así como sus productos asociados (planes, documentación, código, pruebas, manuales, etc.).

Ahora bien, un método de mejoramiento de procesos es un conjunto de procedimientos y herramientas para mejorar la calidad del producto.

Es decir, la calidad del proceso es cuando se diseña y desarrolla el software, así como cuando se mantiene y la calidad del producto es la mejora que se le hace a todo el proceso y al producto en general.

Es de suma importancia comprender y diferenciar la estrecha relación que existe entre la calidad de los productos de software y los procesos utilizados para construirlos.

El mejoramiento de procesos tiene planteados cuatro objetivos básicos para alcanzar la calidad, y así introducirlos de lleno a la búsqueda de la calidad total.

Dichos objetivos son:

• Comprender el estado actual de la práctica de Ingeniería de software y gestión en una organización • Seleccionar áreas de mejoramiento donde los cambios pueden significar el mayor beneficio a largo plazo. • Enfocarse en agregar un verdadero valor agregado al negocio y no solo quedarse con una simple idea. • Lograr los objetivos mediante una combinación de procesos efectivos, con gente preparada, motivada, comprometida y activa.

2.3.5 Calidad en los productos de software En todas las empresas existen diversos problemas que impiden lograr la calidad total del software. Pero existen formas de detectar estos problemas.

La calidad de software se puede medir y varía de in programa a otro según para las funciones para las que ha sido elaborado.

Al hablar de calidad del producto o calidad total no precisamente quiere decir lograr una calidad perfecta; el concepto de la calidad total, es una alusión a la mejora continua, con el objetivo de lograr la calidad óptima en todas las áreas.

Si bien es cierto que deseamos calidad en todo, tanto en el proceso como en el producto final, se debe trabajar en conjunto para lograr una integridad paulatina.

2.3.6 Aspectos fundamentales de la calidad de Software • Interna: es aquella que es medible a partir de las características intrínsecas del software, como por ejemplo el código fuente, la definición de requerimientos, etc. • Externa: es aquella que es medible en el comportamiento mismo del producto, es decir, ya que fue entregado: puede ser desde una prueba hasta la implementación. (La figura 6 representa las etapas de la calidad externa e interna).

En uso: se da durante la utilización efectiva por parte del usuario, cuando el producto ya está puesto en marcha; es aquí donde entra la etapa de mantenimiento (actualizaciones, mejoras, etc.).

2.3.6.1 Calidad Externa e Interna

Figura 7.- Diagrama de Calidad Externa e Interna Fernández Diaz Raymundo (2014). Procesos y gestión de mantenimiento y calidad. Editorial. Marcombo.

Las etapas de la de calidad externa e interna, así como sus propiedades se detallan como sigue: Funcionalidad: significa asegurar que el producto funciona tal como estaba especificado.

• Adecuación: es la capacidad del producto para generar procesos que funcionen específicamente para los requerimientos detallados por el usuario. • Exactitud: capacidad del producto para proporcionar los resultados o efectos correctos y acordados, con un buen grado de precisión.

• Interoperabilidad: capacidad del software para interactuar con otros sistemas, ya sea con sistemas internos de la empresa o con otro sistema del mercado. • Seguridad de Acceso: capacidad del Software para proteger información y datos de manera que las personas o sistemas no autorizados no puedan leerlos ni modificarlos, así mismo no deniega el acceso a los autorizados. • Cumplimiento funcional: capacidad del software para adherirse a firmas, convenciones y regulaciones en leyes y prescripciones similares relacionadas con la funcionalidad.

Fiabilidad: es la probabilidad de que ese sistema funcione o desarrolle una cierta función, bajo condiciones fijadas y durante un período determinado.

• Madurez: capacidad del producto para evitar fallar. • Tolerancia a fallos: capacidad del software para atender el margen de error o fallos que pudieran seguir durante su operación. • Capacidad de recuperación: restablecer un nivel de prestaciones especificado y recuperar los datos directamente afectados en caso de fallo. • Cumplimiento de fiabilidad: capacidad del producto para adherirse a normas, convenciones o regulaciones relacionadas con la fiabilidad.

Usabilidad: asegurar que las personas saben utilizar las funcionalidades para cumplir sus objetivos.

• Capacidad para ser entendido: característica que permite al usuario entender el software, y poder manejarlo, así como también para que pueda determinar si es adecuado para realizar sus operaciones. • Capacidad para ser aprendido: se refiere a la facilidad con la cual el software es asimilado por el usuario; si es claro y simple de entender. • Capacidad para ser operado: permite al usuario manejarlo y controlarlo. • Capacidad de atracción: capacidad del producto de ser atractivo para el usuario; que posea un ambiente amigable. • Cumplimiento de la usabilidad: capacidad del software para adherirse a normas, guías o regulaciones relacionadas con la usabilidad.

Eficiencia: se refiere a la mejor utilización de los recursos para alcanzar el objetivo.

• Comportamiento temporal: capacidad del producto para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas y en ocasiones bajo mucha presión. • Utilización de recursos: capacidad del software para maximizar el rendimiento de los recursos con los que cuenta.

• Cumplimiento de la eficiencia: capacidad del software para adaptarse a las condiciones y las exigencias de la industria y de los clientes o usuarios.

Mantenibilidad: representa la cantidad de esfuerzo requerida para conservar su funcionamiento normal o para restituirlo una vez se ha presentado un evento de falla.

• Capacidad para ser analizado: capacidad del producto de software para determinar cuáles son las deficiencias o fallas que presenta el mismo durante su operación. • Capacidad para ser cambiado: es la facilidad con la que se le pueden hacer modificaciones al software. • Estabilidad: capacidad del producto para evitar efectos inesperados que puedan afectar su operación y que son resultado de las modificaciones que se le hayan hecho. • Capacidad para ser probado: permite que el software modificado pueda ser validado y probado las veces que resulte necesario. • Cumplimiento de la Mantenibilidad: capacidad del software para poder ser mantenido y corregido durante la operación del mismo sin que se altere en ningún momento.

Portabilidad: característica que posee el software para ejecutarse en diferentes plataformas, el código fuente del software es capaz de reutilizarse en vez de crearse un nuevo código cuando el software pasa de una plataforma a otra:

• Adaptabilidad: capacidad del software para ser amoldado a diferentes entornos diferentes a él, sin que esto cause ningún problema y que funcione igual en alguna otra aplicación, área, rubro, empresa, etc. • Coexistencia: capacidad del software para convivir con otro software independiente, en un entorno común, compartiendo recursos comunes. • Capacidad para reemplazar: capacidad del software para ser usado en lugar de otro producto de software, para el mismo propósito, en el mismo entorno. • Cumplimiento de la portabilidad: capacidad del producto para transferirse o utilizarse en otros ambientes y procesos diferentes. 2.3.6.2 Calidad en uso

En lo que concierne a software, su significado ha evolucionado acompañando a la notable evolución de la industria del software en ese período. El cambio fundamental es la atención cada vez mayor que merecen tanto los usuarios como el contexto considerados, cuando se evalúa el desempeño de un producto software en uso.

La figura 7 presenta las etapas de la calidad en uso:

Figura 8.- Diagrama de Calidad en Uso.

Fernandez Diaz Raymundo (2014). Procesos y gestión de mantenimiento y calidad. Editorial. Marcombo.

1. Efectividad: es la capacidad del producto para entregar y mostrar los resultados fijados desde los objetivos para obtener resultados exactos, precisos y completos. 2. Productividad: es la capacidad del software para permitir a los usuarios consumir una cantidad adecuada de recursos con relación a la efectividad alcanzada, en un contexto de uso específico. 3. Seguridad Física: capacidad del software para alcanzar niveles aceptables en el riesgo de hacer daños a personas, al negocio, al software, a las propiedades o al medio ambiente en un contexto de uso especificado. 4. Satisfacción: capacidad del software para satisfacer a los usuarios, cumpliendo con todos los requerimientos que ellos solicitaron y en la forma que lo esperaban. 2.3.6.3 Gestión de la Calidad

Para alcanzar exitosamente la gestión de calidad del software es necesario clarificar los beneficios que va a proporcionar el hecho de estandarizar y controlar los procesos y formas de trabajo existentes dentro de la organización, ya que es difícil que una organización se adapte a nuevos cambios y procedimientos sin tener la certeza de que los va a beneficiar.

Desarrollar un plan de administración de software no es una tarea fácil, ya que es un factor crítico dentro de la calidad (como se explicó anteriormente), afortunadamente los consultores o evaluadores están haciendo mucho más comprensible este proceso.

Algunos de los factores que afectan la calidad de software son correlación, fiabilidad, eficiencia, integridad, facilidad de uso, flexibilidad, facilidad de pruebas, entre otros.

La Gestión de calidad de software, se refiere en concreto a administrar las actividades que se deben llevar a cabo antes, durante y después de la construcción de un proyecto de software, para así alcanzar el mayor nivel posible de calidad. Esta actividad le corresponde normalmente al área directiva de las empresas, aunque puede existir sólo dentro de un proyecto en específico.

Dentro de esta gestión se determina la calidad por medio de: los objetivos y las responsabilidades del desarrollo de un producto; se apoya también de medios tales como: planificación, control, aseguramiento, mejora, comprobación, validación y certificación de la calidad; así mismo de auditorías e inspecciones de calidad, todo ello con el soporte de modelos y técnicas que más se adapten a la organización y que a la larga (con una buena aplicación) garanticen resultados satisfactorios.

El principal objetivo que persigue la gestión de la calidad es el de garantizar que la organización o un producto sea consistente.

Se centra no solo a la calidad de un producto o servicio, sino que a los medios para obtenerla. Por lo tanto, la gestión de calidad utiliza al aseguramiento de la calidad y el control de los procesos para obtener una calidad más consistente.

Dentro de la gestión de la calidad se observa:

Gestión de la calidad de software (ISO 9000): Conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificación de la calidad, el control de la calidad, el aseguramiento (garantía) de la calidad y la mejora de la calidad, en el marco del sistema de calidad.

Política de calidad (ISO 9000): Conjunto de directrices y objetivos generales de una organización, relativos a la calidad, tal como se expresan formalmente por la alta dirección.

2.3.6.4 Control de la calidad de software

Para asegurar la calidad al usuario, es necesario controlar la calidad en cada una de las etapas de desarrollo, desde el análisis del problema, (pasando por todas las etapas antes mencionadas), hasta el mantenimiento

En términos generales se entiende por Control de Calidad, un conjunto de actividades para evaluar la calidad de los productos desarrollados.

Control de calidad implica vigilar el proceso de desarrollo de software para asegurar que se siguen los procedimientos y los estándares de garantía de calidad, en el proceso de control de calidad se comprueba que las entregas cumplan con los estándares definidos. Consiste en revisar que al final el producto cumpla los requerimientos.

El Sistema de control de calidad de software es la estructura que organiza evaluaciones, inspecciones, auditorias y revisiones que aseguren que se cumplan las responsabilidades asignadas, se utilicen eficientemente los recursos y se logre el cumplimiento de los objetivos del producto. Tiene la intención de mantener bajo control un proceso y eliminar las causas de los defectos en las diferentes fases del ciclo de vida de un producto.

El control de calidad del software abarca todo el proceso de desarrollo: supervisar y mejorar el proceso, asegurar que se siguen los procedimientos acordados, que se alcanza el nivel de calidad deseado y que se localizan y resuelven los problemas.

Al aplicar control de calidad en el desarrollo de un proyecto de software se solucionan problemas:

• En la empresa y usuario en particular • En la calidad en general • En la administración del proyecto del software • En cada una de las fases del ciclo de vida del sistema

Para considerar un software como un producto de alta calidad se deben establecer:

• Normas mínimas a cumplir • Procedimientos en el desarrollo y en el control en cada fase del ciclo de vida del producto • Estructura organizacional del proyecto • Tareas y responsabilidades específicas del personal encargado de realizar las pruebas • Documentación a preparar para revisar la constancia del producto • Técnicas para llevar acabo auditoria y pruebas requeridas • Estándares, normas y especificaciones a usuario • Criterios de aceptación del producto

Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores o criterios de medición.

El software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.

Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, para lo que es necesario definir los siguientes pasos:

• Definir el software que va a ser controlado: clasificación por tipo, campo de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software. • Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. • Crear o determinar métodos de valoración de indicadores tales como: métodos manuales (cuestionarios o encuestas) estándares para la medición de criterios y herramientas automatizadas para medir los criterios de cálculo. • Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.

Indicadores para diferenciar los productos de calidad de los que carecen de ella:

• El acercamiento a cero defectos • El cumplimiento de los requisitos intrínsecos y expresos • La satisfacción del cliente Sobre todo la satisfacción del cliente

La Calidad del Software debe ser una disciplina más dentro de la Ingeniería del software. El principal instrumento para garantizar la calidad de las aplicaciones sigue siendo el Plan de Calidad. El plan se basa en unas normas o estándares genéricos y en unos procedimientos particulares.

Los procedimientos pueden variar en cada organización, pero lo importante es que estén escritos, personalizados, adaptados a los procesos de la organización y, lo que es más importante, que se cumplan. La Calidad del Software debe implementarse a lo largo de todo el ciclo de vida, debe correr paralela desde la planificación del producto hasta la fase de producción del mismo. Para ello se cuenta con una serie de ayudas, a través de distintas actividades para la implantación del control de calidad en el desarrollo de software como son: aplicación de metodología y técnicas de desarrollo, prueba del software, ajustes a los estándares de desarrollo, control de cambios, mediciones y recopilación de información, y gestión de informes sobre el control de calidad

2.4 Pruebas de Software Las pruebas de software son procesos diseñados para hacer que el código computacional sea seguro y que realice las funciones para las que fue creado. Se enfoca primordialmente en evaluar o cuantificar la calidad del producto de software. Otra definición nos dice que las pruebas de software son el proceso de ejecución de un programa con el objetivo de encontrar errores. El propósito de las pruebas de software es encontrar y documentar los errores de un sistema, encontrar las causas de tales errores y corregirlos, validar que el producto de software funcione como fue diseñado y que se hayan implementado apropiadamente los requerimientos del sistema comprenden:

• Encontrar bugs o errores en el software. • Asegurar la calidad del producto. • Validar y verificar la funcionalidad del software. • Examinar el código, así como la ejecución de éste en diversos entornos y condiciones. • Examinar los aspectos del código, es decir, que haga lo que se supone debe hacer.

Sin embargo, las pruebas de software no pueden identificar por completo todos los defectos del software. Por ello es importante tomar en cuenta las siguientes consideraciones acerca de las pruebas de software:

• Las pruebas no determinan que el software funcione correctamente en todas las condiciones. Establecen que no funcione correctamente en condiciones específicas. • Probar todas las combinaciones de entradas y condiciones no es factible.

2.5 Clasificación de las pruebas de software No existe una clasificación general para las pruebas de software; sin embargo, pueden ser aplicadas en diferentes contextos y fases del ciclo de vida, así también se diferencian por la forma en que son ejecutadas o los niveles o capas del software en los que éstas son aplicadas, como requerimientos funcionales y no funcionales. A continuación, se presentan los tipos de Prueba de Software básicos de interés para nuestro estudio. Ejecución manual. No se usan herramientas que automaticen el proceso, tampoco se usan scripts. Generalmente esta forma de realizar pruebas es realizada por los usuarios finales, en donde prueban un conjunto de entradas observando y comparando los resultados. Dado que para realizar una prueba se necesita un usuario y un equipo, representan un alto costo, si se quieren realizar pruebas en donde se necesiten varios usuarios simultáneamente.

Ejecución automática. Para automatizar este proceso se utilizan herramientas y scripts; tiene ciertas ventajas, entre ellas está que se puede conocer el comportamiento de un software simulando un gran número de usuarios simultáneamente en el mismo equipo, se puede utilizar un script de pruebas tantas veces como se necesite, el número de usuarios y equipos para realizar pruebas se reduce en gran medida, por lo tanto, el costo de realizar pruebas también disminuye.

No siempre automatizar pruebas es lo más conveniente, habrá ocasiones en las que es mejor realizar pruebas manuales.

Pruebas de Caja Negra. El software es como una “caja negra”, no se tiene conocimiento de la implementación es desconocido o irrelevante. No se tiene accesos al código de la unidad que se está probando. El mecanismo consiste en proporcionar un conjunto de entradas a la unidad que se está probando, la cual producirá un conjunto de salidas, sin tener conocimiento del cómo se produjeron.

Pruebas de Caja Blanca. Se tiene conocimiento y acceso a la implementación interna del elemento que se está probando, es decir, acceso al código, estructuras de datos internas y algoritmos. En esta técnica se tiene conocimiento detallado de lógica y estructura interna del código fuente. Se utiliza para probar que se cumplan los ciclos y condiciones de programación.

Pruebas de Caja Gris. Es una técnica para probar software con conocimiento limitado del funcionamiento interno de la unidad que se quiere probar, es decir, quien prueba tiene acceso a ciertos documentos, códigos fuente e incluso base de datos. Es una técnica intermedia entre caja negra y caja blanca.

Pruebas funcionales. Se basa en las especificaciones del software que se está probando. Se proporcionan un conjunto de entradas; ya que se tienen los resultados, se analizan para saber si el software satisface la funcionalidad para la que fue creado. En este tipo de pruebas se utiliza la técnica de caja negra. En este nivel se validan todos los requerimientos funcionales. Para este nivel se consideran cinco tipos de pruebas: unitarias, integración, sistema, regresión y aceptación.

Pruebas unitarias. Permiten probar una o varias unidades concretas, llámese unidad a una clase, método, librería, componente, módulo, etc. Este tipo de pruebas son realizadas por los desarrolladores. El objetivo de este tipo de pruebas es aislar cada parte del programa y validar que cada unidad del software es funcionalmente correcta o no.

Pruebas de integración. Permite probar una combinación de unidades en el software para determinar si la funcionalidad o un conjunto es correcta, es decir, ayuda a validar que independientemente de que los componentes funcionen adecuadamente de forma aislada, también cumplan su funcionalidad interactuando con otros componentes. Existen dos métodos para realizar pruebas de integración: bottom-up y top-down. Para el caso de bottom-up se comienza probando los componentes más bajos de una jerarquía y procede con niveles más altos, es decir, el proceso inicia con pruebas unitarias lo siguiente es probar progresivamente combinación de unidades llamados módulos e ir incrementado el tamaño de estos.

El top-down comienza probando el componente de más alto nivel de una jerarquía y procede a través de niveles más bajos, en otras palabras, consiste en probar primero módulos grandes y disminuir progresivamente el tamaño de los módulos hasta llegar a unidades.

• Pruebas de sistema. Una vez que todos los componentes están integrados, la aplicación es probada rigurosamente como un todo. Se basa en probar requerimientos funcionales. Tiene como objetivo revelar errores que no se puedan encontrar en los componentes de forma aislada. • Pruebas de regresión. Cuando se realiza una modificación en una unidad del sistema es probable que este cambio afecte a más de un componente. Este tipo de pruebas ayudan a comprobar que tanto afecta a uno o varios componentes realizar cambios en una unidad específica del software. • Pruebas de aceptación. Este tipo de pruebas son orientadas al cliente y permiten verificar si se cumplen todos los requerimientos funcionales del sistema. Hay dos formas de realizar pruebas de aceptación, realizando pruebas alpha y pruebas beta. Las pruebas alpha son desarrolladas por un cliente usando el software de manera natural y se llevan a cabo en un ambiente controlado. Las pruebas beta son desarrolladas después de las pruebas alpha por un grupo de usuarios finales, también son conocidas como pruebas de pre-lanzamiento.

• Pruebas no funcionales. En este nivel se validan los requerimientos no funcionales. Tales como: rendimiento, seguridad, mantenibilidad, usabilidad, portabilidad, etc. Para este trabajo nos enfocaremos en términos de rendimiento a las pruebas de carga y pruebas de estrés. • Pruebas de carga. Es el proceso de probar el comportamiento del software en condiciones de cargas normales y máximas. Permite medir los tiempos de respuesta, las tasas de producción y los niveles de utilización de los recursos. Ayudan a identificar puntos de ruptura en la aplicación. • Pruebas de estrés. Permite analizar el comportamiento del sistema bajo condiciones anormales de carga, es decir, con este tipo de pruebas se lleva al límite el software. El principal objetivo de realizar este tipo de pruebas es identificar errores que surgen sólo en condiciones carga elevada. Entre otras cosas ayuda a determinar la solidez del sistema con cargas extremas e identificar puntos débiles en la aplicación.

2.6 Aseguramiento de la calidad Al hablar de aseguramiento de la calidad, se habla de garantizar, resguardar y procurar el nivel de satisfacción del usuario respecto a los requerimientos que solicitó. Dando a éste la confianza en que el producto tiene calidad.

Particularmente el aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza adecuada de que el producto software cumplirá estrictamente los requisitos dados de calidad.

El aseguramiento de calidad se enfoca en identificar y evaluar los defectos que puedan afectar al software. Si los errores se pueden identificar de forma temprana en el proceso de software, las características del diseño de software se pueden especificar de modo que eliminarán o controlarán los peligros potenciales, al corregir los errores mucho antes en cada etapa es decir durante el proceso, ahorrando esfuerzos, tiempo y recursos.

El aseguramiento de calidad de software está presente en:

• Métodos y herramientas de análisis, diseño, desarrollo y pruebas • Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software. • Estrategias de prueba • Control de la documentación del software y de los cambios realizados • Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos) • Mecanismos de medida (métricas) • Registro de auditorías y realización de informes Visiblemente lo encontramos también en estas actividades:

• Métricas de software para el control del proyecto • Verificación y validación del software a lo largo del ciclo de vida. • Pruebas y procesos de revisión e inspección.

2.7 Herramientas para pruebas de software En el mercado hay gran cantidad de herramientas que sirven para realizar pruebas de software, cada una ayuda a evaluar diferentes atributos del software. A continuación se presenta un conjunto de herramientas que ayudan a evaluar funcionalidad y rendimiento.

2.7.1 JSystem JSystem es un framework para escribir y correr pruebas automatizadas, está escrito en java y es de código abierto. Su objetivo principal es la automatización de pruebas funcionales y de sistema. El objetivo de JSystem es proporcionar un marco central simple para las pruebas funcionales y de sistemas de software. Una característica única de JSystem es su simplicidad y escalabilidad: la arquitectura de JSystem consta de cuatro capas, con una clara distinción entre la lógica empresarial subyacente de la prueba y la interfaz gráfica del usuario (GUI). El diseño estructural de JSystem ofrece una verdadera escalabilidad al proyecto de prueba: a medida que el producto evoluciona, el usuario puede crear pruebas adicionales basadas en la solución original, sin la necesidad de volver a escribir las pruebas: una marca de un proyecto de prueba verdaderamente sostenible.

Características Principales

• Usa eclipse como entorno de desarrollo. • Es un API comprimido. • Permite realizar reportes, monitoreo y análisis de resultados. • Tiene soporte multi-usuario. • Tiene GUI con JRunner. • Permite crear pruebas con configuración independiente de la instalación del entorno completo. • Admite el ciclo de vida completo de pruebas. • Permite construir escenarios de prueba complejos. • Se centra en probar la lógica del negocio. • Permite a todos los perfiles de usuario tener la capacidad de interactuar fácilmente entre sí. • Está construido sobre una base de código extensible. • Divide el proyecto de pruebas en capas para cada perfil. • Integración con JUnit. • Incluye un servidor de informes central, basado en Spring. • Tiene la capacidad de efectuar la misma prueba en diferentes configuraciones.

2.7.2 HP LoadRunner HP LoadRunner es un framework desarrollado por HP que permite desarrollar, entre otras, cosas pruebas de carga y de estrés. Permite probar el rendimiento de diversos tipos de aplicaciones e identificar y resolver problemas antes de que las aplicaciones se pongan en marcha.

LoadRunner simula la actividad del usuario generando mensajes entre los componentes de la aplicación o simulando interacciones con la interfaz del usuario, como las pulsaciones de teclas o los movimientos del mouse. Los mensajes e interacciones que se generarán se almacenan en scripts. LoadRunner puede generar los scripts grabándolos, como registros de solicitudes HTTP entre un navegador web del cliente y el servidor web de una aplicación.

Características Principales

• Admite pruebas de rendimiento en diferentes tecnologías. • Integración con J2EE, Visual Studio, .NET. • Respalda pruebas de rendimiento. • Permite probar aplicaciones en dispositivos móviles y aplicaciones web. • Ayuda a reducir costos de hardware y software al predecir la capacidad de la aplicación. • Detecta cuellos de botella. • Disminuye ciclos de pruebas. • Reduce las necesidades de personal sustituyendo a usuarios humanos por usuarios virtuales. • Proporciona capacidades para configurar y simplificar la introducción de la información. • Permite vigilar los recursos de la red y el servidor. 2.7.3 WebLOAD WebLOAD es un framework desarrollado por Radview que permite realizar pruebas de carga y estrés a través de cuatro fases para el desarrollo de pruebas de este tipo. Dichas fases son: creación de la prueba, ejecución de la prueba, monitoreo y análisis.

La herramienta de carga WebLOAD combina rendimiento, escalabilidad e integridad como un proceso único para la verificación de aplicaciones web y móviles.

Puede simular cientos de miles de usuarios concurrentes haciendo posible probar grandes cargas y reportar cuellos de botella, restricciones y puntos débiles dentro de una aplicación.

Utilizando su soporte multiprotocolo, simula el tráfico de cientos de miles de usuarios y proporciona datos de análisis sobre cómo se comporta la aplicación bajo carga. WebLOAD supervisa e incorpora estadísticas de los diversos componentes del sistema bajo prueba: servidores, servidor de aplicaciones, base de datos, red, equilibrador de carga, firewall, etc., y también puede supervisar el

44 cumplimiento de la experiencia del usuario final y el acuerdo de nivel de servicio (SLA) en entornos de producción.

Características Principales

• Solución robusta para la creación y ejecución de pruebas. • Incluye registro y repetición del trafico HTTP(S) sin la necesidad de configurar un navegador. • Soporta una gran cantidad de protocolos, algunos de ellos son: FTP, POP3, SMTP, TCP, UDP, SSH, etc. • Permite crear y editar scripts usando JavaScript. • Permite desarrollar pruebas de rendimiento a aplicaciones que usan tecnologías basadas en Java. • Permite monitorear y analizar aplicaciones J2EE. • Compatibilidad con diferentes servidores: JOnAS, Tomcat, Glassfish, JBoss, etc. • Integración con: .NET, Java J2EE, Oracle Form, Web Services, RESTFull, ERP y CRM. • Permite realizar pruebas de rendimiento en dispositivos móviles. • Permite simular condiciones de carga reales y variadas. • Número ilimitado de usuarios. 2.7.4 NeoLOAD NeoLOAD es un framework que proporciona una manera para desarrollar pruebas de rendimiento para aplicaciones web y aplicaciones móviles. Proporciona soluciones pragmáticas a los desarrolladores para ayudarles al rendimiento antes de que la aplicación entre a producción. Básicamente se encarga de simular que una cierta cantidad de usuarios virtuales recorran nuestra aplicación (trabajen sobre ella) y de monitorear el comportamiento del servidor en el cual se encuentra alojada. En base a este comportamiento NeoLOAD se encarga de tomar los tiempos de respuesta de cada http response. Características Principales • Generación de carga localmente con la infraestructura propia, también permite carga con la infraestructura de la nube. • Permite probar todo tipo de aplicaciones web y móviles. • Ayuda al monitoreo de los servidores. • Se pueden desarrollar pruebas con y sin scripts. • Usa JavaScript para crear scripts de prueba. • Cuenta con herramientas para analizar la conducta del sistema durante la prueba. • Permite definir reglas para la extracción de datos. • Simula el acceso de múltiples usuarios con diferentes navegadores. • Permite agregar y eliminar usuarios en tiempo de ejecución de la prueba.

• Permite filtrar los resultados obtenidos utilizando múltiples criterios. • Determina el número máximo de usuarios soportados por la aplicación. • Registra el tráfico HTTP entre el navegador y el servidor. • La forma de producir reportes es a través de Jenkins. 2.6.5 Selenium Selenium es un conjunto de diferentes herramientas de software las cuales permiten, entre otras cosas, automatizar pruebas de software, soporta la ejecución de pruebas en diferentes navegadores. Selenium IDE es un plugin de firefox que permite realizar pruebas automáticas, permite crear scripts en lenguaje Java Script. Posee la característica de registrar las acciones realizadas por un usuario para que estas se puedan volver a usar, sin importar el lenguaje de programación de la aplicación. Selenium Grid permite correr pruebas en paralelo en varios lenguajes como Java, C#, Perl, Python y Ruby.

Selenium provee una herramienta de grabar/reproducir para crear pruebas sin usar un lenguaje de scripting para pruebas.

Selenium incluye también un lenguaje específico de dominio para pruebas para escribir pruebas en una amplia variedad de lenguajes de programación, incluidos Java, C#, Ruby, Groovy, Perl, Php y Python. Las pruebas creadas pueden ejecutarse entonces usando la mayoría de los navegadores web modernos en diferentes sistemas operativos como Windows, Linux y OS X.

Otra de las herramientas es Remote Control, encargada de ejecutar los test en diferentes navegadores y en diferentes plataformas. Remote Control está formado por un servidor escrito en Java, encargado de abrir y cerrar el navegador, y actuar a modo de proxy para las peticiones web que vayamos lanzando, y un conjunto de librerías para el lenguaje de programación que elijamos. Con la liberación de Selenium 2, en Julio de 2011, Selenium RC fue oficialmente descartado en favor de Selenium WebDriver.

WebDriver es el sucesor de Remote Control. WebDriver acepta comandos (enviados en Selenese o vía el API de cliente) y los envía a un navegador. Esto se implementa a través de un controlador del navegador específico para cada navegador que envía los comandos y trae los resultados de regreso. Diferencia de Selenium 1, donde el servidor Selenium RC era indispensable, en Selenium WebDriver no se requiere de un servidor especial para ejecutar las pruebas, en vez de ello WebDriver inicia una instancia del navegador y lo controla.

Otra parte importante es Selenium Grid, que permite coordinar múltiples servidores para así poder ejecutar scripts en múltiples plataformas y equipos al mismo tiempo. Grid permite ejecutar pruebas en paralelo en múltiples máquinas y manejar diferentes versiones y configuraciones de manera centralizada.

2.6.7 JMeter. Apache JMeter es una aplicación de escritorio de código abierto, desarrollado en el lenguaje Java y diseñado para probar funcionalidad y rendimiento. Se puede usar para simular cargas pesadas en el servidor, red o un objeto para probar su resistencia o para analizar el rendimiento general bajo diferentes tipos de carga.

JMeter puede ser usado como una herramienta de pruebas unitarias para conexiones de bases de datos con JDBC, FTP, LDAP, Servicios web, JMS, HTTP y conexiones TCP genéricas. JMeter puede también ser configurado como un monitor, aunque es comúnmente considerado una solución ad-hoc respecto de soluciones avanzadas de monitoreo.

A veces se clasifica JMeter como herramienta de "generación de carga", pero esto no es una descripción completa de la herramienta. JMeter soporta aserciones para asegurar que los datos recibidos son correctos, por lo que es una herramienta de realización de pruebas automáticas.

Características Principales.

• Se pueden probar diferentes tipos deservidores y protocolos: HTTP(S), SOAP, • JDBC, TCP, POP3, SMTP, comandos nativos o shellscript. • Permite hacer un análisis gráfico del rendimiento de la aplicación. • Portabilidad por estar creado totalmente en Java. • Completamente multi-hilo. • Interfaz GUI diseñada cuidadosamente, lo que permite la construcción de pruebas y depuración más rápido. • Almacenamiento de resultados de las pruebas en caché fuera de línea. • Altamente extensible. • Permite registrar scripts de prueba. • Permite hacer pruebas distribuidas. • Permite acceder al log. • Permite generar reportes. • Integración con JUnit. • Permite el monitoreo de la red. • Permite crear y utilizar usuarios virtuales. 2.6.8 JUnit.

Es un conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son utilizadas en programación para hacer pruebas unitarias de aplicaciones Java.

JUnit es un conjunto de clases (framework) que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor de

47 retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el método correspondiente.

JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando una parte del código ha sido modificado y se desea ver que el nuevo código cumple con los requerimientos anteriores y que no se ha alterado su funcionalidad después de la nueva modificación.

2.8 Estudio comparativo En la tabla se muestra un total de siete herramientas que ayudan a probar pruebas a nivel de no funcionales. En esta tabla se hace referencia a un conjunto de características de interés para la metodología, estas características nos ayudarán a elegir que herramienta se recomienda para el uso de la metodología.

La mayoría de las herramientas cumple con casi todas las características marcadas, no se pretende que en la aplicación de la metodología se use una herramienta en específico. Sin embargo hemos decido proponer un conjunto de herramientas que nos ayudarán a medir la funcionalidad y rendimiento de un software.

✔

WebLoad

✔

Neo Load Neo

✔

HPLoad Runner

✔

Selenium

✔

Jsystem

softwarey sus

✔

Jmeter

Figura TablaFigura 8. comparativa de herramientasde pruebas de características Sanz Esteban Ana (2012). Un proceso de pruebas eficiente. Editorial. EAE Editorial Academia Española

Mediciónde consumo de memoria del servidor

Compatibilidadcon diferentes navegadores

Compatibilidadcon diferentes servidores

Detectarcuellos de botella

Creaciónde informes

Multiplataforma

Compatibilidadcon diferentes protocolos de comunicación

Pruebasen dispositivos móviles

Integracióncon diferentes lenguajes de programación

Monitoreatráfico el de la red

Determinanúmero el máximo mínimo y de usuarios concurrentes

Creaciónde usuarios virtuales

Mediciónde peticiones por unidad de tiempo

Monitoreode base de datos

Documentación

Gratuita

Integracióncon otras herramientas

Creaciónde escenarios

Grabareproduce y guiones de prueba

Permite crear Permite scripts de prueba

Pruebasdistribuidas

Pruebasde estrés Pruebasde carga . 49

CAPITULO III SITUACIÓN ACTUAL DE LAS METODOLOGIAS EN LAS EMPRESAS

3.1 Conceptos de Testing Cem Kaner. Es una investigación técnica realizada para proveer información a los stakeholders sobre la calidad del producto o servicio bajo pruebas. Según Glenford Myers, software testing es un proceso diseñado para asegurar que el código hace lo que se supone que debe hacer y no hace lo que se supone que no debe. Según el autor, se trata de un proceso en el que se ejecuta un programa con el objetivo de encontrar errores. Lo más importante: aportar calidad al software que se está verificando. ¿Cómo? Detectando posibles incidencias de diversa índole que pueda tener cuando esté en uso. Cem Kaner

Gustavo Terrera. El testing es una actividad desarrollada para evaluar la calidad del producto, y para mejorarlo al identificar defectos y problemas. El testing de software consiste en la verificación dinámica del comportamiento de un programa sobre un conjunto finito de casos de prueba, apropiadamente seleccionados a partir del dominio de ejecución que usualmente es infinito, en relación con el comportamiento esperado.

3.1.1 Conceptos Relacionados en la Aplicación de un Proceso de Testing • Pruebas de aceptación del usuario (User Acceptance Testing)

Una evaluación formal del producto realizada por un cliente, como condición de la compra. Normalmente este tipo de pruebas se hace para verificar si el sistema cumple con los requisitos especificados por el cliente.

• Validación (Validation)

El proceso de evaluación de software al final del proceso de desarrollo de software para garantizar el cumplimiento de los requisitos de software. Las técnicas para la validación son pruebas, inspección y revisión.

• Verificación (Verification)

El proceso de determinar si los productos de una determinada fase del ciclo de desarrollo de software cumplen con los pasos de implementación y se los puede relacionar a los objetivos entrantes establecidos durante la fase anterior. Las técnicas para la verificación son pruebas, inspección y revisión.

• Pruebas de integración incremental (Incremental integration testing)

Enfoque de prueba tipo abajo arriba. Ej. Prueba continua de una aplicación a medida que se añade una nueva funcionalidad

50 • Prueba de recuperación (Recovery testing)

Prueba de lo bien que un sistema se recupera de accidentes, fallos de hardware, u otros problemas catastróficos. Relacionados con el concepto de sistema

• La prueba de compatibilidad (Compatibility testing)

Prueba el buen funcionamiento del software en un / entorno de red particular / sistema de hardware / software / operativo y combinación diferente.

• Prueba de comparación (Comparison testing)

Comparación de las fortalezas y debilidades de productos con versiones anteriores u otros productos similares.

• Pruebas alfa (Alpha testing

La prueba se realiza al final del desarrollo.

• Las pruebas beta (Beta testing)

Prueba que realiza normalmente el usuario final u otros. Son pruebas finales antes de lanzar la aplicación para fines comerciales.

Las pruebas de software (testing) son el proceso usado para identificar que los aplicativos hacen lo que tienen que hacer, y/o para determinar posibles fallos de implementación. Básicamente es una fase en el desarrollo de software que consiste en probar las aplicaciones construidas.

Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado.

Hoy en día es fundamental evaluar la calidad de lo construido de modo de minimizar el costo de su reparación. Mientras más pronto se detecte una falla, más barata es su corrección.

Las diferentes pruebas de software que se realizan durante todas las fases del ciclo de vida de un software específico, garantizan la entrega de una aplicación que aumenta la satisfacción de usuarios y clientes. En nuestro país es una de las aéreas con mayor crecimiento en el rubro tecnológico y cada vez más empresas reconocen su importancia.

3.1.2 Aplicación de un Proceso de Testing Como de describió en el punto anterior, en un proceso testing se ejecutan pruebas con el fin de poder detectar errores y asegurar la calidad y funcionamiento correcto del software, la aplicación del mismo requiere distintas fases en las cuales se va trabajando paulatinamente, con el fin de tener el control de todo el Proceso.

51 Un proceso Testing es aquel en el que se revisa el sistema a probar (el SUT) bajo condiciones definidas explícitamente, y se le aplica (eventualmente con apoyo de software especializado de tipo CAST) un conjunto de estímulos (los casos de prueba) diseñados de manera sistemática utilizando técnicas apropiadas, con el objetivo de detectar niveles inadecuados de calidad. Este proceso debe llevarse a cabo disciplinadamente, y respaldarse en métricas bien definidas. Todas estas actividades y sus resultados son documentados, en especial las fallas detectadas.

Precisemos cada uno de los conceptos de esta definición. Intuitivamente, un proceso puede verse como una secuencia de actividades, cada una de las cuales genera productos, tiene insumos asociados, e involucra gente (roles) y otros recursos (hardware y software).

Un primer bosquejo del proceso de prueba de caja negra sería el siguiente, que refinaremos en números subsiguientes:

1. Establecer alcances, entregables y criterios de éxito 2. Estimar el esfuerzo de prueba 3. Planear el proyecto 4. Reproducir el contexto del SUT 5. Hacer a. Diseñar casos de prueba b. Aplicar casos de prueba c. Reportar métricas y dar seguimiento) Reportar análisis de resultados d. Mientras no (criterio de terminación)a) Hacer el cierre del proyecto

El SUT (System Under Testing) se refiere en general al elemento a probar. Por otro lado, las herramientas que utiliza el tester para llevar a cabo las actividades anteriores son cobijadas bajo el acrónimo CAST (Computer Aided Software Testing).

En cuanto a los casos de prueba, es deseable que presenten las siguientes características:

• Ortogonalidad. No tener casos que incluyan segmentos de otros • Efectividad. Que detecten fallas. • Ejemplaridad. Que “con poco se pruebe mucho”. • Claridad. Que evidencien fallas de manera clara. • Con calidad nos referimos a: el grado en que el producto satisface los requerimientos funcionales y no-funcionales explícitamente establecidos; el nivel al que se siguieron los estándares de desarrollo explícito y documentado; que el producto muestre las características implícitas que se espera de todo software desarrollado profesionalmente.

52 Una equivocación es una acción incorrecta cometida por un humano, que ocasiona que se genere una falta al ser ejecutada, la falta se evidencia en forma de lo que llamamos una falla. El error es la magnitud de la diferencia entre el resultado esperado y el obtenido.

3.1.3 Perfil del Tester Para poder ejecutar un Proceso de pruebas de testing, es de vital importancia contar con el personal calificado, y que cuente con el know how y la experiencia para llevar a cabo dicha actividad, por ser pruebas muy técnicas el conocimiento que tenga el Individuo Juega un papel fundamental en la aplicación del Proceso.

Si bien sabemos que un “probador de software” deberá de ser: curioso, perceptivo, inquisitivo, crítico, analítico, persistente, buen comunicador y negociador, estas características y habilidades son parte del perfil de un buen ingeniero, pero son en su mayoría implícitas a la profesión y difíciles de medir de forma concreta. Es por eso que se requiere de una formación estructurada y especializada que pueda ser validada para garantizar los conocimientos básicos y la experiencia.

Al día de hoy, la mayoría de los ingenieros de pruebas han aprendido a desarrollar su profesión de forma empírica. Si bien algunos cuentan con mayor o menor formación formal en términos de sistemas de software y una carrera universitaria afín al área de TI, pocos han sido los que han tenido entrenamiento formal y han logrado acreditar certificaciones en la disciplina. Esta disciplina ha tomado una gran relevancia en las últimas 3 décadas y al día de hoy ya se considera una profesión madura que cuenta con diferentes ofertas para validar los conocimientos de sus practicantes. A continuación describiremos las principales certificaciones disponibles y comentaremos sus principales diferencias y puntos clave.

Algunas cualidades personales que un tester debería poder reunir la mayoría son: crítico, analítico, creativo y pragmático, conciso, buen comunicador, sentido común, organizado, explícito, metódico, asertivo, atento, claro, curioso, comprometido, desconfiado, investigador interno, cauto, tener confianza en sí mismo, detallista, pasión por el producto, deductivo, compatibilidad con el grupo, certero, rápida adaptación al área y a los cambios, ordenado, ético.

En el aspecto técnico: conocimiento en herramientas, comprender fallas de arquitectura, conocimiento en plataformas, capacidad para detectar errores, conocimiento en lenguajes de programación, gestionar la configuración, ingeniería de software, capacidad de medir, probar de manera creativa.

3.1.3.1 Perfil profesional del Tester Un probador de software necesita el desarrollo de las siguientes actividades ya que el campo laboral donde estar inmerso lo demanda.

• Importantes habilidades de TIC.

53 • La capacidad de trabajar con calma bajo presión. • Capacidad de organización. • Pensamiento lógico. • Capacidad de planificar el trabajo futuro. • Prestar atención a los detalles. • Ser capaz de redactar informes claros. • Habilidades de comunicación oral. • Habilidades de trabajo en equipo.

3.1.4 Habilidades que debe tener un buen Tester Para poder ejecutar un Proceso de Testing con la certeza de obtener un resultado Positivo, es importante que el Tester cuente con las siguientes habilidades:

• Acuerda de antemano cuánto hay que testear en el tiempo disponible. • Aptitudes para la comunicación verbal y escrita. • Aptitudes para la planificación. • Aptitudes para redactar informes. • Bien organizado. • Capacidad de análisis. • Capacidad para priorizar tareas. • Capacidad para trabajar en equipo. • Capaz de prestar atención al detalle. • Capaz de trabajar bajo presión. • Conocimientos especializados en informática. • Destrezas en informática. • Elabora y realiza tests sobre programas informáticos, páginas web y juegos. • Habilidad para evaluar. • Habilidad para resolver problemas. • Idea tests que puedan repetirse y valorarse. • Identifica riesgos. • Lista errores y redacta informes para programadores y directores de proyectos para que actúen según los mismos. • Lleva registros precisos de lo que se ha testado. • Metódico. • Observador. • Recomienda formas de mejorar la realización de tests.

54 • Resuelve cómo probar riesgos a fin de que el software resulte lo más seguro posible. • Sensato. • Sentido común. • Trabaja en equipo. • Tranquilo. • Habilidades y su comportamiento en el campo laboral • Capacidad de abstracción y modelado para entender y simular el comportamiento del sistema bajo prueba • Facilidad de comunicación oral y escrita para interactuar con desarrolladores y usuarios. • Creatividad para generar ideas e imaginar los problemas que podrían existir • Pensamiento crítico para evaluar las ideas, hacer deducciones y vincular lo observado con los criterios de calidad de la empresa • Pragmatismo para poner en práctica las ideas y adecuar las técnicas y el esfuerzo al alcance del proyecto • Aptitudes para el trabajo en equipo, de manera de poder interactuar con los desarrolladores y otros testers, y lograr el máximo beneficio en esta interacción • Acuerda de antemano cuánto hay que probar en el tiempo disponible • Aptitudes para la comunicación verbal y escrita • Aptitudes para la planificación • Aptitudes para redactar informes • Bien organizado • Capacidad de análisis • Capacidad para priorizar tareas • Capacidad para trabajar en equipo • Capaz de prestar atención al detalle • Capaz de trabajar bajo presión

El papel de tester consiste en eliminar los problemas propios de dejar que el constructor pruebe lo que el mismo ha construido.

La prueba independiente elimina el conflicto de intereses, que de otra manera, estaría presente. Después de todo, al personal de testeo se le paga para que encuentre errores. Sin embargo, el desarrollador de software no debe simplemente entregar el programa al tester y alejarse. Estos dos deben trabajar unidos en todo el proyecto de software para asegurar la realización de pruebas

55 exhaustivas. Mientras estas se realicen, el desarrollador debe estar disponible para corregir los errores que se descubran.

El tester es parte del equipo del proyecto de desarrollo del software, ya que participa en el análisis y diseño y además sigue participando (al planear y especificar procedimientos de prueba) en todos los pasos de un proyecto grande. Sin embargo, en muchos casos el tester informa a la organización de aseguramiento de calidad del software, por lo que obtiene un grado de independencia que sería imposible si fuera parte de la organización encargada de la ingeniería del software.

3.1.5 Actividades que ejecuta un Tester Los probadores de software pueden probar todo tipo de software, programas individuales para aplicaciones o productos (una serie de programas que almacenan y procesan información para realizar una tarea específica). Las aplicaciones incluyen pantallas para que los usuarios introduzcan información y puedan imprimir los resultados. Los probadores también pueden analizar sitios web o juegos de ordenador.

Pueden estar involucrados con el desarrollo de un nuevo programa, ya que a menudo deben probar nuevas versiones de un software, o simplemente llevar a cabo un control rutinario de un producto existente.

En primer lugar, identifican todos los riesgos tales como: errores que podrían ocurrir en el software cuando alguien lo está usando, confusiones a la hora de utilizar un software por parte de un usuario debido a la falta de información, la instalación del software en diferentes tipos de sistemas, etc. Prueban estos riesgos para conseguir que un software ofrezca la máxima confianza. Deben diseñar pruebas que se puedan repetir y evaluar.

Pueden evaluar el correcto funcionamiento:

• Si el software coincide con la especificación original (o qué hay que hacer para que coincida). • Si cuando un usuario hace clic en un botón o enlace para que suceda algo, por ejemplo, para ir a una nueva pantalla, se abre la pantalla correcta. • Si el usuario tiene que introducir algunos datos, el software actúa de forma correcta y los datos se almacenan de forma segura. • Si está diseñado para que varios usuarios puedan abrirlo al mismo tiempo sin que el programa reduzca su velocidad de procesamiento. • Si se puede utilizar herramientas de automatización de pruebas para iniciar una sesión en muchos usuarios al mismo tiempo. • Si cuando el Software tiene que compartir información

56 Los probadores de software, por ejemplo, pueden introducir deliberadamente información en una ruta equivocada para asegurarse de que reciben el mensaje de error esperado. Por ejemplo, si se les pide que introduzcan un año de nacimiento, podrían poner 1892 en lugar de 1992 y comprobar que el programa reacciona de la forma adecuada y detecta el error.

Los probadores de software no suelen tener tiempo para probar todas las combinaciones posibles de las acciones que pueden aplicarse con un software, por lo que tienen que ponerse de acuerdo de antemano con el cliente sobre el tiempo disponible que tendrán. Mantienen un registro detallado las pruebas que realizan. Una vez completadas las pruebas, enumeran los errores y redactan un informe para que los programadores y administradores de proyectos puedan implementar posteriormente.

Algunos probadores trabajan como consultores, y deben viajar a los hogares/locales de los clientes para asesorarles sobre los procedimientos de prueba, así como la realización de las pruebas.

3.1.6 Tipos de Testers según su Expertiz (Clasificación) Durante las últimas semanas le he estado dando “vuelta al coco” sobre el tema de cómo diferenciar un buen profesional de otro, según su nivel de experiencia o “seniority“. Y decirte quiero, que no es un tema muy sencillo. Incluso en las búsquedas que he realizado en la red, no he encontrado alguna respuesta que pueda catalogar como excelente a esta interrogante. Una de las conclusiones a las cuales he llegado, es que las diferencias entre los diferentes tipos o niveles de “seniority“, depende de las necesidades y cultura de cada organización o equipo de trabajo en sí. Los criterios que se pueden aplicar para diferenciar a un profesional Junior de un Semi Senior o un Senior, pueden variar dependiendo de cada entorno. Algunas empresas o reclutadores toman como criterio diferencial, la cantidad de años de experiencia laboral del profesional, otros se basan en el grado de conocimientos técnicos o en la capacidad de la persona para auto gestionarse su trabajo, ya sea individual o en equipo. Lo que no cabe duda es que es una temática sumamente muy sensible. Y trasladándola al ecosistema freelancing, habitualmente muchos clientes tienen en cuenta el criterio experiencia profesional, para definir el precio que estarían dispuestos a pagar por los servicios del profesional freelance.

En este apartado se muestran algunos de los criterios que se podrían tener en cuenta a la hora de definir el nivel de seniority de un profesional. Cada uno de estos indicadores y en dependencia de tu propia valoración, necesidades y estructura organizativa, podrá tener mayor o menor importancia.

Si eres un Cliente y estás en búsqueda de talento freelance, te diría que aplicaras una ponderación (asignar un valor de importancia) a cada uno de los indicadores antes de aplicarlos en tus procesos selectivos.

Si en cambio eres un profesional freelance, te sugiero que te apuntes y te marques como objetivo dominar cada uno de los aspectos que mencionaré.

57 Y por el contrario, si eres un experto en procesos de selección y reclutamiento, o RRHH, te pediría que colaboraras en el debate, dejando tu opinión o sugerencias como experto en la temática:

1. Experiencia laboral.

Cantidad de años de experiencia laboral del profesional.

No cuentan los trabajos prácticos realizados durante su etapa como estudiante. Tampoco suma si la persona trabajó 2 años atendiendo una agencia de viajes o en otras tareas no relacionadas con su actividad profesional.

• Junior: Menos de 2 años de experiencia. • Semi Senior: De 2 a 6 años de experiencia • . Senior: Más de 6 años de experiencia. 2. Conocimientos Técnicos.

Principalmente me estoy refiriendo a las herramientas, tecnologías, metodologías de trabajo que deba utilizar para cumplir sus labores.

• Junior: Para desempeñarse suele requerir acompañamiento. Probablemente no maneja todas las herramientas que se necesitan para el cumplimiento de las tareas. • Semi Senior: Técnicamente autosuficiente. Puede desarrollar funcionalidades más complejas y ejecutar proyectos de mayor envergadura. Pero no es un crack y todavía comete errores “evitables”. • Senior: Es un “referente técnico” dentro del equipo. Sus conocimientos le permite trabajar o colaborar en proyectos más desafiantes. 3. Conocimientos funcionales.

Relacionado a los procesos, técnicas, metodologías o estándares requeridos para cumplir con su faena.

Junior: Para desempeñarse suele requerir cierto nivel de acompañamiento. No conoce todos los procesos, ni los estándares que se deben aplicar en el desarrollo del proyecto. No es experto en los temas propios del negocio.

Semi Senior: Maneja “los circuitos” lo suficiente como para desempeñarse de forma autónomo. Respeta los estándares y metodologías. Conoce buena parte de los procesos del negocio.

Senior: Ayuda a definir procesos, metodologías y estándares que tendrán lugar en el desarrollo del proyecto. Y por supuesto, cumple con los mismos.

4. Proactividad.

58 Indica si el profesional espera a que le asignen sus tareas o si por el contrario, toma una actitud de mayor iniciativa.

• Junior: Necesita que frecuentemente le definan su trabajo. Está a la espera del siguiente pedido. Cuando tiene tiempo libre no sabe con qué seguir. Depende de otros para avanzar con sus tareas. • Semi Senior: Se preocupa por aprovechar mejor su tiempo. Pide nuevas asignaciones cuando tiene tiempo disponible y es autosuficiente para llevar adelante una gran parte de sus tareas. • Senior: No solamente recibe requerimientos, sino que los busca y genera. En muchas oportunidades es él quien aporta nuevas y novedosas iniciativas a sus clientes. 5. Seguimiento requerido.

Atención que requiere de su cliente.

• Junior: Requiere seguimiento diario a nivel detallado. • Semi Senior: Requiere seguimiento semanal y a nivel general. • Senior: Proactivamente reporta el estado y avance de sus tareas y/o proyecto en él se encuentra trabajando. 6. Indicadores de Productividad, Calidad y Eficiencia.

Indicadores varios relacionados con el trabajo que realiza.

• Junior: Calidad: Baja/Media – Productividad: Baja/Media – Innovación: Poca o Nula • Semi Senior: Calidad: Media – Productividad: Media – Innovación: Poca • Senior: Calidad: Alta – Productividad: Alta – Innovación: Alta 7. Cumplimiento de fechas.

Cumplimiento de las fechas de entrega pautadas. Se puede aplicar a las tareas previas de análisis de requerimientos o funcionalidades, desarrollos, documentación del proyecto, reporting, etc.

• Junior: La mayoría de las veces no cumple con sus estimaciones. • Semi Senior: A veces cumple, a veces no. • Senior: Siempre cumple. Cuando surge un desvío (inevitablemente) lo informa adecuadamente y con anticipación. 8. Respuestas bajo Presión.

Este punto se refiere a situaciones extremas… no a una “maratón semana” para cumplir con la fecha de entrega del siguiente “release”.

• Junior: Le pueden pasar alguna de las siguientes cosas

59 o : • Se bloquea. o •Se angustia. o •Se confunde. o •Se estresa.

Su resultado final de su trabajo en una situación de presión no es bueno.

• Semi Senior: Le pueden suceder algunas de las siguientes cosas: o Se enoja. o •Se defiende. o •Se distancia. o •Se resigna.

El resultado final de su trabajo en una situación de presión a pesas de todo es bueno.

• Senior: Le pueden suceder algunas de las siguientes cosas: o Se entusiasma. o Se compromete. o Se hace cargo de la situación o Se inspira o Se auto supera pese a las dificultades.

El resultado final de su trabajo en una situación de presión es excelente.

Relaciones interpersonales con su cliente y demás miembros del equipo de trabajo.

Más allá de los conocimientos y capacidades profesionales, la habilidad de comunicarse con su entorno es fundamental para su desarrollo profesional y el trabajo en equipo.

• Junior: Puede tener dificultades para transmitir sus ideas con claridad. No logra arribar a conclusiones concretas. No siempre sabe interactuar con otras personas de forma colaborativa y profesional. • Semi Senior: Se hace entender pero no logra ganarse la simpatía ni despierta la vocación de sus colaboradores para acompañarlo en sus sugerencias. “Escucha” otros puntos de vista, pero sigue intentando que sean sus ideas (buenas y malas) las que Senior prevalecen. • Senior: Es bueno comunicando, pero principalmente escuchando. Puede participar en decisiones de alto nivel y colaborar si es necesario en actividades más operativas privilegiando el resultado y la calidad de las relaciones por sobre su autoría en las ideas.

60 Vale la pena mencionar que la misma persona puede tener características de Senior en un aspecto y de Junior en otro, la decisión final radica en tener un plan de selección bien claro para cada perfil freelance que necesites en tu proyecto.

3.1.7 Principales certificaciones y organizaciones certificadoras Para asegurar que el Tester cubre el perfil correspondiente y cuenta en realidad con las competencias que el mercado le demanda, al mismo tiempo que, se mantiene en constante actualización con las ultimas practicas del Mercado, es de vital importancia contar con ciertas certificaciones las cuales lo acrediten y avalen como un verdadero Tester.

La siguiente información muestra algunas de las principales certificaciones que demanda el Mercado

El International Software Testing Qualifications Board es una organización basada en Alemania pero con representación en distintas regiones del mundo. En el caso de América está el ASTQB (American Software Testing Qualifications Board) para Estados Unidos, CSTB (Canadian Software Testing Board) para Canada y HASTQB (Hispanic America Software Testing Qualifications Board) para países de habla hispana. Estos son los niveles y opciones de especialización para las certificaciones que ofrece ISTQB:

• Nivel de fundamentos (Foundation). • Nivel avanzado (Advanced) con 3 opciones de especialización: Test Manager, Test Analyst, Technical Test Analyst. • Nivel experto con 4 opciones de especialización: Improving Test Process, Test Management, Test Automation, Security Testing.

Asimismo, el IIST (International Institute for Software Testing) de Estados Unidos ofrece los programas:

• Certified Software Test Professional (Associate, Practitioner, Master Levels). • Certified Agile Software Test Professional. • Certified Test Manager. • Certified Software Quality Manager. • Certified Software Test Automation Specialist.

La American Society for Quality (ASQ) es un organismo bastante importante en Estados Unidos, que ofrece programas de formación y certificación para roles de gestión de calidad en distintos dominios. En el caso específico del software, ofrece el programa CSQE (Certified Software Quality Engineer).

También tenemos al iSQI (International Software Quality Institute) en Alemania, que destaca por un lado por ofrecer un programa de certificación para testing ágil y por otro por ofrecer un programa específico para el modelo V. Estos son sus programas: 61 • CAT Certified Agile Tester (Foundation Level y Advanced Level) • QAMP Quality Assurance Management Professional • TTCN-3 Testing and Test Control Notation • Certified V-Model XT Project and QA Manager

El British Computer Society / Information Systems Examinations Board (BCS/ISEB) en el Reino Unido ofrece los siguientes programas de certificación:

• Foundation, Advanced, Expert (en alianza con ISTQB) • Intermediate Certificate in Software Testing. Este certificado se considera como un nivel intermedio entre los niveles Foundation y Advanced del ISQTB. • Certified Agile Tester (en alianza ISQI)

Por último, el Instituto de Examinación para Ciencias Informáticas en Holanda ofrece programas de certificación orientados a la metodología TMap (Test Management Approach):

• TMAP NEXT Test Engineer • TMAP NEXT Test Manager

En general podemos observar que la mayoría de las ofertas de pruebas se orientan a un nivel básico y permiten la especialización como administradores o líderes de pruebas. Son pocas las organizaciones que validan diferentes niveles de dominio de la disciplina (niveles intermedios, avanzados o expertos) y sólo un par ofrecen certificaciones relacionadas a pruebas técnicas y automatización de pruebas.

Seguramente en los siguientes años veremos una mayor especialización en términos de automatización de pruebas y pruebas no funcionales. Además, se puede ver claramente que la profesionalización de la disciplina se ha adoptado tanto en EUA y Europa. También se debe considerar que además de la oferta de estas organizaciones, diferentes compañías locales y regionales están comenzando a definir sus propios esquemas de certificación y rutas de entrenamiento.

Algunos puntos a considerar:

• Todas las certificaciones mencionadas, se acreditan por medio de examen, a excepción de IIST que se acredita simplemente por entrenamiento. • Solamente ISTQB cuenta con representación regional en México (HASTQB). • ISTQB contempla dos especializaciones técnicas: Technical Analyst, Test Automation • IIST tiene la especialización técnica de: Test Automation Specialist.

62 3.1.7.1 Puntos importantes al decidir sobre una certificación Presencia a nivel mundial y reconocimiento. Es recomendable contar una certificación por parte de una organización con presencia mundial a través de capítulos o coordinaciones regionales. Aquí vale la pena revisar las organizaciones que tienen más tiempo en la industria y que han logrado formar vínculos con entidades gubernamentales u otras asociaciones similares.

Tipo de Acreditación. Básicamente hay dos tipos, las que son basadas en exámenes y las que son basadas en entrenamientos. Para las primeras, únicamente se requiere acreditar un examen y pagar su costo. Para las segundas, además del examen es forzoso haber tomado el curso oficial asociado a la certificación.

Vigencia. El tiempo que acredita la certificación, algunas no expiran y otras deben renovarse cada cierto tiempo (3 a 5 años).

Niveles de Certificación. Normalmente las organizaciones con mayor madurez ofrecen más de un nivel y esto permite una ruta de desarrollo más robusta.

Ramas de especialización. También hay algunas organizaciones que ofrecen más de un esquema de crecimiento, ya que uno puede especializarse en una rama de la disciplina de pruebas como es la Administrativa, Mejora de Procesos, Pruebas No Funcionales, Automatización, etc.

3.2 Características de las Metodologías actuales Hoy en día es común observar que todas las metodologías de software buscan en común dos aspectos:

• Calidad • Rapidez

Estos aspectos son de gran importancia en la consideración de cualquier tipo de metodología, se busca el poder subsanar estos dos problemas en el desarrollo de software para satisfacer las necesidades de los clientes y eficientar los tiempos de entrega, pero a todo esto, ¿A qué se le llama calidad del software?

3.2.1 ¿Qué es la Calidad del software? Desde los inicios de la ingeniería del software se ha intentado formalizar una definición de calidad que esté enmarcada dentro del contexto del desarrollo de software. Muchos autores están de acuerdo con la importancia que tiene la calidad del software para obtener aplicaciones con un rendimiento óptimo que cumplan con todos los requisitos establecidos por el cliente.

Tomando como base una definición genérica de calidad, desarrollada en el estándar ISO 9000,”grado en el que un conjunto de características inherentes cumple con los requisitos”, se puede

63 empezar a concebir calidad aplicada al desarrollo de software. Algunos autores han enmarcado la definición de calidad dentro de este contexto.

Autores como William E. Lewis en su libro Software “Testing And Continuous Quality Improvement” definen calidad de software desde dos puntos de vista.

• El primero, hace alusión al cumplimiento de requerimientos; de acuerdo a eso, obtener un producto de calidad implica tener requerimientos medibles, y que se cumplan. Con este significado la calidad de un producto pasa a ser un estado binario en donde se tiene o no calidad. • El segundo, tiene en cuenta al cliente; el cual define calidad de un producto o servicio como el cumplimiento de las necesidades presentadas por el mismo. Otra forma de expresar lo mencionado anteriormente es la capacidad del producto de “ajustarse para el uso”. 2 Lewis, William E. Software Testing and Continuous Quality Improvement. Awerbach. 2000. p. 3 16

Una definición más concreta de calidad de software, propuesta por Roger S. Pressman, sugiere que “la calidad de software es el cumplimiento de los requisitos de funcionalidad y desempeño explícitamente establecidos, de los estándares de desarrollo explícitamente documentados y de las características implícitas que se esperan de todo software desarrollado profesionalmente”.

Se puede ver que los dos autores exponen versiones similares de la definición de calidad de software y en general en el mundo la definición puede variar o extenderse dependiendo del autor, y no es el objetivo de este proyecto decidir cuál es la definición correcta, sin embargo se puede concluir que la calidad de software es una compleja combinación de factores que varían entre las diferentes aplicaciones y los clientes que las solicitan.

3.2.2 Factores que determinan la calidad del software En el año de 1970, McCall propuso unos factores de calidad que siguen vigentes en la actualidad, lo que quiere decir que los factores que afectan la calidad del software no cambian en el tiempo. Estos factores se dividen en dos grandes grupos; aquellos que pueden ser medidos directamente, es decir aquellos defectos descubiertos en las pruebas; y factores que pueden ser medidos únicamente de manera indirecta, como por ejemplo el mantenimiento y la facilidad de uso.

McCall y su equipo de trabajo plantearon una clasificación basada en tres aspectos importantes de todo producto de software: operación, que incluye corrección, confiabilidad, usabilidad, integridad y eficiencia; transición, compuesta por portabilidad, reutilización y compatibilidad; y por último revisión de un producto, donde se encuentran factores como facilidad de mantenimiento.

A continuación se proporcionara una breve descripción de cada factor previamente citado:

• Corrección: está compuesto por dos aspectos; cumplimiento por parte del software de las especificaciones técnicas, y satisfacción de objetivos del cliente.

64 • Confiabilidad: Expectativa que un programa desempeñe la función para la cual está hecho. • Usabilidad: Esfuerzo necesario para aprender, operar y preparar los datos de entrada de un programa e interpretar la salida. • Integridad: Grado de control sobre el acceso al software o la manipulación de los datos por parte de personas no autorizadas. • Eficiencia: Cantidad de recursos necesarios para que un programa realice su función. • Portabilidad: Esfuerzo necesario para transferir el programa de un entorno de hardware o software a otro. • Reutilización: Grado en que un programa o parte de él puede usarse en otras aplicaciones. • Compatibilidad: Esfuerzo necesario para acoplar un sistema con otro. • Facilidad de mantenimiento: Esfuerzo necesario para localizar y corregir errores en un programa. • Flexibilidad: Esfuerzo necesario para modificar un programa en operación. • Facilidad de prueba: Esfuerzo que demanda un programa con el fin de asegurar que cumpla su función 18 Se puede observar que muchos de los factores previamente mencionados se convierten en grupo de factores cuantitativos y por tanto, desarrollar medidas que permitan realizar una adecuada medición se convierte en una actividad frustrante debido a la naturaleza subjetiva de la misma.

3.2.3. Aseguramiento de la calidad del software Se puede definir el aseguramiento de la calidad del software como “las actividades sistemáticas que proveen evidencia del uso apropiado de la capacidad total del software”. En otras palabras, el aseguramiento de la calidad del software es una colección de actividades y funciones usadas para monitorear y controlar un proyecto de software desde su concepción hasta la salida en vivo, con el fin de que los objetivos específicos se cumplan con un nivel deseado de confianza.

El aseguramiento de la calidad es un esfuerzo planeado para asegurar que el producto (software) cumpla con los criterios y los factores de calidad mencionados en el numeral anterior. Estas actividades y funciones no solo son responsabilidad del equipo asegurador de calidad, sino que incluyen también al gerente/líder del proyecto, el personal del proyecto y los usuarios.

La definición de aseguramiento plantea, que sí los procesos planteados dentro del plan de calidad son seguidos de acuerdo a los lineamientos pactados, asegurarán la gestión de la calidad del producto.

Los objetivos de la calidad del software se logran siguiendo el plan de aseguramiento de calidad de software, el cual establece los métodos que el proyecto debe emplear para asegurar que los documentos y/o productos generados y revisados en cada etapa, sean de alta de calidad.

65 El aseguramiento de la calidad del software es una estrategia adoptada por la gestión del riesgo. Considerar la calidad de software dentro de la gestión del riesgo es importante porque en muchas ocasiones la calidad tiene un alto costo en los proyecto de software. A continuación, se mostrarán algunos ejemplos de mala calidad en materia de software:

• Fallas frecuentes en la funcionalidad del software. • Consecuencias secundarias de fallas en el software, como problemas financieros. • Sistemas no disponibles cuando se requiere. • Costosas mejoras en el software • Altos costos en la detección y corrección de errores.

Parte de los riesgos con respecto a la calidad están relacionados a los defectos del producto. Un defecto es una falla o falta de cumplimiento con un determinando requisito. Si dicho requisito está planteado de una forma incorrecta, generará una mayor posibilidad de que ocurran riesgos, teniendo como resultado la aparición de posibles defectos posteriores en la aplicación y productos poco verificables. Algunas de las técnicas y estrategias de gestión de riesgos incluyen Testing de software, revisiones técnicas, revisión de pares (peers) y verificación de conformidad.

El aseguramiento de la calidad de software posee tres componentes expuestos a continuación:

• Testing de software: Componente usado para verificar que los requisitos funcionales de una aplicación se cumplan. El Testing de software tiene limitaciones en cuanto al aseguramiento de la calidad se requiere, ya que una vez hecho el Testing, se dejarán descubiertos posibles defectos que cuestionan la calidad del producto evaluado, con poco o nada de tiempo para mitigar dicha falta de calidad. • Control de calidad: Compuesta por métodos y procesos usados para monitorear el trabajo y observar si los requisitos son cumplidos. Se enfoca en la revisión y posterior eliminación de defectos antes de la entrega del producto final. El control de calidad debe ser responsabilidad de la unidad organizacional que está encargada de generar el producto. En general el control de calidad consiste en una serie de revisiones (incluida en el plan de aseguramiento de la calidad) realizadas a un producto. Para el caso de los productos de software, el control de calidad generalmente incluye revisión de las especificaciones, inspecciones de código y documentación, y revisiones para los entregables. Usualmente las inspecciones del producto y de la documentación son llevadas a cabo en cada etapa del ciclo de vida de software, para demostrar que los ítems producidos cumplen con los criterios especificados en el plan de aseguramiento de la calidad. Estos criterios están determinados por las especificaciones de los requisitos, por la documentación del diseño, y por los planes de prueba. Dependiendo del tamaño del proyecto, el control de calidad puede estar cargo bien sea, del personal del departamento de calidad de software del proyecto, en caso de que

66 el proyecto sea pequeño, o de una junta de control de configuración si el proyecto es grande. Dicha junta debe incluir un representante por parte del usuario, un miembro del departamento de calidad de software, y el líder del proyecto. • Gestión de la configuración del software: Tiene que ver con el seguimiento y control de cambios de los elementos de software en un sistema. Controla la evolución de un sistema software por medio del manejo de versiones de los componentes de software y sus relaciones. El propósito de la gestión de la configuración del software es el de identificar todos los componentes de software interrelacionados y controlar su evolución a través de los diferentes ciclos de vida. La gestión de la configuración del software es una disciplina que puede ser aplicada a actividades como el desarrollo de software, el control de la documentación, control de cambios y mantenimiento. Puede proveer un alto ahorro de costos en la reutilización del software porque cada componente de software y su relación con otros componentes de software ya han sido previamente definidas. Cabe mencionar también que la gestión de la configuración del software consta de actividades que aseguran que el diseño y el código estén definidos previamente, y por tanto no se puedan cambiar sin antes hacer una revisión del efecto de tal cambio. A continuación se mencionarán los elementos que hacen parte de la gestión de la configuración del software: Identificación de componentes, control de versiones, construcción de la configuración, control del cambio.

Figura 9. Componentes de Aseguramiento de Calidad.

Hall Richard .Software Engineering Testing.. Editorial. McConnell.

Cuando se habla de aseguramiento de calidad de software es importante tener un plan que garantice que todos los procesos y/o procedimientos llevados a cabo dentro del aseguramiento de la calidad se cumplan de una manera eficiente. El plan de aseguramiento de la calidad de software (SQA, por

67 sus siglas en inglés) es un conjunto de medidas con la finalidad de asegurar ciertos niveles de calidad dentro de las fases del desarrollo de software.

El plan es usado como base para comparar los niveles actuales de calidad durante el desarrollo con los niveles planeados. Dicho plan sugiere un marco de trabajo y unos lineamientos para el desarrollo de código entendible y de fácil mantenimiento. El plan de SQA determinará si los procedimientos para asegurar la calidad del software serán desarrollados dentro del equipo de desarrollo o estarán a cargo de terceros. Para desarrollar e implementar un plan de aseguramiento de calidad de software (SQA), es necesario tener en cuenta ciertos pasos mencionados a continuación:

• Documentar el plan: Todo plan debe estar documentado para su posterior aprobación y ejecución. • Obtener aprobación de la gerencia del proyecto: La participación de la gerencia del proyecto es necesaria para poder implementar de manera exitosa un plan de SQA. La gerencia del proyecto es responsable tanto de asegurar la calidad en un proyecto de software, como de proveer los recursos necesarios para el desarrollo del mismo. • Obtener aprobación del equipo de desarrollo: Los principales usuarios de un plan de SQA son los miembros del equipo de desarrollo, por lo tanto es de vital importancia su aprobación y cooperación en el plan. • Planear la implementación del SQA: El proceso de planear, formular y esbozar un plan de SQA requiere de personal y acceso a recursos tecnológicos. La persona responsable de implementar el plan de SQA debe tener acceso a estos recursos y adicionalmente, necesita aprobación y soporte constante del gerente del proyecto para garantizar la disponibilidad de los mismos. El gerente del proyecto debe considerar todos los riesgos que puedan impedir que el proceso se lleva a cabo, como por ejemplo la disponibilidad de personal o equipos. Es necesario también desarrollar un cronograma que incluya revisiones y aprobaciones para el plan de SQA. • Ejecutar el plan de SQA: El actual proceso de ejecutar un plan de SQA involucra puntos de auditoría que permiten monitorear dicho plan. La auditoría debe ser programada durante la fase de implementación del software, para que así el plan de SQA no se vea afectado por un mal monitoreo del proyecto de software. Las auditorias deben darse periódicamente durante el desarrollo o en las etapas especificas del proyecto.

3.2.4. Estrategias de Prueba para asegurar la calidad del Software Aclarar el concepto de estrategia dentro del contexto de pruebas de software es sumamente difícil ya que los autores usan el término “estrategia” para exponer diferentes ideas todas ellas relacionadas con proyectos de prueba de software.

68 Para algunos la estrategia son las técnicas y metodologías que deben aplicarse al momento de realizar las pruebas; otros como William Perry y Roger Pressman, recurren a la palabra estrategia dentro de dos enfoques.

Primero: Se refiere a estrategia como el plan general que guía y permite el seguimiento del proyecto de pruebas, e integra los métodos de diseño de casos de pruebas en una serie bien planeada de pasos.

Segundo, estrategia como las técnicas y metodologías que deben aplicarse en cada uno de los tipos de pruebas que se consideran dentro de las etapas del plan general. Autores más especializados en el tema como Rick D. Craig y Stefan P. Jaskiel, consideran el concepto de estrategia mencionada por Pressman como una planeación maestra de pruebas a lo que denominan “Master Test Planning”.

A pesar de las diferencias conceptuales con las que se refieren al termino estrategia, los autores coinciden que antes de empezar a realizar cualquier actividad relacionada con pruebas de software, debe existir un plan de pruebas (De ahora en adelante plan) que soporte y considere todas las decisiones administrativas que se toman a partir de las condiciones que rodean el proyecto, como: riesgos, recursos (tanto humanos como materiales) y tiempo, para lograr el buen desarrollo del mismo. Además de lo anterior, el plan debe tener objetivos medibles y alcanzables que conlleven al desarrollo de software de calidad.

El nivel de detalle a alcanzar por el plan debe permitir al desarrollador basar su trabajo diario de acuerdo a lo estipulado en el mismo y sobre todo, servir de guía para que el gerente realice control sobre el proyecto

3.2.5 Selección de la Metodología a aplicar Una de las primeras decisiones a la que nos enfrentamos cuando comenzamos a enfocar un proyecto es elegir la metodología más adecuada para el mismo. Generalmente no es una decisión sencilla, siendo necesario debatir los requerimientos del proyecto antes de elegir la más apropiada.

Las dos metodologías más utilizadas en el desarrollo de proyecto son:

Waterfall: También denominada en “cascada”, es el método que se ha utilizado tradicionalmente. Consiste en desarrollar un proyecto de forma secuencial, comenzando con las fases de análisis y diseño y terminando con las de testeo y puesta en producción.

Agile: Una metodología de tipo RAD (Rapid Application Development), siendo Scrum el método más utilizado.

Ambas metodologías son usables, maduras y se pueden implementar en una gran variedad de proyectos. A continuación, analizaremos las fortalezas y debilidades de cada una de ellas.

69 La metodología Waterfall Esta metodología es una aproximación lineal al desarrollo de software y ha sido la más utilizada durante los últimos 30 años. La secuencia que sigue este método está compuesta de las siguientes fases:

• Captura y documentación de requisitos • Diseño • Desarrollo • Test • UATs • Corrección de errores y ajustes finales • Puesta en producción

En un desarrollo waterfall puro, cada una de estas fases representan una etapa diferenciada en el desarrollo del producto final. Cada una de estas etapas debe darse por concluidas antes de comenzar con la siguiente. Además, entre cada una de ellas, generalmente tenemos un hito bloqueante que nos impide avanzar a la siguiente si este no se libera adecuadamente. (P.ej. Los requisitos han de ser validados por el cliente antes de avanzar a la fase de diseño.) Ventajas de la metodología Waterfall

No podemos negar que el uso de esta metodología aporta puntos positivos al desarrollo de un proyecto:

Desarrolladores y clientes se ponen de acuerdo en una fase muy temprana del proyecto. Esto lleva a una planificación y un diseño más sencillos y directos.

El progreso del proyecto es más fácil de medir y seguir, dado que el alcance completo del mismo se conoce de antemano.

Durante la fase de desarrollo, es posible que varios miembros del equipo participen o continúen con otros trabajos, dependiendo de la fase activa del proyecto. Por ejemplo, los analistas de negocio pueden aprender y documentar lo que se necesita hacer, mientras los desarrolladores están trabajando en otros proyectos. Los testers, a su vez, pueden preparar scripts de prueba a partir de la documentación de requisitos, mientras la codificación está en curso.

Excepto para revisiones, aprobaciones y reuniones de estado, no se requiere estrictamente la presencia del cliente después de la fase de requisitos.

Debido a que el diseño se completa al principio del ciclo de vida de desarrollo, esta metodología es idónea para proyectos en los que deben diseñarse múltiples componentes de software, a veces en paralelo, para su integración con sistemas externos.

70 Finalmente, el software puede ser diseñado completamente y con más cuidado, basado en una comprensión más completa de todos los entregables del software.

Desventajas de Waterfall

Pero también nos encontramos con circunstancias adversas cuando decidimos emplear una metodología waterfall puro:

Un aspecto que casi siempre falla es la eficacia de los requisitos. Reunir y documentar los requisitos de una manera que sea significativa para el cliente es, a menudo, la parte más difícil del desarrollo de software. En muchas ocasiones, los clientes se sienten intimidados por los detalles, y con este enfoque se requieren detalles específicos, proporcionados al principio del proyecto. Además, los clientes no siempre pueden visualizar una aplicación desde un documento de este tipo. Los wireframes y maquetas pueden ser de ayuda para llegar a una imagen certera de lo que obtendrá el usuario final.

Otro inconveniente del desarrollo waterfall es la posibilidad de que el cliente no esté satisfecho con el producto de software suministrado. Dado que todos los entregables se basan en requisitos documentados, es posible que un cliente no vea lo que se entregará hasta que esté casi terminado. Para entonces, los cambios pueden ser difíciles de implementar y costosos.

La metodología Agile Agile es un enfoque iterativo y basado en equipos para el desarrollo. Este enfoque enfatiza la entrega rápida de una aplicación en componentes funcionales completos. Cada Sprint tiene una duración definida con una lista continua de entregables, planificada al principio del sprint. Los entregables son priorizados por el valor del negocio, determinado por el cliente. Si no se puede completar todo el trabajo planificado para el sprint, se vuelven a priorizar las tareas y se incluyen en el siguiente sprint.

A medida que el trabajo se completa, este puede ser revisado y evaluado por el equipo del proyecto y el cliente, a través de las ceremonias Agile. Las metodologías Agile cuentan con un alto nivel de participación del cliente en todo el proyecto, pero especialmente durante estas revisiones.

Ventajas de la metodología Agile

El cliente adquiere un fuerte sentido de pertenencia al trabajar estrechamente con el equipo durante todo el proyecto.

El cliente tiene oportunidades frecuentes y tempranas para ver el trabajo que se está llevando a cabo, tomar decisiones y solicitar cambios a lo largo del proyecto de desarrollo.

Si el lanzamiento al mercado de una aplicación es prioritario, gracias a las metodologías Agile se puede producir una versión básica de software operativo que puede ser completada en sucesivas iteraciones.

71 El desarrollo está centrado en el usuario.

Desventajas de Agile

El elevado grado de implicación del cliente, aunque es excelente para el resultado final del proyecto, puede presentar problemas para algunos ya que no disponen del tiempo o interés para este tipo de participación.

Ágile funciona mejor cuando los miembros del equipo de desarrollo están completamente dedicados al proyecto.

Debido a que Agile se enfoca en la entrega con timebox o caja de tiempo y la re-priorización frecuente, es posible que algunos elementos establecidos para la entrega no se completen dentro del plazo asignado, lo que incrementaría el coste del proyecto. Además, la participación de los clientes a menudo conduce a características adicionales, solicitadas a lo largo del proyecto, lo que puede derivar en un aumento del tiempo y el coste total de la implementación.

Las estrechas relaciones de trabajo en un proyecto Agile son más fáciles de gestionar cuando los miembros del equipo están ubicados en el mismo espacio físico, lo que no siempre es posible.

La naturaleza iterativa del desarrollo agile puede llevar a una frecuente refactorización si el alcance completo del sistema no es considerado en la arquitectura y diseño inicial. Sin esta refactorización, el sistema puede sufrir una reducción de la calidad global. Esto se hace más pronunciado en implementaciones de mayor escala o con sistemas que incluyen un alto nivel de integración.

Entonces, ¿cómo elegimos entre waterfall y Agile?

Decidir la metodología más adecuada para cada caso no es una decisión sencilla, cada proyecto, por sus características intrínsecas, requiere distintas formas de gestión. Es conveniente hacer una investigación del proyecto con detenimiento, así como de las circunstancias que lo rodean y del entorno del propio cliente.

En ocasiones, implementar íntegramente una metodología, ya sea waterfall o Agile, es bastante complejo. Es por ello que, dependiendo de la tipología del proyecto, recomendamos un enfoque metodológico híbrido, al que hemos denominamos Hybrid Agile. Esta metodología, parte de Scrum, y suaviza un poco la curva de adaptación al mismo, sin perder la capacidad de introspección, transparencia e iteración de las metodologías Agile, a la vez que introduce ciertas características de metodologías más tradicionales, haciendo así que en entornos que tienen escasa formación en enfoques Agile, los equipos de trabajo y el cliente se sientan más cómodos.

Esta metodología hibrida incluye el uso de prototipos, donde sea posible, para proporcionar al cliente una mejor visión de su producto terminado al principio del ciclo de diseño y desarrollo. Esto ayuda a mejorar la comprensión del equipo de los requisitos y la comunicación con el cliente.

72 Consideramos los siguientes factores (reflejados en la tabla comparativa) a la hora de elegir una metodología frente a la otra.

Figura 10. Tabla comparativa entre las metodologías Waterfall y Agile

Hall Richard .Software Engineering Testing.. Editorial. McConnell.

En esta figura, de describe a alto nivel la interacción de cada Macroactividad al igual que la secuencia en la que se llevara a cabo la actividad y su interacción con las mismas.

3.2.6 Criterios de Selección de metodologías de desarrollo de Software Como se ha descrito en puntos anteriores, el uso de la metodología correcta tiene que ver en gran medida con el tipo de Proyecto y la necesidad del Cliente, estas variantes tienen gran impacto en el tipo de metodología que se estará utilizando. Respecto a la metodología, no se tiene una buena o mala, simplemente el utilizar alguna va muy de la mano con la necesidad que el cliente tenga.

En este punto se presentaran algunos factores que se deben de tomar en cuenta previo a utilizar algún tipo de metodología en el desarrollo del Proyecto, los cuales son:

73 • Visión del producto. • Vinculación con el cliente. • Establecer un modelo de ciclo de vida. • Gestión de los requisitos. • Plan de desarrollo. • Integración del proyecto. • Medidas de progreso del proyecto. • Métricas para evaluar la calidad. • Maneras de medir el riesgo. • Como gestionar los cambios. • Establecer una línea de meta

3.3. Situación actual en la Implementación de Metodologías de Testing “No sobrevive la especie más fuerte, ni la más inteligente, sino la que responde mejor al cambio” Charles Darwin

Los sistemas de hoy en día son cada vez más complejos, deben ser construidos en tiempo récord y deben cumplir con los estándares más altos de calidad. Para hacer frente a esto, se concibió y perfeccionó lo que hoy conocemos como Ingeniería de Software Basada en Componentes (ISBC), la cual se centra en el diseño y construcción de sistemas computacionales que utilizan componentes de software reutilizables. Esta ciencia trabaja bajo la filosofía de "comprar, no construir", una idea que ya es común en casi todas las industrias existentes, pero relativamente nueva en lo que a la construcción de software se refiere.

Para este momento, ya muchos conocen las ventajas de este enfoque de desarrollo y, de la misma forma, muchos se preguntan día a día el por qué son tan pocos los que realmente alcanzan el éxito siguiendo esta filosofía. La realidad es que aún se ha tanteado poco las posibilidades del software basado en componentes, y es justo hora, en la presente década, que la industria del software despegará y se perfeccionará para estar a la par de cualquier otra industria del medio, este camino hacia el perfeccionamiento de este modelo de desarrollo tan prometedor debe incluir necesariamente la concepción de su propia metodología de testing que apoye y garantice la calidad del software desarrollado con este modelo, haciendo que cada vez más sea tenido en cuenta por esta industria, la del desarrollo de software.

Este trabajo de grado apunta a ello, a proponer una metodología adaptable al desarrollo de software basado en componentes, que al igual que los otros modelos de desarrollo tienen un ciclo de vida del mismo, a través del cual se puede asegurar en un alto porcentaje la calidad del software cuando se ejecutan todas las pruebas necesarias a lo largo de todo este ciclo, a pesar de ello la metodología

74 que se propondrá solo se centrará en la planeación, diseño, ejecución y evaluación de las pruebas funcionales integrales de caja negra en las etapas de implementación con enfoque en la ventaja y en el factor crítico del método de desarrollo que son la reutilización de componentes e integración de componentes respectivamente, esto con el fin de convertir el control de calidad, en un proceso práctico que no presente reacción negativa en las organizaciones que quieran adaptar el desarrollo de software basado en componentes como modelo de desarrollo y que deseen por el contrario que 16 se convierta en un factor diferenciador para el incremento de la productividad en áreas de Tecnologías de Información.

Esta propuesta metodológica estará estructurada siguiendo el ciclo PHVA (ciclo Demming – Planear, Hacer, Verificar, Actuar) para identificar los actores, las actividades y los resultados de cada proceso. Esto permite focalizar fácilmente las tareas relacionadas con la planeación, la ejecución, el control y el mejoramiento de las pruebas funcionales de software.

Figura 11, Ciclo PDCA (Planificar, Hacer, Verificar, Actuar)

Porter Michael (2001). Estrategia Competitiva, Técnicas para el Análisis de las Empresa y sus Competidores. Editorial. Cecsa.

El ciclo PDCA se define como una estrategia, que trae consigo la mejora continua de algún Proceso, su utilización se divide en 4 rubros:

Planificar: Se establecen las actividades del proceso, necesarias para obtener el resultado esperado. Al basar las acciones en el resultado esperado, la exactitud y cumplimiento de las especificaciones a lograr se convierten también en un elemento a mejorar. Cuando sea posible conviene realizar pruebas de preproducción o pruebas para probar los posibles efectos.

• Recopilar datos para profundizar en el conocimiento del proceso. • Detallar las especificaciones de los resultados esperados.

75 • Definir las actividades necesarias para lograr el producto o servicio, verificando los requisitos especificados. • Establecer los objetivos y procesos necesarios para conseguir resultados de acuerdo con los requerimientos del cliente y la política organizacional.

Hacer: Se ejecuta la mejora Propuesta, es decir, de acuerdo a lo planeado se comienzan a ejecutar las actividades paulatinamente con el fin de cumplir con lo descrito en el Plan.

Verificar: Pasado un periodo predeterminado, se procede a analizar el comportamiento de lo hecho, los datos de control son recopilados y analizados, comparándolos con los requisitos especificados inicialmente, para saber si se han cumplido y, en su caso, evaluar si se ha producido la mejora esperada.

Monitorear la implementación y evaluar el plan de ejecución documentando las conclusiones.

Actuar: A partir de los resultados conseguidos en la fase anterior (Verificar) se procede a recopilar lo aprendido y a ponerlo en marcha. También suelen aparecer recomendaciones y observaciones que suelen servir para volver al paso inicial de Planificar y así el círculo nunca dejará de fluir.

Actualmente algunos expertos prefieren denominar este paso "Ajustar". Esto ayuda a las personas que se inician en el ciclo PDCA a comprender que el cuarto paso tiene que ver con la idea de cerrar el ciclo con la realimentación para acercar los resultados obtenidos a los objetivos. Además, no debe confundirse este paso "A" con el conjunto de acciones (implementación) consecuencia del despliegue de los planes (que se desarrolla en el segundo paso, "D", de "hacer" o "llevar a cabo las Acciones").

El ciclo PDCA ha sido utilizado para implementar metodologías basadas en la reutilización de componentes, obteniendo como resultado un ahorro significado de tiempo.

3.3.1 Modus Operandi en la aplicación de Metodologías de Testing Actualmente vivimos en un mundo tan digitalizado que hemos llegado a un punto en el que hemos logrado tener el control de todos nuestros procesos de negocios en la punta de los dedos. Sin embargo, las empresas que deseen garantizar su vigencia en el mercado y aumentar su eficiencia, deben saber no solo cómo sacar máximo provecho de las soluciones que tienen a su alcance, sino contar con soluciones que incluyan las mejores metodologías de desarrollo de software que permitan que la gestión de sus procesos empresariales sean mucho más ágiles.

Vivimos una competencia tan acelerada que muchas empresas desarrollan un nuevo producto y cuando se lanza al mercado ya se ha quedado obsoleto. Las metodologías tradicionales para el desarrollo de productos, y especialmente en el ámbito de IT, empiezan a convertirse en un cuello de botella importante.

76 Desde siempre se ha considerado necesario tener una definición completa del producto y una planificación detallada para arrancar con su desarrollo. Sin embargo, los sistemas van creciendo en complejidad y en interrelaciones, lo cual hace que cada vez cueste más tiempo definir un producto. Además, en muchos casos no es posible definir desde un inicio el producto porque no están claros algunos aspectos o funcionalidades que lo componen y es necesario realizar pruebas de concepto para aterrizar muchas de las ideas que originaron su existencia. Incluso hasta que no tenemos el producto en producción no nos damos cuenta de funcionalidades que ni siquiera habíamos imaginado, o incluso se han producido cambios que hemos tenido que abordar sobre la marcha.

Las metodologías ágiles pretenden facilitar este proceso de cambio frecuente y adaptación constante.

El modus operandi de una metodología ágil como puede ser Scrum, tiene en su ADN la posibilidad de cambio frecuente. Las áreas de negocio definen unas necesidades y esas necesidades se van agrupando en historias de usuario que permiten describir cómo se va a comportar el sistema. A continuación, se van priorizando según el valor aportado al negocio, y se incorporan a un “saco” general de desarrollo denominado backlog.

El equipo comienza a desarrollar estableciendo unos periodos de trabajo llamados sprints de duración habitual entre dos y cuatro semanas, en los cuales se va construyendo el producto de manera incremental. De esta forma tenemos la tranquilidad de que, si nos hemos equivocado en la definición de características, se pueden ir ajustando a medida que se va completando el producto. Al mismo tiempo, en cada iteración existe la posibilidad de ir viendo cómo se va construyendo de manera gradual, no teniendo que esperar a su finalización para ver el resultado. A pesar de ello, lo habitual es cerrar el contenido de lo que se suele denominar mínimo producto viable. El resto de entregas se consideran incrementos funcionales o evoluciones del producto inicial.

Los equipos de negocio pueden ir verificando si tiene sentido conceptualmente lo que se está construyendo. Por otro lado, la capacidad de respuesta ante el cambio aumenta y permite que la organización sea mucho más flexible adaptándose rápidamente a las nuevas circunstancias.

Las metodologías ágiles parten de un enfoque completamente diferente a las tradicionales, ya que las áreas de negocio no pueden tener cerrado completamente el producto si tiene cierta complejidad, ni tampoco pueden cerrar un presupuesto al inicio.

El método está orientado a ajustar un producto lo máximo posible y lo más rápido posible, no persigue reducir coste, aunque pueda ser una consecuencia de su propio funcionamiento. La clave está en ir viendo cómo evoluciona el producto y modificar sobre la marcha cualquier aspecto que se necesite.

77 Un profundo cambio Top-Down

Las metodologías ágiles suponen un profundo cambio de funcionamiento, que requiere estar alineado desde el nivel más alto de la empresa. Solo cuando se entiende, comparte e impulsa la filosofía que hay detrás, se toma conciencia de los beneficios potenciales que proporciona, lo cual facilita la labor de asimilación por toda la organización. Se necesita un “cambio de chip” para aquellos grupos y organizaciones acostumbrados a trabajar con metodologías tradicionales

Figura 12, Metodología Tradicional contra Metodología Ágil

Porter Michael (2001). Estrategia Competitiva, Técnicas para el Análisis de las Empresa y sus Competidores. Editorial. Cecsa.

78 3.3.1.1 El Proceso ágil en Scrum Scrum es una de las metodologías ágiles más utilizadas en el desarrollo de software y que hoy en día, muchas empresas apuestan por adoptar dada las necesidades tan cambiantes en aspectos de tecnología. En la fase de preventa únicamente se cierra la forma de trabajo, se establecen las “reglas del juego”, los puntos intermedios de revisión y las funcionalidades del producto mínimo viable que se entregará inicialmente. Un producto mínimo viable puede requerir de varios sprints para su construcción. El proceso de trabajo se refleja a continuación.

Figura 13, Ciclo de implementación y operación de un Proceso Scrum

Porter Michael (2001). Estrategia Competitiva, Técnicas para el Análisis de las Empresa y sus Competidores. Editorial. Cecsa.

3.4 Problemática A pesar de los beneficios que se pueden obtener de la correcta aplicación de los procesos, técnicas y herramientas de verificación y validación de software, la utilización institucionalizada de los mismos en la industria, sobre todo en las pequeñas y medianas organizaciones de desarrollo de software, no alcanza los niveles mínimos para el logro de los beneficios potenciales. En esta ponencia se presentan los 10 factores más importantes que impiden la correcta aplicación de las prácticas eficientes de verificación y validación de software, cabe mencionar que por temas de costos muchas organizaciones se niegan a invertir en este aspecto, sin embargo, al futuro los retrabajos se traducen en pérdidas económicas.

79 Se ha reportado en numerosos estudios relativos al beneficio obtenido a raíz de procesos de mejora que la implantación de un proceso formal de verificación y validación supone importantes beneficios para las organizaciones software:

• Se produce un incremento de la satisfacción del cliente al utilizar un software con una cantidad de errores inferior. • Se incrementa la eficiencia del proceso de desarrollo. – • Se facilita la definición y cumplimiento de los objetivos de calidad. • Se incrementa la satisfacción de los trabajadores debido a que se proporcionan herramientas y recursos apropiados para la realización eficiente del trabajo.

Además, las empresas han reportado la consecución de beneficios económicos asignables a las actividades de mejora del proceso de verificación y validación de software son los siguientes:

• Reducción de un 20% en los errores en el software entregados al cliente (BKIN Software). • El esfuerzo en pruebas de software se redujo desde el 25% al 20% del esfuerzo total del proyecto (BKIN Software). • El número de errores detectados en las pruebas de aceptación es menor del 12% de los errores detectados en las pruebas de integración. El valor anterior era del 37%. (BKIN Software). • Los errores informados por el cliente/usuarios se han reducido en un 77% (Archetypon). • 30% de reducción en los costes de ejecución (IMB SEMEA SUD). • Reducción en el tiempo de entrega e incremento en la eficiencia de las pruebas (Nokia – Network Management Systems)

Figura 14. Beneficios en la adopción de un Proceso estándar de Testing

Carretero Arriba Alberto (2015).Pruebas de funcionalidad y optimización de páginas Web. Editorial. IC Editorial.

80 Sin embargo, a pesar de los beneficios que una aplicación institucionalizada de procesos de verificación y validación de software, según el perfil de madurez mundial de las organizaciones intensivas en software elaborado por el Software Engineering Institute (SEI), de aquellas organizaciones (402 en 2006) que evaluaron sus procesos con respecto al nivel 2 de capacidad establecido por el CMMI para el Proceso de Verificación, solo el 2,98% de las organizaciones (12) lograron satisfacer totalmente ese nivel, mientras que el 7,96% organizaciones (32) lo lograron satisfacer parcialmente es decir, no en la totalidad de los requisitos marcados por el CMMI). Por otra parte, para aquellas organizaciones (45 en lo que llevamos de 2006) que evaluaron sus procesos con respecto al nivel 1 de capacidad establecido por el CMMI para el Proceso de Verificación, solo el 8,88% de las organizaciones (4) lograron satisfacer totalmente ese nivel, mientras que el 40% de las organizaciones (18) lo lograron satisfacer parcialmente. Ante estas cifras tan bajas, es necesario que se analicen los factores que impiden que las prácticas eficientes relativas a la verificación y validación se introduzcan.

3.4.1 Principales errores de fallo en el Software ¿El software falló?

No hace lo requerido (o hace algo que no debería)

Razones:

• Las especificaciones no estipulan exactamente lo que el cliente precisa o quiere (requisitos faltantes o incorrectos) • Requerimiento no se puede implementar • Faltas en el diseño • Faltas en el código • La idea es detectar y corregir estas faltas antes de liberar el producto

3.4.2 Tipos de Fallas • En algoritmos • De sintaxis • De precisión y cálculo • De documentación • De estrés o sobrecarga • De capacidad o de borde • De sincronización o coordinación • De capacidad de procesamiento o desempeño • De recuperación • De estándares y procedimientos • Relativos al hardware o software del sistema Introducción 81 3.4.2.1 En algoritmos Faltas típicas

• Bifurcar a destiempo • Preguntar por la condición equivocada • No inicializar variables • No evaluar una condición particular • Comparar variables de tipos no adecuados

3.4.2.2 De sintaxis • Ejemplo: Confundir un 0 por una O • Los compiladores detectan la mayoría

3.4.2.3 De precisión o de cálculo Faltas típica

• Formulas no implementadas correctamente • No entender el orden correcto de las operaciones • Faltas de precisión como un truncamiento no esperado •

3.4.2.4 De documentación • La documentación no es consistente con lo que hace el software. • Ejemplo: El manual de usuario tiene un ejemplo que no funciona en el sistema.

3.4.2.5 De estrés o sobrecarga Exceder el tamaño máximo de un área de almacenamiento intermedio.

Ejemplos

• El sistema funciona bien con 100 usuarios pero no con 110 • Sistema que funciona bien al principio del día y se va degradando paulatinamente el desempeño hasta ser espantoso al caer la tarde.Falta: había tareas que no liberaban memoria.

3.4.2.6 De capacidad o de borde Más de lo que el sistema puede manejar

Ejemplos

• El sistema funciona bien con importes. • Año 2000. Sistema trata bien fechas hasta el 31/12/99

82 3.4.2.7 De sincronización o coordinación No cumplir requerimiento de tiempo o frecuencia.

Ejemplo

• Comunicación entre procesos con faltas.

3.4.2.8 De capacidad de procesamiento o desempeño • No terminar el trabajo en el tiempo requerido. • Tiempo de respuesta inadecuado.

3.4.2.9 De recuperación • No poder volver a un estado normal luego de una falla.

3.4.2.10 De estándares o procedimientos • No cumplir con la definición de estándares y/o procedimientos.

3.4.2.11 De hardware o software del sistema • Incompatibilidad entre componentes.

3.4.3 Clasificación de Defectos Dentro de los problemas más comunes a la hora de instalar un software aparentemente terminado se encuentran los siguientes:

Categorizar y registrar los tipos de defectos

• Guía para orientar la verificación o Si conozco los tipos de defectos en que incurre la organización me puedo ocupar de buscarlos expresamente.

Mejorar el proceso

• Si tengo identificada la fase en la cual se introducen muchos defectos me ocupo de mejorarla.

3.4.3.1 Clasificación Ortogonal • Cada defecto queda en una única categoría. • Si pudiera quedar en más de una de poco serviría.

3.4.3.2 Clasificación Ortogonal de IBM • Función: afecta capacidad de brindarla, interfaz usuario, de producto, con hardware o estructura global de datos. • Interfaz: al interactuar con otros componentes o drivers vía call, macros, control blocks o lista de parámetros. • Validación: no valida de forma adecuada los datos antes de usarlos.

83 • Asignación: falta en inicialización de estructura de datos o bloque. • Tiempo/serialización: recursos compartidos o tiempo real. • Build/package/merge: problemas en repositorios, control de cambios o versiones. • Documentación: publicaciones o notas de mantenimiento. • Algoritmo: involucra eficiencia o correctitud de algoritmo o estructura de datos, pero no diseño.

3.4.4 Descripción de los principales problemas relativos a la Implementación de un Proceso para pruebas de Testing. El modelo ideal, como otras aproximaciones para la introducción de mejoras en el proceso productivo de una organización (Plan-Do-Check-Act, PDCA), tiene como principal propósito establecer los mecanismos necesarios para facilitar la realización de programas de mejora continúa en organizaciones, aunque el modelo ideal está especialmente orientado a las mejoras en organizaciones intensivas en software. Estos modelos de mejora, con un nombre u otro, definen las siguientes fases para la realización satisfactoria de un programa de mejora de procesos:

1. Obtención del compromiso, cuyo propósito consiste en establecer los objetivos que se deberán alcanzar con la utilización sistemática de la mejora, en este caso en el proceso de verificación y validación, desarrollar el plan para la realización de las mejoras (incluyendo la dotación de los recursos necesarios) y la obtención del compromiso requerido en cuanto a los objetivos, actividades, calendario y recursos disponibles para el programa de mejora. 2. Diagnosis, cuyo objetivo consiste en establecer las prácticas eficientes ya existentes en la organización e identificar las necesidades y oportunidades concretas, en este caso, relativas a la mejora de los procesos de verificación y validación. 3. Definición, que persigue la definición del proceso y de todas las guías que permitan adaptar el proceso general definido a cada uno de los tipos de trabajos realizados por la organización. 4. Implantación, cuyo propósito es el logro de la utilización generalizada en todos los trabajos de la organización del proceso mejorado. 5. Por último, la fase de análisis de resultados tiene como propósito cuantificar las mejoras logradas con la introducción del nuevo proceso y determinar los próximos objetivos de mejora a satisfacer. Por otra parte, para poder aplicar convenientemente cualquiera de los modelos de mejora es necesario que se aplique un modelo de referencia que establezca los objetivos de los procesos de verificación y validación, así como las actividades y tareas que permiten conseguir eficientemente el propósito de los mismos. Siguiendo la estructura del modelo IDEAL y la necesidad de modelos de referencia de procesos software para su aplicación, se presenta clasificadas por la fase del modelo IDEAL en la cual se manifiestan. Para cada uno de los problemas reflejados se presenta su identificación (mediante una breve

84 frase), su descripción detallada y la solución que los autores de la ponencia plantean o han aplicado con éxito. Es necesario tener en cuenta que los problemas NO están ordenados por orden de importancia

3.4.5. Beneficios en la aplicación de pruebas ¿Por qué son necesarias las pruebas?

Querámoslo o no, actualmente el uso de software es pan nuestro de cada día. En momento, mientras escribo tengo en la pantalla de mi computadora 3 escritorios y 15 pestañas abiertas con diferentes herramientas de software. Además, tengo al lado mi teléfono móvil con aplicaciones que uso todo el tiempo, y una Tablet que me sirve para leer y ver mis series favoritas de Netflix. En fin, puedo decir que mi vida productiva depende enteramente de software que funcione. Y sé que no estoy sólo en esto.

¿Acaso no es frustrante cuando el software que está usando de pronto no funciona? Personalmente si un sitio web o una aplicación móvil tarda 3 segundos más en cargarse, me molesto y me distraigo. Seamos sinceros, vivimos en una época en la que nadie es paciente con software de mala calidad.

Es por eso que el aseguramiento de la calidad (QA) debe ser parte integral en cualquier proyecto de software. La ciencia detrás de las pruebas QA está en identificar con precisión la calidad del software con el objetivo de asegurar que el software funcione como se espera que funcione en todo momento. El término se refiere a diferentes métodos y procesos para probar software y garantizar su calidad.

Por eso las pruebas QA son su mejor aliado en la relación costo beneficio, y para poder garantizarse software de excelente calidad.

1 QA le ahorra dinero y muchos dolores de cabeza

¿Cuánto dinero le cuesta un proyecto de software defectuoso? Les cuesta usuarios y a los clientes. Y es bien sabido que cuanto más tiempo pasa inadvertido un error en su software, más difícil y costoso se vuelve solucionarlo. Al emplear pruebas de aseguramiento de la calidad durante todo el proceso de desarrollo del software, ahorrará tiempo y dinero después de la implementación.

2 QA previene emergencias corporativas catastróficas

Con el software corporativo, lo que está en juego es aún más importante. Los errores en el software corporativo pueden ocasionar apagones del sistema, datos faltantes y fallas de comunicación. Si va a utilizar software en una empresa o para manejar información sensible, entonces debe asegurarse de que el software funcionará exactamente como debe funcionar. No hay margen de error.

85 3 QA inspira confianza del cliente

Al hacer que el Software Testing para Aseguramiento de la Calidad tenga una clara prioridad para el desarrollo de software, está enviando un mensaje a sus clientes indicando que desea que su software tenga el mayor éxito posible. Esto es extraordinariamente importante cuando se trata de ofrecer calidad y forjar relaciones a largo plazo.

4 QA mantiene una gran experiencia de usuario

Cada vez es más claro que la experiencia del usuario creará o romperá un producto. Si el software está fallando o es lento, entonces interrumpe la experiencia del usuario con el producto. La mala experiencia del usuario resulta en insatisfacción y frustración. Una buena experiencia de usuario, lo que obtiene cuando ha probado meticulosamente un producto de software, resulta en un usuario satisfecho, que es mucho más probable que recomiende el producto y su negocio a otros.

5 QA trae más ganancias

Si está creando un software que va a comercializar o vender, entonces invertir en QA significará que puede vender su producto a una tasa mayor. No hay nada peor que un usuario enojado que pagó por un producto que no funciona bien.

6 QA aumenta la satisfacción del cliente

En relación con el primer punto, este sexto beneficio se centra en la reputación que la satisfacción del cliente aporta a su empresa, no solo la ganancia. Al ofrecer un software de calidad que funciona cuándo y cómo desea que funcione, aumentará su reputación al producir clientes satisfechos. No ponga a prueba la paciencia de sus clientes con software defectuoso que tiene que arreglar constantemente.

Proporcione calidad desde el principio y le recompensarán con su lealtad.

3.5 Presentación de Hipótesis Al desarrollar un modelo de pruebas y calidad de software, las pruebas se realizarán de una manera integral y concisa, obteniendo como resultado una mejora en el nivel de calidad del producto final y la optimización de los tiempos de entrega.

86 CAPITULO IV PROPUESTA PARA SOLUCIONAR EL PROBLEMA El modelo de construcción de software más usado en la actualizado y que nos permite adaptarnos a los continuos cambios del cliente es el método “Ágil”, por lo que debemos poder realizar un proceso de pruebas continuas a través del ciclo de vida del proyecto.

Que pueda garantizar la calidad del código en todos los niveles además de que se cumplan con las exigencias del negocio mintiéndonos siempre dentro del tiempo acordado para el desarrollo.

Sabemos que la mayoría de los errores se producen en las primeras etapas y que no se pueden visualizar hasta la etapa tardía, por eso es necesario llevar a cabo un plan de pruebas ágil que pueda interactuar con las iteraciones naturales del modelo de desarrollo, por ejemplo SCRUM.

4.1 Propuesta de solución: Modelo de Pruebas y Calidad de Software El proceso de pruebas formal tendrá que llevarse a cabo en cada iteración (sprint) del desarrollo. Deberá existir un rol de tester y un equipo que pueda ejecutar matrices de prueba hechas durante el desarrollo y que es parte de los criterios de aceptación para cada historia de usuario escrita.

Sin embargo cada desarrollador tendrá que realizar pruebas de forma individual utilizando las herramientas ya conocidas por el desarrollador, esto es debe hacer pruebas unitarias y cumplir con un porcentaje ( definido en conjunto por el gerente del área ) de cobertura para cada método utilizado en su código.

Este tipo de pruebas puede ser automatizado si se utilizan las herramientas adecuadas, como lo es por ejemplo el “Bamboo” y el “Bitbucket” de Atlassian, donde se tendrían que actualizar los códigos usando un gestor de versiones de código donde haya una revisión y se aseguren de cumplir el DoD (Definition of Done)

Además de todo esto, es necesario generar un plan de pruebas ágil, considerando que en contraste con un plan de prueba en cascada tradicional, un plan de prueba ágil está más orientado al time boxing que está relacionado con el tiempo de la iteración de desarrollo. Básicamente, en una metodología “ágil”, hacemos lo que se necesita dentro de un periodo de tiempo y dividimos nuestro plan en estas áreas de consideración:

1. Requisitos y fase de diseño:

Esta fase es similar al flujo de trabajo de prueba tradicional. Las tareas principales consisten en comprender las características y las historias de los usuarios, pero solo para esa iteración, definir la estrategia de prueba, definir el alcance de las pruebas y estimar en términos generales cuánto tiempo se debe dedicar. Pero hay algunas diferencias:

• La definición de controladores de prueba o interfaces de prueba se vuelve más importante en esta fase. Esto se debe a que en la mayoría de los casos,

87 la IU no está lista y las pruebas deben ejecutarse a través de estas interfaces. • Dado que se dedica tiempo adicional al diseño del controlador de prueba, el diseño del caso de prueba requerirá menos tiempo. Es común encontrar que los casos de prueba en ágil son más bien una guía suelta. Esta fase gastará 10% - 15% del tiempo de sprint.

Cuando los requisitos cambian, los flujos de trabajo de Agile le ofrecen la capacidad de adaptarse a estos cambios, por lo que no puede tener un gran plan de prueba rígido. Las pruebas ágiles deben ser tan ágiles como los requisitos en sí. Las pruebas deben seguir las funciones implementadas en esa iteración independientemente del plan.

2. Fase de verificación de Historias / Características: En esta fase, la ejecución de la prueba debe comenzar con historias o características, incluso si no es completamente funcional. Las actividades de prueba en esta fase pueden incluir:

• Investigación sobre las características. • Revisión estática del código. • Pruebas de caja gris utilizando controladores o interfaces para probar las características • Prueba de caja negra de características con la interfaz de usuario existente • Pruebas de historias cruzadas entre características: a medida que se realizan las compilaciones nocturnas, las características e historias comenzarán a funcionar juntas, por lo que se deben probar escenarios que involucran más de una, a veces 2 y 3 historias de usuarios. • Pruebas de integración El objetivo principal de esta fase es asegurarse de que todas las características nuevas funcionen bien dentro de sí mismas y con otros componentes. Algunas verificaciones menores pueden posponerse a los hitos 3 o 4, pero el nivel de confianza en las nuevas funciones se debe construir dentro de esta fase.

Se deben encontrar muchos defectos durante este período. Algunos se solucionarán de inmediato y deben validarse en la siguiente compilación diaria. Otros serán pospuestos en la siguiente milla o en el próximo lanzamiento.

Esta fase tomará alrededor del 50% - 60% del tiempo de sprint.

Al implementar la prueba Agile, mantenga su circuito de retroalimentación corto. Si encuentra un defecto, háblelo inmediatamente con los desarrolladores. Si necesita una aclaración sobre los requisitos, hable con el propietario del producto. Luego, adapta tu plan de prueba y prueba de inmediato.

88 3. Fase de verificación del sistema: Cuando se implementan la mayoría de las funciones, el sistema se integrará para la prueba. Como se mencionó anteriormente, es posible que solo le quede un 20% antes de tener que entregar software "funcional" en este momento.

El objetivo principal de esta fase es garantizar que el nuevo conjunto de funciones y todos los cambios más recientes no destruyan ni interrumpan el sistema de ninguna manera. Esto también incluye garantizar que el conjunto anterior de características funcione como debería con el sistema.

Además de esto, debe planificar el tiempo para la validación de defectos. Esto significa que no habrá recursos de repuesto para realizar más pruebas de características. Todo el resto de los recursos y el tiempo disponible deben colocarse en las pruebas de regresión.

Solo porque en Agile, todos se responsabilizan de conducir hacia un producto de alta calidad no significa que todos hagan todo. Todos tienen la tarea de hacer lo que mejor saben hacer, pero siempre son conscientes de lo que debe hacerse fuera de su propio rol.

4. Fase de aceptación: Una vez que finaliza la regresión (generalmente dirigida y no completa), el producto está casi listo para ser lanzado. La mayoría de los errores se corrigen durante las pruebas de regresión, el sistema se vuelve estable y se crea una versión candidata. Es necesario realizar una prueba de humo antes de la liberación para garantizar que todos los cambios realizados no afecten al sistema y confirmen que todos los errores críticos estén solucionados.

Si es posible, algunos recursos pueden asignarse a pruebas exploratorias para las características recientemente desarrolladas dentro de este sprint.

5. Retroalimentación, retrospectiva y cambio: Con respecto al plan de prueba, en cada retrospectiva, el siguiente plan de iteración debe adaptarse en términos de asignación de recursos y tiempo. Por ejemplo, si los desarrolladores dicen que las pruebas de unidad se están quedando atrás, es posible que el control de calidad deba trabajar directamente lado a lado y que los requisitos coincidan con las pruebas de unidad. O, si una determinada característica, función o historia del usuario tiene más problemas de los que debería, el control de calidad debe cambiar el enfoque con el objetivo de "software funcionando".

6. Deuda técnica: Muchos no planean deuda técnica. El hecho es que, si conduce más rápido, se abre más riesgos y se estrella. Agile, con un enfoque en la velocidad, también puede fallar si no planifica la calidad. Abordar la deuda técnica debe ser parte del plan. Lo que a menudo funciona mejor es dedicar periódicamente una iteración para eliminar la deuda. Esto viene en forma de código de documentación, corrigiendo los requisitos que fueron codificados de manera diferente, pero la

89 documentación está retrasada, corrigiendo scripts de automatización, refactorizando, optimizando tablas de bases de datos, etc.

7. Deslizamiento y escalonamiento: Cambiar la regresión a la mitad de un ciclo más tarde también puede aliviar la carga de la regresión sin mucha pérdida de velocidad. La mayoría de los equipos operan una forma híbrida de ágil mientras aún se mantienen principios ágiles centrados alrededor de la velocidad, la calidad y el software de trabajo que se entrega de manera incremental, de modo que se pueda proporcionar una retroalimentación rápida y cambiar la dirección, añadir requisitos y características de subcontratación si es necesario.

Como se mencionó, el rápido ritmo de las iteraciones y la integración continua a menudo lleva a un tiempo limitado para la regresión hacia el final de la iteración.

Para manejar esto, muchos equipos escalonan las pruebas de regresión y solo entregan una semana tarde.

Todavía está obteniendo software en funcionamiento en el intervalo predeterminado, pero no justo después de que se haya codificado, sino ½ una iteración más tarde.

8. Tiempo estimado: Es importante para las personas calcular horas reales y registrar horas reales. Cuando entre todos se trabaja y se hace un plan juntos, estiman la cantidad de trabajo necesario para hacer cada tarea y subtarea y asignan tareas a los individuos. Este es un componente crítico de la metodología ágil. Por un lado, no quieres un plan, por otro lado, aquí tienes una tarea y un cronograma, y una persona asignada. La diferencia es que este es un plan de iteración en lugar de un plan de proyecto. Estas estimaciones son críticas para el éxito del proyecto y la iteración

Desde un punto de vista de control de calidad, los testers deben incluir los tiempos de esfuerzos de prueba en el plan. Muy a menudo se pasa por alto y se agrega con un porcentaje aproximado o una asignación de unidades sin pensar realmente en la complejidad de las funciones que se están probando.

Hay que recordar que uno de los principios de ágil es la sostenibilidad. Si constantemente subestima el trabajo y luego trabaja horas extras, esto no es sostenible. Por lo tanto, tener mediciones para la estimación y la exactitud de la adherencia del calendario.

Conclusión Como hemos discutido, los proyectos tradicionales / en cascada generalmente dictan la necesidad de un documento detallado del plan de prueba porque desean establecer una visión muy clara del alcance, el método y las responsabilidades de la prueba al inicio de un proyecto. En un flujo de trabajo Agile, el proceso es incremental con la planificación de pruebas programada con cada

90 iteración de desarrollo. Con cada iteración (generalmente llamada Sprint en SCRUM), la planificación ayuda a los equipos a decidir el alcance y la metodología de la prueba mientras se adaptan a la situación de desarrollo actual. Algunas iteraciones pueden estar dedicadas a corregir defectos y realizar trabajos de repaso - refactorización, solo porque es necesario.

Por otro lado, puede haber un cambio en una característica o requisito importante, por lo que todos deben concentrarse en eso y hacerlo funcionar correctamente, por lo que quizás haya poco tiempo para una regresión y el desarrollo finalice en un 90% dentro del ciclo, por lo tanto, no tiene sentido planear varios meses de pruebas cuando todo lo que necesita hacer es probar 2 semanas a la vez. Por otro lado, tenemos que ser ágiles acerca de ágil. El hecho de que comencemos con iteraciones de 2 semanas, o iteraciones de 1 semana, no significa que tengamos que ceñirnos a eso o no somos "ágiles". Ágil significa iteraciones "cortas" y no hay una regla fija.

Por lo tanto, la necesidad de crear documentos formales del plan de prueba al inicio del proyecto se minimiza, y la prueba se adapta a la situación dada para la iteración actual, con una importancia creciente en esa calidad es responsabilidad de todos en el equipo. Los desarrolladores prestan atención a la calidad a través de la escritura de un buen código con pruebas unitarias, mientras que los gerentes de productos se enfocan en escribir historias de usuario claras que las personas puedan entender, y el control de calidad lo une todo al probar cada historia de usuario y desarrollar historias cruzadas para sistemas más grandes. Con todos enfocados en la calidad, eso no significa que todos hagan todo. Cada uno tiene especialidades en las que son expertos, y eso beneficia a todo el equipo.

Por último, la calidad es el objetivo, no la velocidad. Si se opta por la calidad, se obtendrá velocidad al reducir toneladas de retrabajo. Pero no funciona al revés. Dicho esto, es necesario eliminar todos los obstáculos para la calidad.

4.2 Métricas que se utilizarán dentro del Modelo de pruebas El objetivo primordial de la ingeniería del software es producir un sistema, aplicación o producto de alta calidad. Para lograr este objetivo, deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software. A continuación, se verá un conjunto de métricas del software que pueden emplearse a la valoración cuantitativa de la calidad de software de acuerdo con nuestra revisión:

1. Corrección: A un programa le corresponde operar correctamente o suministrará poco valor a sus usuarios. La corrección es el grado en el que el software lleva a cabo una función requerida. La medida más común de corrección son los defectos por KLDC, en donde un defecto se define como una falla verificada de conformidad con los requisitos. 2. Facilidad de mantenimiento. El mantenimiento del software cuenta con más esfuerzo que cualquier otra actividad de ingeniería del software. La facilidad de mantenimiento es la habilidad con la que se puede corregir un programa si se encuentra un error, se puede

91 adaptar si su entorno cambia o optimizar si el cliente desea un cambio de requisitos. No hay forma de medir directamente la facilidad de mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una métrica orientada al tiempo simple es el tiempo medio de cambio (TMC), es decir, el tiempo que se tarda en analizar la petición de cambio, en diseñar una modificación apropiada, en efectuar el cambio, en probarlo y en distribuir el cambio a todos los usuarios. En promedio, los programas que son más fáciles de mantener tendrán un TMC más bajo (para tipos equivalentes de cambios) que los programas que son más difíciles de mantener. 3. Integridad. En esta época de intrusos informáticos y de virus, la integridad del software ha llegado a tener mucha importancia. Este atributo mide la habilidad de un sistema para soportar ataques (tanto accidentales como intencionados) contra su seguridad. El ataque se puede ejecutar en cualquiera de los tres componentes del software, ya sea en los programas, datos o documentos. Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad. La amenaza es la probabilidad (que se logra evaluar o concluir de la evidencia empírica) de que un ataque de un tipo establecido ocurra en un tiempo establecido. La seguridad es la probabilidad (que se puede estimar o deducir de la evidencia empírica) de que se pueda repeler el ataque de un tipo establecido, en donde la integridad del sistema se puede especificar como:

Integridad = Ó[1- amenaza x (1- seguridad)] donde se suman la amenaza y la seguridad para cada tipo de ataque.

4. Facilidad de uso. El calificativo “amigable con el usuario” se ha transformado universalmente en disputas sobre productos de software. Si un programa no es “amigable con el usuario”, prácticamente está próximo al fracaso, incluso aunque las funciones que realice sean valiosas. La facilidad de uso es un intento de cuantificar “lo amigable que pude ser con el usuario” y se consigue medir en función de cuatro características: (1) destreza intelectual y/o física solicitada para aprender el sistema; (2) el tiempo requerido para alcanzar a ser moderadamente eficiente en el uso del sistema; (3) aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida cuando alguien emplea el sistema moderadamente y eficientemente, y (4) valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los usuarios hacia el sistema. 5. Eliminación de Defectos: Una métrica de la calidad que proporciona beneficios tanto a nivel del proyecto como del proceso, es la eficacia de la eliminación de defectos (EED) En particular el EED es una medida de la habilidad de filtrar las actividades de la garantía de calidad y de control al aplicarse a todas las actividades del marco de trabajo del proceso. Cuando se toma en consideración globalmente para un proyecto, EED se define de la forma siguiente: 92

EED = E / (E + D) donde E= es el número de errores encontrados antes de la entrega del software al usuario final y D= es el número de defectos encontrados después de la entrega. El valor ideal de EED es 1, donde simbolizando que no se han encontrado defectos en el software. De forma realista, D será mayor que cero, pero el valor de EED todavía se puede aproximar a 1 cuando E aumenta. En consecuencia, cuando E aumenta es probable que el valor final de D disminuya (los errores se filtran antes de que se conviertan en defectos) Si se utiliza como una métrica que suministra un indicador de la destreza de filtrar las actividades de la garantía de la calidad y el control, el EED alienta a que el equipo del proyecto de software instituya técnicas para encontrar los errores posibles antes de su entrega. 6. Funcionalidad. Se aprecia evaluando el conjunto de características y capacidades del programa, la generalidad de las funciones entregadas y la seguridad del sistema global. 7. -Usabilidad (facilidad de empleo o uso) Se valora considerando factores humanos, la estética, consistencia y documentación general. 8. -Fiabilidad. Se evalúa midiendo la frecuencia y gravedad de los fallos, la exactitud de las salidas (resultados), el tiempo medio entre fallos (TMEF), la capacidad de recuperación de un fallo y la capacidad de predicción del programa. 9. -Rendimiento. Se mide por la velocidad de procesamiento, el tiempo de respuesta, consumo de recursos, rendimiento efectivo total y eficacia

Para poder considerar un estándar en cada uno de los puntos y tomar las métricas de forma correcta es necesario evaluar la misma funcionalidad a través de la métrica de complejidad:

La métrica de complejidad más ampliamente usada para el software es la complejidad ciclomática, originalmente desarrollada por Thomas McCabe. La métrica de McCabe proporciona una medida cuantitativa para probar la dificultad y una indicación de la fiabilidad última. Estudios experimentales indican una fuerte correlación entre la métrica de McCabe y el número de errores que existen en el código fuente, así como el tiempo requerido para encontrar y corregir dichos errores también defiende que la complejidad ciclomática puede emplearse para proporcionar una indicación cuantitativa del tamaño máximo del módulo.

Derivado de las métricas mostradas y su forma de calcularlo este seria la propuesta de los indicadores vs los porcentajes del mercado:

93 Concepto % Metodología % Mercado Corrección 85% 70% Fiabilidad de 80% 65% mantenimiento Integridad 80% 79% Facilidad de uso 80% 75% Eliminación de Defectos 85% 70% Funcionalidad 80% 65% Usabilidad 80% 79% Fiabilidad 80% 75% Rendimiento 90% 89%

Figura 15. Métricas metodología vs métricas del mercado

Y si logramos implementarlos con base en sus premisas podremos lograr una metodología optima y eficiente.

4.3 Análisis Costo-Beneficio Es importante mencionar que dentro del esquema de pruebas propuesto se tienen pruebas automáticas y manuales. Cada una tiene un beneficio diferente y aunque las pruebas manuales tienen un mayor costo, es importante que estas se realicen, pero estén más centradas en el negocio y funcionalidad del sistema.

En cuestión de las pruebas automáticas mencionadas. Los beneficios más obvios de la automatización de pruebas están relacionados con la velocidad de las ejecuciones de prueba en comparación con las pruebas manuales. Se tarda mucho menos tiempo en ejecutar una prueba automáticamente que manualmente, y las fases de la prueba se pueden reducir considerablemente debido a la automatización.

Por lo tanto, uno puede ejecutar pruebas con más frecuencia (con más ciclos) y también en horarios fuera de la oficina.

Cuando las pruebas se ejecutan automáticamente, no hay necesidad de esfuerzo humano en la ejecución de las pruebas en lugar de las pruebas manuales.

Las pruebas también se pueden ejecutar en paralelo con diferentes computadoras, lo que permite la ejecución de muchas pruebas simultáneamente.

Los costos de construcción son los costos relacionados con el desarrollo real del software, como el análisis de requisitos, el diseño y la codificación del software.

La detección de defectos se refiere a actividades que tienen como objetivo encontrar defectos, es decir, análisis de causa raíz, pruebas e inspecciones / revisiones entre pares. Los costos de re

94 trabajo, es decir, los costos relacionados con la reparación de defectos, se dividen en tiempo previo y posterior al lanzamiento. Los costos de re trabajo antes de la liberación son reparaciones de los defectos encontrados en la fase de construcción, mientras que los costos de re trabajo posteriores a la liberación se deben a la reparación de los defectos encontrados por los clientes. Los costos posteriores al lanzamiento también incluyen nuevos costos de funciones y costos de funciones de soporte.

Figura 16. Punto de Equilibrio de las Pruebas Hall Richard .Software Engineering Testing.. Editorial. McConnell.

La automatización de pruebas en muchos casos está integrada con otros cambios y técnicas en el desarrollo del proceso de software en sí. Una técnica de diseño común asociada con la automatización de pruebas es el desarrollo dirigido por pruebas (TDD), donde los desarrolladores escriben las pruebas antes del código de producción.

La integración continua es una práctica a menudo asociada con la automatización de pruebas. Es "una práctica de desarrollo de software donde los miembros de un equipo integran su trabajo con frecuencia"

Es una práctica popular con métodos de desarrollo ágil, y la integración puede ocurrir varias veces al día, con la intención de reducir el tiempo empleado en la detección de defectos al encontrar problemas de manera temprana, enfatizando la importancia de la integración continua en el trabajo de desarrollo, al menos una vez al día y ejecutar todas las pruebas automatizadas durante la integración para que las pruebas sigan siendo relevantes y la capacidad para ejecutarlas permanezca en el equipo de desarrollo.

95 Los autores Thomas Stober y Uwe Hansmann sugieren que el entorno de prueba automatizado es necesario en el desarrollo de software ágil, porque los desarrolladores "necesitan poder obtener retroalimentación en tiempo real para cada cambio de código único de inmediato". También afirman que la automatización de todos los casos de prueba "es un factor clave para el éxito en la mejora de la productividad en un proyecto de desarrollo de software", porque la ejecución de casos de prueba manual varias veces, por ejemplo, al final de cada carrera o iteración es demasiado costosa, ya que Es una actividad que requiere mucha mano de obra en lugar de ejecutar pruebas automatizadas.

La implementación de nuevos procesos y herramientas en una organización genera costos iniciales, como la adquisición de herramientas y la capacitación, que generalmente son inversiones únicas y no necesariamente se pagan directamente durante el primer proyecto. La forma de trabajo modificada, lo que es más importante, podría cambiar los costos a largo plazo. Sin embargo, esos costos pueden ser difíciles de medir si los nuevos procesos no son solo actividades nuevas además de las más antiguas, sino sustitutos de otras actividades que actualmente se realizan en la organización.

Sin embargo, los costos de mantenimiento de la automatización de pruebas también son algo que se vuelven fácilmente incontrolables.

La automatización de pruebas requiere una alta capacidad de prueba del producto. La capacidad de prueba se realiza al hacer que el estado interno del software observable y el software bajo prueba sean controlables, lo que facilita el desarrollo del caso de prueba y la localización de defectos. La capacidad de prueba es un requisito no funcional de la automatización de pruebas que a menudo se olvida, y debe considerarse en la arquitectura del sistema desde el principio, ya que puede ser muy difícil después.

• La automatización de las pruebas que suelen llevar mucho tiempo de forma manual suele tener sentido, pero también podría llevar a las organizaciones a iniciar el trabajo de automatización al automatizar la prueba de las interfaces gráficas de usuario (GUI) existentes. • El beneficio de la automatización de pruebas se pierde si las pruebas automatizadas no están diseñadas para ser mantenibles y deben ser reescritas constantemente, por lo que el diseño de una biblioteca de pruebas que admita la capacidad de mantenimiento de las pruebas durante toda la vida de la aplicación es esencial en el éxito del uso de la automatización de pruebas. • La práctica de probar mientras los desarrolladores escriben el código conducirá a una mejor calidad del código, porque cuando uno piensa en cómo se debe probar el código, uno sabe mejor cómo debería funcionar el código. Cuando se rompe la funcionalidad y se debe hacer una corrección, lleva tiempo averiguar cómo funcionó el código y las correcciones pueden no ser lo suficientemente completas debido a una falta de comprensión del código. 96 4.4 Punto de Equilibrio El punto de equilibrio nos permite medir no solo una relación entre ingresos y costos, sino que tiene otras aplicaciones para la toma de decisiones como por ejemplo la conveniencia de contratar un servicio o no hacerlo. En este caso el modelo de pruebas y calidad de software.

Figura 17. Punto de Equilibrio Bravo Carrasco Juan. (2016). Gestión de Procesos. Editorial. Evolución.

Esta gráfica es sumamente útil para cuantificar el volumen mínimo requerido, y alcanzar un nivel de rentabilidad (utilidad) deseado. Aquí se aprecia que con el empleo del modelo de pruebas y calidad de software nuevo el área de Informática tiende a tener utilidades por encima de los niveles de esfuerzo y volumen de producción representados por el punto de equilibrio. De acuerdo con los resultados obtenidos el área operará con rendimientos excelentes.

Los beneficios de aplicar este nuevo modelo de pruebas se verán reflejados al cumplirse dos meses y en adelante. El total de recursos (mencionados a continuación) necesarios se recuperarán al término del quinto mes.

A pesar de que se demuestra que la inversión puede recuperarse a partir de este punto el análisis en cinco meses revela que los beneficios obtenidos serán significativamente mayores que los costos incurridos. Como se ve en la gráfica el punto de equilibrio se alcanza en un tiempo estimado de dos meses, lo que garantiza que no habrá variación significativa en la operación financiera de la empresa ni siquiera en los primeros meses.

Es necesario observar de todas maneras que el análisis de beneficios se basa en los criterios subjetivos del gerente del área, que aunque se apoyan en datos y cifras reales pueden tener un

97 pequeño margen de error en la estimación. Sin embargo, de forma general puede asegurarse que la inversión traerá más beneficios que los costos que representa.

4.5 Aplicación del modelo de pruebas En una metodología ágil, donde trabajamos en sprints cortos o iteraciones, cada sprint se enfoca solo en unos pocos requisitos o historias de usuarios, por lo que es natural que la documentación no sea tan extensa, tanto en términos de número como de contenido.

No necesitaremos tener un plan de prueba extenso en proyectos ágiles para cada sprint debido a limitaciones de tiempo, pero sí requerimos una estrategia de prueba ágil de alto nivel como guía para los equipos ágiles.

Enumeraremos las mejores prácticas y alguna forma de estructura que los equipos puedan seguir. Hay que recordad que ágil no significa desestructurado ni que sea más rápido.

Una estrategia de prueba generalmente tiene una declaración de misión que podría estar relacionada con los objetivos y metas de negocios más amplios.

Una declaración de misión típica podría ser:

Para entregar constantemente un software de trabajo que cumpla con los requisitos del cliente mediante el suministro rápido de comentarios y la prevención de defectos, en lugar de la detección de defectos.

Apoyado por:

No se puede escribir ningún código para una historia hasta que primero definamos sus criterios / pruebas de aceptación.

Una historia puede no ser considerada completa hasta que todas sus pruebas de aceptación pasen.

Hay que recordar que el control de calidad es un conjunto de actividades destinadas a garantizar que los productos satisfagan los requisitos del cliente de manera sistemática y confiable.

En SCRUM (ágil), el control de calidad es responsabilidad de todos, no solo de los testers. El control de calidad es todas las actividades que realizamos para garantizar la calidad correcta durante el desarrollo de nuevos productos.

Figura 18. Cuadrantes de Agile Bravo Carrasco Juan. (2016). Gestión de Procesos. Editorial. Evolución.

4.5.1 Pruebas Unitarias.

La calidad del código es uno de los aspectos más importantes, si no el más importante, dentro del ciclo de desarrollo de software. Una de las herramientas de las que se apoya el aseguramiento de la calidad son las pruebas sobre el componente desarrollado. Hay diferentes tipos de pruebas, de acuerdo a la fase de desarrollo de software. En la fase de construcción o implementación se encuentran las pruebas unitarias.

Una prueba unitaria es un mecanismo que comprueba el correcto funcionamiento de una unidad de código, incluso antes de que esta unidad sea integrada con otros componentes. Una prueba unitaria debe ser:

• Automatizable

• Completa

• Repetible

• Independiente

• Profesional

Con las pruebas unitarias se logra ejercitar el código, asegurar el correcto funcionamiento de la unidad, proteger esa unidad de código ante modificaciones posteriores; en caso de corrección de un defecto, probar la corrección si cambiar la versión que está corriendo en ambientes productivos. Además, reduce la posibilidad de inyectar defectos en un mantenimiento del código y simplifica la integración. 99 El análisis de código estático se refiere a aquel análisis que se hace sobre el código de acuerdo a ciertos patrones que potencialmente representan defectos. Diferentes herramientas analizan diferentes patrones.

Por ejemplo, para código Java las tres principales herramientas son: 1) PMD, 2) Checkstyle y 3) Findbugs. Código duplicado, no utilizado, complejidad ciclomática, modificadores de acceso incorrectos a clases son algunos ejemplos de los errores/defectos detectados con estas herramientas.

La política para que los desarrollar el proyecto sería la siguiente:

1. El desarrollador, de acuerdo con el proceso de GitFlow aplicable, diseña las pruebas unitarias que cubran los resultados esperados por su implementación.

2. El desarrollador, construye las pruebas unitarias.

3. El desarrollador, ejecuta las pruebas unitarias.

4. Si hay errores, el desarrollador hace los ajustes a las pruebas y/o al código sujeto de prueba y repite el paso 3

5. El desarrollador comprueba que se cumple con el porcentaje de cobertura de pruebas unitarias, por ahora se comenzara el porcentaje en 70%.

6. Si no se cumple con el porcentaje de cobertura establecido, el desarrollador implementa más escenarios de pruebas y regresa al paso 3

7. Si se cumple con el porcentaje de cobertura establecido, el desarrollador comprueba que no se hayan inyectado más defectos en la aplicación a raíz de sus cambios.

8. Si no se inyectaron defectos desde la última versión válida o existen menos, el desarrollador integra sus cambios de acuerdo al GitFlow

9. Si el código que se solicita integrar es aprobado por los revisores, el proceso de integración continua (CI) del server dispara la ejecución automática de pruebas unitarias y revisión de código en el ambiente de desarrollo.

10. Si las reglas de cobertura y análisis de código estático no se cumplen en el CI server, la construcción y despliegue automático en el ambiente de desarrollo se detiene

11. El responsable técnico del equipo informa al desarrollador de los errores

12. El desarrollador puede:

a. Subir el código antes de su integración por cuestión de dependencia de otras aplicaciones con el ambiente de desarrollo

b. Corregir el código que provocó las fallas

13. El desarrollador inicia el flujo nuevamente.

14. Si las reglas de cobertura y análisis de código estático se cumplen en el CI server, el

100 componente es construido y desplegado en el ambiente de desarrollo. 4.5.2. Versionamiento

Marco conceptual

Control de versiones es un (VCS) sistema que registra los cambios hechos a un archivo o conjunto de archivos a través del tiempo, de tal manera que puedan restaurarse en un punto posterior en una versión específica. Esto puede hacerse sobre cualquier tipo de archivo en una computadora.

Una de las herramientas más populares de versionamiento, si no la más popular, es git. Git es un sistema de control de versiones libre y de código abierto diseñado para manejar proyectos desde los más pequeños hasta los más complejos, veloz y eficazmente.

Casi todos los CVSs tienen algún tipo de soporte de ramificación (branching). Branching significa que un desarrollador se separa de la línea principal de desarrollo y continúa su trabajo sin ensuciar la línea principal. Aprovechando el soporte de branching en git, existe un modelo llamado GitFlow.

GitFlow es un modelo de branching creado por Vincent Driessen. Este modelo ha logrado llamar la atención porque se adapta perfectamente para la colaboración de un equipo sobre un proyecto de código, manteniendo el orden y escalando el equipo de desarrollo. Dependiendo de las características del componente a desarrollar, el branching surge y regresa a determinadas ramas. 4.5.3. Integración Continua

La Integración Continua es una práctica de desarrollo de software en la que los miembros de un equipo integran su trabajo frecuentemente - normalmente cada persona los integra diariamente - permitiendo múltiples integraciones por día. Cada integración es verificada por un proceso de construcción automática (que incluye pruebas) para detectar errores de integración tan pronto como sea posible. Muchos equipos concluyen que este enfoque de integración propicia la reducción de problemas de integración de manera significativa y permitiendo a los equipos desarrollar software cohesivo más rápido.

Martin Fowler 2006

Integración Continua (CI), como la define Martin Fowler, es el proceso en el cual los desarrolladores en un equipo integran su trabajo (cambios al código) de forma continua.

CI, como herramienta de aseguramiento de la calidad y seguridad del código, va más allá del simple hecho de integrar funcionalidad al VCS. Dentro de las otras consideraciones a tomar en cuenta para ejecutar correctamente el flujo de CI son las siguientes:

Pruebas unitarias (Pruebas Unitarias (UT) y Análisis de Código Estático (SAST)).- Implica que el código debe estar probado para: 1) asegurar que la funcionalidad está cubierta, y 2) para funcionar como pruebas de regresión cuando se agregue funcionalidad en un futuro. Todo el nuevo código debe tener al menos un 80% de cobertura en UT.

Estas pruebas deben implementarse de tal forma que su ejecución sea de forma automática en

101 tiempo de construcción del componente al que pertenece. Además, es responsabilidad del desarrollador encargado del nuevo código, asegurar que tanto sus pruebas unitarias como las existentes pasen satisfactoriamente.

• GitFlow. El orden en el cual se implementan las nuevas características, correcciones, adecuaciones y demás de un componente, debe apegarse al modelo de branching llamado GitFlow. Es responsabilidad del desarrollador partir de la rama correcta cuando inicie y regresar a la(s) rama correcta cuando termine a fin de mantener el orden y disparar la construcción y despliegue automáticos de los componentes.

• Análisis de código estático. Uno de los objetivos en aseguramiento de código es evitar propagar defectos desde entornos de desarrollo hacia el ambiente de producción. Una estrategia que contribuye a lograrlo es analizar el código con herramientas de SAST. Las tres más populares son: 1) findbugs, 2) checkstyle y 3) PMD y cada una identifica un tipo específico de defectos. Es responsabilidad del desarrollador ejecutar el análisis de su código y, en caso de encontrar defectos con estas herramientas, corregirlos antes de hacer cualquier intento de integración de código al flujo de CI. Además del desarrollador, debe existir en el flujo de CI (específicamente en el CI server) la configuración de una tarea que automatice este análisis y que rompa el flujo de construcción del componente en caso de detectar defectos clasificados de código estático. Existen herramientas que informan al equipo de desarrollo los resultados del análisis de tal manera que puedan asignarse los defectos y solucionarlos. Si el código no cumple con las métricas de análisis, entonces no puede integrarse.

• Documentación de código.- Para facilitar el entendimiento de los componentes desarrollados, es importante que aquellos cuya complejidad lo requiera, exponga documentación explicando su funcionamiento, parámetros de entrada y resultados. Es importante mencionar que en principio, el código debe estar desarrollado de tal forma que se vea autodocumentado cuando se lee. De igual manera, se considera innecesario documentar el código que es explícito por sí mismo.

• Convenciones y estilos de codificación.- Dentro de una organización, existen diferentes equipos con diferentes tipos de desarrolladores. También, en una organización se programa con diferentes lenguajes de acuerdo a las necesidades que deben cubrirse. Si cada desarrollador utiliza un lenguaje diferente y aún más con ese lenguaje programa de una forma diferente, cuando otro desarrollador tenga que mantener ese código primero tiene que lidiar con entender el código para después implementar el mantenimiento. Es por eso que dentro de CI se recomienda el apego a convenciones y estilos de codificación para permitir que cualquier desarrollador entienda lo que el otro quiso expresar en su código y aumentar así el tiempo dedicado a la funcionalidad por la cual abrió el código.

102

4.5.4. Criterios de aceptación. Dentro de SCRUM, los criterios de aceptación definen los requisitos sobre cómo debe comportarse la aplicación para que una determinada acción se pueda llevar a cabo, normalmente por parte de un usuario de la aplicación. Por lo que son esencialmente las pruebas manuales que se tienen que hacer sobre el negocio con el que debe cumplir un producto. Generalmente ayudan al equipo de desarrollo a responder a las preguntas: ¿He construido el producto correcto? ¿He construido el producto correctamente? Los criterios de aceptación deben describir siempre un contexto, un evento y la respuesta o consecuencia esperada del sistema. La forma más utilizada para describir los criterios de aceptación es conocida como Given-When-Then. Aquí un ejemplo: Dado un usuario que aún no se ha identificado en el sistema Cuando intenta acceder a alguna funcionalidad de la parte privada Entonces se le redirige automáticamente a la página de login para que pueda identificarse Aunque describen comportamiento de la aplicación, se utiliza siempre un lenguaje de negocio, no técnico. En el ejemplo anterior usamos “cuando intenta acceder a alguna funcionalidad de la parte privada” y no “cuando hace clic en alguna opción de menú que requiere sesión”. Precisión de los criterios de aceptación Una pregunta frecuente es ¿hasta qué punto tengo que ser preciso y extenso en esta definición? ¿Tengo que poner todos y cada uno de los casos? La respuesta es depende. Depende de la madurez y la experiencia del equipo de desarrollo, y también de su potestad y libertad a la hora de participar en la definición del producto. En un entorno donde el equipo es inexperto o bien negocio espera algo muy concreto y controlado, donde en la demo se revisan textos, tenemos que cumplir con una normativa muy restrictiva, etc. necesitaremos unos criterios de aceptación muy concretos y precisos. Si por el contrario el equipo resuelve con efectividad estos pequeños detalles, los criterios de aceptación serán el inicio de las conversaciones y no el final. 4.5.5. Developer Testing

El desarrollador, debe comportarse como si no tuviera ningún control de calidad en el equipo u organización. Es cierto que los controles de calidad tienen una mentalidad diferente, pero debes probarlos lo mejor que puedas.

Piensa que está ahorrando tiempo al pasar rápidamente a la siguiente historia, pero en realidad, cuando se encuentra e informa un defecto, se tarda más en corregir el problema que en dedicar unos minutos a asegurarse de que la función funcione bien.

Cualquier código nuevo y / o refactorización del código heredado debe tener pruebas de unidad apropiadas que formarán parte de la prueba de regresión de la unidad.

103 Pruebas automatizadas de aceptación y pruebas no funcionales.

Las pruebas de aceptación automatizadas incluyen Pruebas de integración y Pruebas de servicio y Pruebas de interfaz de usuario que pretenden probar que el software funciona a un nivel funcional y que cumple con los requisitos y especificaciones del usuario.

Debido a que estas pruebas generalmente requieren comunicación a través de HTTP, deben ejecutarse en una aplicación implementada, en lugar de ejecutarse como parte de la compilación.

Las pruebas no funcionales (Rendimiento y seguridad) son tan importantes como las pruebas funcionales, por lo que deben ejecutarse en cada implementación.

Las pruebas de rendimiento deben verificar las métricas de rendimiento en cada implementación para garantizar que no haya degradación del rendimiento.

Es vital que este sea un proceso completamente automatizado con muy poco mantenimiento para obtener el mayor beneficio de las implementaciones automatizadas. Esto significa que no debe haber fallas de prueba intermitentes, problemas de secuencia de comandos de prueba y entorno roto.

Las fallas solo deben ser debidas a defectos de código genuino en lugar de problemas de script, por lo tanto, cualquier prueba fallida que no se deba a fallas genuinas debe solucionarse de inmediato o eliminarse del paquete de automatización, para poder obtener resultados consistentes. 4.5.6. Pruebas de regresión

No se espera encontrar muchos defectos aquí. Su propósito es solo proporcionar comentarios que no hemos roto la funcionalidad principal. Debe haber una cantidad muy pequeña de pruebas de regresión manual.

Se llaman pruebas de paquete de humo - No debe ser más de 15 minutos

Este paquete solo contiene funcionalidad de alto nivel para garantizar que la aplicación sea lo suficientemente estable como para un mayor desarrollo o prueba.

Por ejemplo, para un sitio web de comercio electrónico, las pruebas incluidas en este paquete podrían ser:

• Búsqueda de Producto,

• Revisión de producto

• Adquirir artículo

• Creación de cuenta / Inicio de sesión de cuenta

104 Paquete de regresión completa - no debe ser más de 1 hora

Este paquete contiene el conjunto completo de pruebas de regresión y contiene todo lo demás que no está incluido en el paquete de humo.

Aquí, el objetivo es obtener una respuesta rápida con un conjunto más amplio de pruebas. Si la retroalimentación toma más de 1 hora, no es rápida. Reduzca el número de pruebas utilizando la técnica de prueba por pares, cree paquetes de prueba basados en el riesgo o ejecute las pruebas en paralelo. 4.5.7. Pruebas nexploratorias

No hay ninguna razón por la que UAT y las pruebas exploratorias no puedan ejecutarse en paralelo con las pruebas de aceptación automatizadas. Después de todo, son actividades diferentes y tienen como objetivo encontrar diferentes temas. El objetivo de UAT es garantizar que las características desarrolladas tengan sentido comercial y sean útiles para los clientes.

El PO (Product Owner) debe ejecutar Pruebas de aceptación del usuario o Pruebas de aceptación comercial para confirmar que el producto creado es lo que se esperaba y que cumple con las expectativas del usuario.

Las pruebas exploratorias deben centrarse en los escenarios de los usuarios y deben encontrar errores que la automatización no detecte. Las pruebas exploratorias no deben encontrar errores triviales, sino que deben encontrar problemas sutiles. 4.5.8. Criterios hechos

Una vez que se hayan completado todas las actividades anteriores y no se hayan encontrado problemas, ¡la historia está lista!

Las anteriores son algunas pautas sobre lo que se puede incluir en un Documento de Estrategia de Prueba Agile. Obviamente, esto debe adaptarse a las necesidades de su organización, pero es de esperar que esta plantilla lo ayude a crear su propio documento de Estrategia de prueba Agile. 4.6 Demostración de la hipótesis Empezamos definiendo que es óptimo y eficientes aplicado dentro de nuestro proceso: Optimo: es el superlativo de bueno, es decir, generalmente, la palabra se emplea a instancias de alguna actividad que se desarrolló y cuyos resultados fueron muy beneficiosos. La eficiencia, está vinculada a utilizar los medios disponibles de manera racional para llegar a una meta. Por lo tanto, consideramos que la aplicación de las métricas en forma correcta permite tener actividades optimas en nuestro proceso de pruebas, utilizando la eficiencias de las herramientas tecnológicas y de los recursos necesarios para complementar cada una de nuestras fases.

Con base en los puntos anteriores, se confirma que la labor de desarrollar software en una empresa (en este caso como herramienta interna) conlleva la necesidad de asegurar que el

105 trabajo realizado se acerca (en medida de lo posible) a la perfección en cuanto calidad y desarrollo seguro. Evidentemente, esto redunda en la satisfacción del equipo de trabajo que logra los objetivos, así como por parte del usuario quién obtiene el mayor beneficio de un producto útil finalizado. Se concluye también que es altamente factible establecer el modelo de pruebas y calidad de software dentro del área de Informática de la empresa Seguros Atlas S.A., derivado de los resultados arrojados en el análisis costo beneficio. El haber desarrollado este modelo de pruebas y calidad de software, permitió que las pruebas se realizaran de manera integral y concisa, dando como resultado una mejora visible en el nivel de calidad del sistema y se optimizaron también los tiempos de entrega. La reacción del usuario final fue de satisfacción total, ya que el sistema cumple al 100% las expectativas deseadas en cuanto a funcionalidad de cada uno de los módulos del sistema, la facilidad de uso, los resultados obtenidos de las consultas y reportes; y en la parte visual del sistema. En síntesis, la realización de este estudio coincidió con la estimación inicial calculada, ya que no hubo obstáculos mayores.

En la propuesta de incluir un testeo cruzado se necesita de fondo el cambio de cultura en la forma de trabajo de los integrantes del área y adoptar metodologías de desarrollo ágiles. No es una tarea fácil ya que los seres humanos la mayoría de las veces le tenemos miedo a los cambios o a lo desconocido. Pero es un riesgo que bien vale la pena tomar ya que traerá muchas satisfacciones y resultados, ¿Cómo lograrlo? con disposición y compromiso por parte de los desarrolladores. Los tiempos de entrega para la realización de pruebas con el usuario, y para la entrega final del producto fueron reducidos y optimizados visiblemente, es decir, no se desperdiciaron recursos para lograrlo. El tiempo total desde que se recibió el requerimiento hasta la entrega en Producción fue de 2 meses.

Conclusiones Con base a esta investigación se menciona las siguientes conclusiones: Debido a que la tecnología se encuentra actualmente en todos los ámbitos del campo laboral, prueba importante para ello es el trabajar con sistemas de información funcionales, prácticos y confiables que apoyen en la buena operación de las compañías.

Como se mostró a lo largo de este proyecto la calidad de software es un tema de suma importancia que ninguna empresa puede pasar por alto, justo hoy que vivimos en un mundo globalizado altamente competitivo. En mi particular punto de vista en este proyecto se relacionó ampliamente los temas vistos en clase a lo largo de la carrera de Ciencias de la Informática, en materias como Ingeniería de Software, Estructura de Datos, Calidad, Programación I, Formulación de Proyectos, Habilidades

106 Gerenciales.

De forma personal, la calidad de software es más que una etapa dentro del ciclo de vida del software. Es un paso primordial que debe de estar presente dentro de cada etapa, es decir, cada nivel del ciclo desde la definición de un requerimiento hasta el mantenimiento, cada una de estas etapas debe realizarse con calidad, ya que de cada una de ellas dependerá la entrega de un producto de software que cubra y satisfaga al máximo las necesidades y exigencias del usuario. El aseguramiento de calidad hace que todo lo creado tenga sentido, pero no se puede asegurar la calidad sino existen controles adecuados para cada proceso, es importante definir éstos controles de acuerdo a lo que se expuso para luego infundir una cultura de calidad en los que conforman el equipo de Informática de la empresa Seguros Atlas. El beneficio que trae la calidad total al departamento es muy grande, ya que los usuarios lo perciben y se genera la confianza que todo desarrollador de software necesita. A través de la credibilidad que el usuario tenga en nuestro trabajo es como la empresa va creciendo. De igual forma, se concluye que una de las etapas fundamentales dentro del ciclo de vida (aunque muchas veces no se le otorgue la importancia necesaria) es la etapa de pruebas de software. En ella se fomenta la detección de posibles errores pasando por el proceso de corregirlos para que una vez liberado el sistema éste funcione en su totalidad de acuerdo con las necesidades iniciales. Esta investigación permitió optimizar el proceso de pruebas de software a través de un modelo que resultó en gran medida funcional. Fue aplicada a algunos proyectos y los resultados fueron satisfactorios, por lo que concluyo que sí se cumple la hipótesis mencionada.

Referencia Libros

• Black Rex (2011). Fundamentos de Pruebas de Software. Editorial. RBCS, Inc. • Bravo Carrasco Juan. (2016). Reingeniería de Negocio. Editorial. Sol. • Bravo Carrasco Juan. (2016). Gestión de Procesos. Editorial. Evolución. • Carretero Arriba Alberto (2015).Pruebas de funcionalidad y optimización de páginas Web. Editorial. IC Editorial. • Fernandez Diaz Raymundo (2014). Procesos y gestión de mantenimiento y calidad. Editorial. Marcombo. • Hall Richard .Software Engineering Testing.. Editorial. McConnell. • Henry J Johansson (1993). Reingeniería de Proceso de Negocios. Editorial. Limusa. • Porter Michael (2001). Estrategia Competitiva, Técnicas para el Análisis de las Empresa y sus Competidores. Editorial. Cecsa.

107 • Sanz Esteban Ana (2012). Un proceso de pruebas eficiente. Editorial. EAE Editorial Academia Española

Glosario Algoritmo: Conjunto de sentencias o instrucciones en lenguaje nativo, los cuales expresan la lógica de un programa. Ambiente: Entorno que permite interactuar con todos los elementos del programa. Analista de sistemas: Es un profesional especializado del área de la informática, encargado del desarrollo de aplicaciones en lo que respecta a su diseño y obtención de los algoritmos, así como de analizar las posibles utilidades y modificaciones necesarias de los sistemas operativos. Aplicación: Es un tipo de programa informático diseñado como herramienta para permitir a un usuario realizar un o diversos tipos de trabajo. Archivo: Conjunto de bits que son almacenados en un dispositivo. Un archivo es identificado por un nombre y la descripción de la carpeta o directorio que lo contiene. Ciclo: Es una sentencia que se realiza repetidas veces a un trozo aislado de código, hasta que la condición asignada a dicho bucle deje de cumplirse. Código duro: Mala práctica en el desarrollo de software que consiste en incrustar datos directamente en el código fuente del programa, en lugar de obtenerlos de una fuente externa como parámetros. Código fuente: Texto escrito en un lenguaje de programación que ha de ser compilado o interpretado para ejecutarse en una computadora. Compilador: Es un programa informático que traduce un programa escrito en un lenguaje de programación a otro lenguaje de programación. Componente de software: Parte modular de un sistema software. Contador: Variable incremental de tipo numérico que sirve para saber el total de registros. Caso de prueba: conjunto de condiciones o variables bajo las cuáles un analista determinará si una aplicación o un sistema software es parcial o completamente satisfactoria. Dato: Es el término que usamos para describir las señales con las cuales trabaja la computadora es dato; Aunque las palabras dato e información muchas veces son usadas indistintamente, si existe una diferencia importante entre ellas. Desarrollador: Profesional experto en parte o en la totalidad de software, tal como el sistema operativo, redes, sistema de administración de base de datos. Diagrama de flujo: Representación gráfica de una secuencia de instrucciones de un programa que ejecuta un computador para obtener un resultado determinado. Espiral: Es una línea curva generada por un punto que se va alejando progresivamente del centro a la vez que gira alrededor de él. Función: Grupo de instrucciones con un objetivo en particular y que se ejecuta al ser llamada desde otra función o procedimiento. Una función puede llamarse múltiples veces e incluso

108 llamarse a sí misma (función recurrente). Información: Es lo que se obtiene del procesamiento de datos, es el resultado final. Informática: Ciencia que estudia métodos, técnicas, procesos, con el fin de almacenar, procesar y transmitir información y datos en formato digital. Instrucción o sentencia: Conjunto de caracteres que se utilizan para dirigir un sistema de procesamiento de datos en la ejecución de una operación. Interfaz: Una conexión e interacción entre hardware, software y usuario, es decir como la plataforma o medio de comunicación entre usuario o programa. Iteración: Significa el acto de repetir un proceso con el objetivo de alcanzar una meta deseada, objetivo o resultado. Cada repetición del proceso también se le denomina una "iteración", y los resultados de una iteración se utilizan como punto de partida para la siguiente iteración. Layout: Es el proceso de calcular la posición de objetos en el espacio sujeto a varias coacciones. Esta funcionalidad puede ser la parte de un uso o como un componente reutilizable o la biblioteca. Lenguaje de programación: Es un lenguaje formal diseñado para expresar procesos que pueden ser llevados a cabo por máquinas como las computadoras. Lógica de software: O lógica del programa, es el método o razonamiento en el que las ideas o la sucesión de los hechos se manifiestan o se desarrollan de forma coherente y sin que haya contradicciones entre ellas. Memoria: Dispositivo de una máquina donde se almacenan datos o instrucciones que posteriormente se pueden utilizar. Paradigma: Esta palabra se usa para denominar elementos que siguen algún diseño o modelo. Parámetro: Es una constante o una variable que aparece en una expresión matemática y cuyos distintos valores dan lugar a distintos casos en un problema. Procedimiento almacenado: (Stored Procedure en Inglés) es un programa almacenado físicamente en una base de datos. Su implementación varía de un gestor de bases de datos a otro. Proceso: Conjunto de actividades mutuamente relacionadas o que al interactuar juntas en los elementos de entrada los convierten en resultados. Programa: Colección de instrucciones que indican a la computadora que debe hacer. Un programa se denomina software, por lo tanto, programa, software e instrucción son sinónimos. PSP: (Personal Software Process en inglés); es un proceso de desarrollo de software en forma Personal) es un esquema de trabajo definido y medible que ayuda a los desarrolladores en la planificación y la medición de su trabajo, generando productos de alta calidad. Red: Conjunto de medios (transmisión y conmutación), tecnologías, protocolos y facilidades en general, necesarios para el intercambio de información entre los usuarios de la red. Registro: Grupo de campos relacionados que se usan para almacenar datos implícitamente estructurados en una tabla. RUP: (Rational Unified Process en Inglés), es un proceso de desarrollo de software y que en 109 conjunto con el lenguaje unificado UML, constituye la metodología más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Rutina: Es el conjunto de instrucciones dentro del mismo programa, que se puede llamar a ejecución desde diferentes partes del mismo programa. Servidor: Es una aplicación en ejecución (software) capaz de atender las peticiones de un cliente y devolverle una respuesta. Los servidores se pueden ejecutar en cualquier tipo de computadora. Sistema operativo: Conjunto de órdenes y programas que controlan los procesos básicos de una computadora y permiten el funcionamiento de otros programas. Sistemas de información: Conjunto de elementos orientados al tratamiento y administración de datos e información, organizados generados para cubrir una necesidad o un objetivo. Software: Conjunto de programas, documentos, procesamientos y rutinas asociadas con la operación de un sistema de computadoras, es decir, la parte intangible de computador. Usuario: Cualquier individuo que interactúa con la computadora a nivel de aplicación. Variable: Estructura que contiene datos y recibe un nombre único, mantiene los datos asignados a ella hasta que un nuevo valor se le asigne o hasta que el programa termine.

110