P A O L A T O V A R H E R N Á N D E“N DE UNA... · mencionar algunos: sistemas de información,...

1

T E S I N A

Q U E P A R A O B T E N E R E L T Í T U L O D E

L I C E N C I A D O E N C I E N C I A S D E L A I N F O R M A T I C A

P R E S E N T A N

D A V I D F L O R E S M E N D O Z A

P A O L A T O V A R H E R N Á N D E Z

Q U E P A R A O B T E N E R E L T Í T U L O D E

L I C E N C I A D O E N A D M I N I S T R A C I Ó N I N D U S T R I A L

P R E S E N T A

I R V I N E D U A R D O M A R T E L L J I M E N E Z

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

SEMINARIO GESTIÓN E INTELIGENCIA DE NEGOCIOS

“CREACIÓN DE UNA METODOLOGÍA ÓPTIMA Y EFICIENTE PARA LA

IMPLEMENTACIÓN DE PRUEBAS DE SOFTWARE.”

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

I

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.

II

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.

1

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.

2

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)

3

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.

4

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.

5

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

6

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

7

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.

8

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.

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.

9

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.

10

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


11

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”,

12

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


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

13

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

14

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

15

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


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

16

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.

17

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.

18

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.

19

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.

20

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

21

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.

22

• 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).

23

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

24

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:

25

• 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.

26

• 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

27

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.

28

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

29

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.

30

• 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.

31

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.

32

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.

33

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.

34

• 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.

35

• 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:

36

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.

37

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.

38

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.

39

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:

40

• 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.

41

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.

42

• 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:

43

• 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.

44

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.


• 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

45

cumplimiento de la experiencia del usuario final y el acuerdo de nivel de servicio (SLA) en entornos

de producción.


• 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.


• 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.

46

• 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.

47

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

48

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.

https://es.wikipedia.org/wiki/Pruebas_de_regresi%C3%B3n

49

.Jm

eter

Jsys

tem

Sele

niu

mH

P L

oad

Ru

nn

erN

eo L

oad

We

b L

oad

Pru

ebas

de

carg

a✔

✔✔

✔

Pru

ebas

de

estr

és✔

✔✔

✔

Pru

ebas

dis

trib

uid

as✔

Perm

ite

crea

r sc

rip

ts d

e p

rueb

a✔

✔✔

✔✔

✔

Gra

ba

y re

pro

du

ce g

uio

nes

de

pru

eba

✔✔

✔✔

✔✔

Cre

ació

n d

e es

cen

ario

s✔

✔✔

✔✔

✔

Inte

grac

ión

co

n o

tras

her

ram

ien

tas

✔✔

✔

Gra

tuit

a✔

✔✔

Do

cum

enta

ció

n✔

✔✔

✔✔

✔

Mo

nit

ore

o d

e b

ase

de

dat

os

✔✔

✔✔

Med

ició

n d

e p

etic

ion

es p

or

un

idad

de

tiem

po

✔✔

✔

Cre

ació

n d

e u

suar

ios

virt

ual

es✔

✔✔

✔✔

✔

Det

erm

ina

el n

úm

ero

máx

imo

y m

ínim

o d

e u

suar

ios

con

curr

ente

s✔

✔✔

✔

Mo

nit

ore

a el

trá

fico

de

la r

ed✔

✔✔

✔

Inte

grac

ión

co

n d

ifer

ente

s le

ngu

ajes

de

pro

gram

ació

n✔

✔✔

✔

Pru

ebas

en

dis

po

siti

vos

mó

vile

s✔

✔✔

Co

mp

atib

ilid

ad c

on

dif

eren

tes

pro

toco

los

de

com

un

icac

ión

✔✔

✔

Mu

ltip

lata

form

a✔

✔✔

✔✔

✔

Cre

ació

n d

e in

form

es✔

✔✔

✔

Det

ecta

r cu

ello

s d

e b

ote

lla✔

✔✔

✔

Co

mp

atib

ilid

ad c

on

dif

eren

tes

serv

ido

res

✔✔

✔✔

Co

mp

atib

ilid

ad c

on

dif

eren

tes

nav

egad

ore

s✔

✔✔

✔✔

Med

ició

n d

e co

nsu

mo

de

mem

ori

a d

el s

ervi

do

r✔

✔✔

✔

Fig

ura

8. T

abla

com

para

tiva d

e h

err

am

ienta

s d

e p

rue

bas d

e s

oftw

are

y s

us

cara

cte

rísticas

Sanz E

ste

ban A

na (

2012).

Un p

roceso d

e p

rueb

as e

ficie

nte

. E

ditori

al. E

AE

Editori

al A

cad

em

ia E

spañ

ola

50

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

51

• 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.

52

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.

53

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.

54

• 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.

55

• 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

56

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

57

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é.

58

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.

59

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

60

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.

61

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:

62

• 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.

63

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

64

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.

65

• 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.

66

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

67

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

68

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.

69

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.

70

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.

71

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.

72

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.

73

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


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:

74

• 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

75

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.

76

• 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.

77

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.

78

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.

79

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.

80

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.

81

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

82

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

83

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.

84

• 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

85

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.

86

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.

87

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,

88

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.

89

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

90

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

91

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

92

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:

93

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:

94

Concepto % Metodología % Mercado

Corrección 85% 70%

Fiabilidad de mantenimiento

80% 65%

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

95

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


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.

96

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.

97

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

98

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.

99

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.

100

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

101

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

102

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.

https://confluence.invexbt.com/pages/viewpage.action?pageId=2916823

103

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.

104

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.

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

105

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

106

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

107

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.

108

• 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

109

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

110

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.

P A O L A T O V A R H E R N Á N D E“N DE UNA... · mencionar algunos: sistemas de información,...

Documents

Transcript of P A O L A T O V A R H E R N Á N D E“N DE UNA... · mencionar algunos: sistemas de información,...