la integraciÓn continua y su aporte al aseguramiento de...
TRANSCRIPT
LA INTEGRACIÓN CONTINUA Y SU APORTE AL ASEGURAMIENTO DE LA
CALIDAD EN EL CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
ANA MARÍA GARCÍA OROZCO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
ESPECIALIZACION PROYECTOS INFORMATICOS
BOGOTÁ, D.C.
2015
2
LA INTEGRACIÓN CONTINUA Y SU APORTE AL ASEGURAMIENTO DE LA
CALIDAD EN EL CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
ANA MARÍA GARCÍA OROZCO
20151199021
Proyecto de Grado para optar al título de
Especialista en Proyectos Informáticos
DIRECTOR
ING. ALEXANDRA ABUCHAR.
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
ESPECIALIZACION PROYECTOS INFORMÁTICOS
BOGOTÁ, D.C.
2015
3
NOTA DE ACEPTACIÓN
_______________________________
_______________________________
_______________________________
_______________________________
_____________________________
Firma del Director del Proyecto
_____________________________
Firma del Revisor del Proyecto
Bogotá, 02 de Diciembre de 2015
4
Dedicatoria
A mis padres por alentarme e inspirarme día a día y brindarme
su apoyo incondicional, este triunfo no es solo mío, es de ellos, porque
sin ellos no hubiera podido llegar a donde estoy en estos momentos.
Ana María.
5
Agradecimientos
En primer lugar dar gracias a Dios, el creador de todas las cosas y quien ha provisto de
inteligencia, salud y recursos económicos para alcanzar este sueño
A mi familia por inspirarme a ser cada día mejor, pues todos y cada uno de ellos es un ejemplo
a seguir desde el punto de vista personal y profesional
A mi empresa QVision, quien me brindó el espacio y el apoyo para realizar sin tropiezos la
especialización,
A mi prima Valentina Orozco, quien aportó como diseñadora de la comunicación Visual al
embellecimiento de los gráficos que generó esta investigación
6
Contenido
RESUMEN ............................................................................................................................................... 10
ABSTRACT .............................................................................................................................................. 12
INTRODUCCIÓN .................................................................................................................................... 13
1. TÍTULO .......................................................................................................................................... 14
1.1 PLANTEAMIENTO DEL PROBLEMA ....................................................................................................... 14 1.2 FORMULACIÓN DE LA PREGUNTA DE INVESTIGACIÓN ............................................................................ 15 1.3 JUSTIFICACIÓN .................................................................................................................................... 15
1.3.1 Técnica ..................................................................................................................................... 16 1.4 OBJETIVOS .......................................................................................................................................... 16
1.4.1 Objetivo General ...................................................................................................................... 16 1.4.2 Objetivo específicos .................................................................................................................. 17
1.5 DELIMITACIÓN DEL PROBLEMA ........................................................................................................... 17 1.5.1 Alcances .................................................................................................................................... 17 1.5.2 Limitaciones ............................................................................................................................. 18
2. MARCO REFERENCIAL .............................................................................................................. 18
2.1 MARCO TEÓRICO ................................................................................................................................ 20 2.1.1 Metodologías de desarrollo ágil ............................................................................................... 22
2.1.2 METODOLOGÍAS ÁGILES ................................................................................................................. 23 2.2 HERRAMIENTAS UTILIZADAS EN EL CICLO DE DESARROLLO DE SOFTWARE ....................................... 26 2.3 REPOSITORIO PARA CÓDIGO FUENTE (CONTROL DE VERSIONES) ......................................................... 26 2.3 AUTOMATIZAR LA CONSTRUCCIÓN PARA CONSTRUIR UN COMANDO ÚNICO PARA TODO EL APLICATIVO
(COMIMT) .................................................................................................................................................. 27 2.4 AUTOMATIZACIÓN DE PRUEBAS UNITARIAS ........................................................................................ 28 2.5 PRUEBAS FUNCIONALES ...................................................................................................................... 29 2.6 AUTOMATIZACIÓN DE PRUEBAS FUNCIONALES ................................................................................... 31
3 METODOLOGÍA ........................................................................................................................... 35
3.1 TIPO DE INVESTIGACIÓN ..................................................................................................................... 36
4. PROPUESTA FINAL...................................................................................................................... 37
4.1 COMPARATIVO HERRAMIENTAS EXISTENTES EN EL MERCADO QUE APOYAN LOS PROCESOS DE
INTEGRACIÓN CONTINUA ............................................................................................................................. 37 4.1.1 METODOLOGÍA GENERAL .................................................................................................................... 38 4.1.2 ANÁLISIS COMPARATIVO .................................................................................................................... 38
4.1.2.1 Comparación de Herramientas para Proceso de Control de Versiones ..................................... 38 4.1.2.2 Comparación de Herramientas para Proceso de Construcción de Código Fuente ............. 42 4.1.2.3 Comparación de Herramientas Pruebas Unitarias ................................................................... 43 4.1.2.4 Comparación de Herramientas para Proceso de Pruebas Funcionales .................................... 44 4.1.2.5 Comparación de Herramientas para Integración Continua ...................................................... 45
4.2 MODELO DE IMPLEMENTACIÓN DE INTEGRACIÓN CONTINUA ................................................................. 46 4.2.1 CUBRIMIENTO DE LA IC DENTRO DEL CICLO DE VIDA DE SOFTWARE EN EL MODELO EN V ............. 49 4.3 PROPUESTA DE MODELO DE INTEGRACIÓN CONTINUA PARA ENTORNOS DE DESARROLLO ÁGIL ........ 51 4.4 PRECONDICIONES PARA IMPLEMENTAR INTEGRACIÓN CONTINUA ...................................................... 56 4.5 VENTAJAS DE LA INTEGRACIÓN CONTINUA ......................................................................................... 57 4.6 DESVENTAJAS DE LA INTEGRACIÓN CONTINUA ................................................................................... 58
7
CONCLUSIONES .................................................................................................................................... 60
PROSPECTIVA ....................................................................................................................................... 62
RECOMENDACIONES........................................................................................................................... 63
BIBLIOGRAFÍA ...................................................................................................................................... 64
GLOSARIO .............................................................................................................................................. 67
8
Lista de figuras
Figura 1. Tipical continuos integration cycle.
Figura 2. Modelo en V.
Figura 3. Detalles del modelo en V.
Figura 4. Aseguramiento de la calidad del software apoyado en IC visto en metodologia
tradicional.
Figura 5. Aseguramiento de la calidad del software apoyado en IC visto en metodologia
agil.
Figura 6. Practicas del trabajo SCM.
9
Lista de tablas
Tabla 1. Los procesos identificados y las herramientas a evaluar.
Tabla 2. Herramientas para el proceso de control de versiones.
Tabla 3. Integración/ Interfaz Web y GUI
Tabla 4. Herramientas Para Pruebas Funcionales.
Tabla 5. Herramientas Pruebas Unitarias.
Tabla 6. Herramientas Pruebas Funcionales
Tabla 7. Herramientas Para Integración Continua (Servidores).
10
Resumen
La calidad de software se ha convertido en un eje dentro de las empresas que utilizan
procesos de desarrollo de software, en el cuál se están invirtiendo grandes esfuerzos para lograr
obtener productos de alta calidad para alcanzar a ser un referente en el mercado de la producción
de software. Actualmente el desarrollo de aplicaciones se encuentra apoyado por diferentes
normas, certificaciones de procesos, además prácticas y herramientas que aportan mejoras en el
diseño, implementación y desarrollo de software, esta investigación se centra en una de las
prácticas que se vienen implementando las empresas para agilizar los procesos de desarrollo y
controlar la calidad del mismo.
Según Matin Flower, “La Integración Continua es una práctica de desarrollo de software
en el que los miembros de un equipo integran su trabajo con determinada frecuencia, generalmente
una persona se integra mínimo una vez al día, lo cual resulta en muchas integraciones diarias, cada
integración es verificada por un ciclo automatizado (incluyendo las pruebas), para detectar errores
de integración tan rápido como sea posible”1. Una vez conocidos los problemas comunes de las
empresas colombianas que desarrollan Software como lo son: código inestable, integraciones
(despliegues o liberaciones) fallidas, dificultad para identificar lo que se debe probar,
disponibilidad del rol de pruebas para realizar pruebas en cualquier momento que sea necesario,
falta de cultura en la realización de pruebas unitarias documentadas, limitada disponibilidad del
estado el proyecto de desarrollo de software en tiempo real, entre otros, se hace evidente la
necesidad de minimizar dichos problemas para conseguir una mayor calidad del producto; se
decide realizar esta investigación con el fin de dar a conocer los beneficios de aplicar la Integración
Continua, lograr presentar sus beneficios y la mejor forma de implementar esta práctica, para
aportar en el mejoramiento de los procesos de aseguramiento de la calidad y optimizar la
utilización de herramientas de uso gratuito, que ayudan a controlar alguna actividad dentro del
desarrollo de software, de la misma manera, mostrar a los profesionales en ingeniería de sistemas
1 M. Flower. Continous Integration – Improving software Qality and Reducing Risk. Estados Unidos. Pearson Education, 2007 .p. 23
11
la forma de mejorar su calidad de vida en su entorno laboral con respecto a los traumatismos que
se generan en el momento de realizar despliegue de modificaciones a las aplicaciones en los
ambientes de pruebas o productivo y a facilidad de identificar errores en el software ya que se
compila en cortos espacios de tiempo el código generado por todo el equipo de desarrollo.
Palabras Clave: Integración Continua, Aseguramiento de calidad de Software, despliegues
seguros
12
Abstract
Software quality has become an axis within companies that use software development
process, in which they are investing great efforts in order to obtain high quality products to meet
to become a market leader in the production of software. Currently application development is
supported by different standards, certification processes, and practices and tools that bring
improvements in the implementation and development of software, this research focuses on one
of the practices that have been implemented for companies to streamline processes development
and control quality.
According Matin Flower, "Continuous Integration is a software development practice
where members of a team integrate their work with certain frequency, usually a person integrates
at least once a day, resulting in many everyday integrations, each integration is verified by an
automated cycle (including test) to detect integration errors as quickly as possible.” Unstable code,
integration (deployment or releases) failed, difficulty in identifying what to test, test role
availability for testing at any time it: Once common problems of Colombian companies that
develop Software as are known necessary, lack of culture in achieving documented unit testing,
limited availability of state development project of real-time software, among others, the need to
minimize these problems for higher product quality is evident; It was decided to conduct this
research in order to publicize the benefits of applying continuous integration, achieving submit its
benefits and how best to implement this practice, to contribute in improving the processes of
quality assurance and optimize the use Free use tools that help control any activity within the
software development, in the same way, show professionals in systems engineering ways to
improve their quality of life in their working environment with respect to trauma that generated at
the time of deployment of changes to applications on test or production environments and ease of
identifying errors in the software as it is compiled in a short space of time code generated by the
entire development team.
Keywords: Continuous Integration, Software Quality Assurance, secure deployments.
13
Introducción
Cuando se realiza cualquier tipo de proyecto es inevitable la existencia de los riesgos, y
aún más cuando hablamos de proyectos de desarrollo de aplicaciones informáticas, algunos de los
más frecuentes pueden ser controlados mediante la Integración Continua; la cual es una práctica
que da un paso hacia adelante en el aseguramiento de la calidad del Software; la integración
continua, funciona realizando comprobaciones interconectadas entre diferentes herramientas que
miden o controlan un proceso dentro del desarrollo de Software, para conseguir un producto de
software de mejor calidad, yendo más allá de instalar herramientas para la automatización del
tareas en el desarrollo del producto, logrando establecer unos estándares y llevándolos a cabo por
todo el grupo de personas que haga parte de la implementación del software. De acuerdo con la
definición de Charles Climent “La integración continua es un conjunto de buenas prácticas que
tratan de combatir los problemas de integración, integrando más a menudo y desde etapas más
tempranas de lo acostumbrado”
Esta investigación se realizará con el fin de identificar e ilustrar el aporte que una práctica
como la integración continua, aporta más que al desarrollo de una aplicación de software, al
aseguramiento de la calidad dentro del ciclo de vida del desarrollo de software, a través de la
utilización de herramientas para desarrollo de software y la implementación de la integración
continua entre ellas
Para lograr llegar a la totalidad de implementación de integración continua, son muchos
los componentes a interrelacionar, se debe ir paso a paso, si se quisiera hacer todo al mismo tiempo,
se tiende al fracaso, por tal razón, se trabajará con base en el modelo publicado por Martin Flower,
creador de la IC, generando una guía, modelando los procesos y procedimiento para lograr una
implementación exitosa de la IC a nivel de Fábrica de Software.
14
1. Título
LA INTEGRACIÓN CONTINUA Y SU APORTE AL ASEGURAMIENTO DE LA
CALIDAD EN EL CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
1.1 Planteamiento del problema
La mayoría de las empresas en Colombia que desarrollan productos de software para
terceros o para su consumo propio, se enfrentan a diario con inconvenientes en la calidad de sus
productos. Si bien, algunas cuentan con herramientas que ayudan a mejorar ciertos tropiezos dentro
de la cadena productiva del software, como lo son los servidores para controlar las versiones de la
aplicación o las aplicaciones que se encuentren desarrollando, siguen existiendo problemas al
momento de ejecutar el paso a producción al tratar de desplegar una versión donde se encuentren
involucrados más de un desarrollador; también pueden contar con herramientas donde se
encuentren automatizadas las pruebas unitarias y de calidad, pero que al solucionar incidentes que
se presentan, se pierde el control de la versión o se afectan otras partes de la aplicación,
aumentando la posibilidad de encontrar fallos en los despliegues.
Al estar vinculados en un mismo proyecto varios desarrolladores, los cuales tiene formas
diferentes de realizar su código, seguramente se enfrentaran a reprocesos más adelante, en el
momento de realizar mantenimientos adaptativos, evolutivos o perfectivos, por no contar con
estándares de calidad definidos por la empresa, y realizar inspecciones continuas de código a través
de una herramienta para detectar problemas de calidad en él.
Los problemas descritos afectan directamente los costos de un proyecto de software, al
aumentar los tiempos estimados para la fabricación del producto, se pierde el control en la fase del
desarrollo del producto, pasando a través de los diferentes ambientes, de pruebas a producción,
devolviéndose de producción a desarrollo, de desarrollo a pruebas, generando impacto negativo
para el ordenamiento del proyecto.
15
1.2 Formulación de la pregunta de investigación
En este orden de ideas, se genera la siguiente pregunta de investigación que define y
delimita el problema por atender:
Pregunta e Investigación:
¿Cómo mejorar la calidad en el proceso de desarrollo de software a través de la
práctica de Integración Continua?
1.3 Justificación
De acuerdo con la evolución del desarrollo de software en los últimos 30 años, en la década
de los 90´s el desarrollo se realizaba de forma atómica y estaban basados en clientes pesados, para
le década del 2.000 la aparición y crecimiento de los desarrollos web, trae clientes livianos y
servidores pesados, actualmente, se hace necesario tener desarrollos con partes desacopladas y
probadas, lo más reutilizable posible, centralizar el código y tener versiones correctas para la
utilización en el negocio, al igual que contar en el equipo de desarrollo con profesionales
conscientes y preocupados por la calidad de su trabajo.
Para implementar Integración Continua contamos con una oferta de herramientas, tanto
comerciales, como Open Source. Algunas de las más conocidas son el CruiseControl (Open
Source), AntHill (Comercial/Open Source) y el DamageControl (Comercial), Jenkins (Open
Source), lo que permite a una empresa iniciar el proceso de implementación sin realizar altas
inversiones e ir evaluando cada paso que se dé en la adaptación del a la IC, si se utiliza una
16
metodología adecuada, que permita ver la evolución que tiene el área de desarrollo, QA e
Infraestructura, al ir incorporando cada paso hasta completar el ciclo de la IC.
El éxito de todo proyecto se centra en tener controlados los riesgos e imprevistos; tener un
código 100% documentado, contar con un tablero que indique el estado del código, las pruebas y
las integraciones diariamente, monitoreo, métricas de calidad, automatizar la documentación
técnica, augura una tranquilidad en el momento que el producto de software sea puesto en
producción, entregado al cliente o listo para generar réplicas del él.
1.3.1 Técnica
Proponer el diseño de un modelo para la implementación de la práctica de integración
Continua, que sea aplicable en la industria de construcción de software en Colombia, de manera
que sirva de guía para lograr con éxito la ejecución de dicha práctica y permita aumentar a calidad
en los procesos de aseguramiento de calidad del software, permitiendo ser más competitivos en el
mercado nacional e internacional.
1.4 Objetivos
1.4.1 Objetivo General
Diseñar la forma de implementar una metodología para la práctica de Integración Continua
en un entorno de Desarrollo de Software y los impactos beneficiosos en el proceso de
aseguramiento de la calidad dentro de esta.
17
1.4.2 Objetivo específicos
Realizar el análisis de las herramientas Open Source existentes para la implementación de
Integración Continua.
Diseñar un modelo para la implementación de la Integración Continua, que aporte los pasos
e interacción en cada una de las etapas del ciclo de vida de desarrollo del software.
Realizar el análisis de las ventajas y desventajas de la implementación de la
implementación de la Integración Continua relacionadas con costo vs beneficio.
1.5 Delimitación del problema
1.5.1 Alcances
El alcance de esta investigación, busca generar un modelo de implementación de
Integración Continua, llegando hasta diseñar una interacción que facilite el entendimiento y la
aplicación de esta práctica aportando al aseguramiento de la calidad del software. Mostrando los
beneficios que trae a la calidad del software en cada una de las etapas que generan reprocesos en
el ciclo de vida del desarrollo del mismo, mejorando el aumento en los indicadores que miden el
desempeño de las áreas de calidad, desarrollo e infraestructura, involucradas en la realización y
despliegue de las versiones de aplicaciones generadas para utilizarlas en un ambiente de
producción; el modelo deberá orientarse a que no sea una práctica imposible de implantar en
cualquier tipo de empresa donde se realice desarrollo de software. El alcance de la investigación
mostrará panorama existente en general en las empresas donde se realiza desarrollo de software,
las posibles herramientas con las que se podría implementar esta práctica, generará un modelo, y
al final aportará las ventajas y desventajas al implementar el modelo de la IC.
.
18
1.5.2 Limitaciones
Dentro de las limitaciones de esta investigación, se prevé el manejo de una única
herramienta en cada una de las fases del modelo que se proponga, sin demostrar que la herramienta
seleccionada provea mejores resultados que otra para el proceso en el que se utilice y aporte
mayores beneficios en los resultados esperados al finalizar la implantación de todo el modelo. Otro
punto que no se podrá determinar en esta investigación es la mejora en todos los indicadores que
manejen las organizaciones en el área de desarrollo de software o ALM como se llama en algunas
empresas.
2. Marco referencial
En el artículo “La Integración Continua Aplicada en el Desarrollo de Software en el Ámbito
Científico - Técnico” escrito por A. Salamon, P. Maller, A. Boggio, N. Mira, S. Pérez y F. Coenda,
del Departamento de Informática del Instituto Universitario Aeronáutico, describen la utilización
de un modelo básico de referencia que no solo integra 3 herramientas open source que permite
automatizar y brindar información del proceso del Building sino que provee un plan de tareas que
detallan las acciones a realizar y los encargados de ejecutarlos.
A través de la integración continua lograron que el equipo de desarrollo se desentendiera
del proceso de compilación e integración de los componentes y que pudieran visualizar en que
momento fallan las integraciones. Por otra parte la sincronización de los equipos de trabajo
permitió identificar en el momento que los desarrolladores están actualizando componentes
dependientes entre si y alertar esta situación para evitar conflictos, lo que propició el reúso de
componentes en los proyectos de software.
En el Proyecto de Grado “Incorporación de pruebas automáticas sobre transformaciones de
modelos en entornos de Integración continua de MOSKitt” para obtener el título de Ingeniería
19
Informática, realizado por Jesús Badenas Martínez para la Universidad Politécnica de Valencia-
España, siendo MOSKitt, una herramienta para la transformación de modelo (MDE), la cual
genera automáticamente un modelo a partir de otro, de acuerdo con unas reglas establecidas para
la transformación. El desarrollo de este proyecto se centra en la escogencia de herramientas que
permitan automatizar las pruebas funcionales de los nuevos modelos generados por la herramienta
MOSKitt, dentro de un entorno de Integración continua ya en funcionamiento, una vez
implementada la automatización de pruebas el trabajo concluye: “La automatización de cualquier
procedimiento siempre es un voto positivo para el avance de cualquier proyecto. En este caso la
automatización de las pruebas (aunque solo sea una parte, las transformaciones de modelos)
favoreció el rápido desarrollo de la herramienta, ya que no se desperdicia tiempo en testear una y
otra vez” “Además, la inclusión de dichas pruebas en el entorno de construcción MOSKitt aligera
y hace aún más automático el proceso; ya que nos permite conocer de antemano, sin necesidad de
llegar a probar nada, si el componente que ha sido ensamblado es funcionalmente correcto”, lo que
permite evidenciar que los entornos de integración continua propuestos por Matin Flower se
pueden expandir añadiendo otros componentes como la automatización de Pruebas
En la tesis para optar al grado de Master en Dirección Estratégica en Tecnologías de la
Información cuyo título es “Incorporación de la Integración Continua en el desarrollo de Software:
Caso de Estudio Organismo Supervisor de la Inversión en Energía y Minería” realizado por Oscar
Bertha-Hinostroza de la Universidad de Piura Perú en el año 2011,en la cual se aplicaron
cuestionarios a las personas que integraban el equipo de desarrollo del Organismo Supervisor de
la Inversión en Energía y Minería, se analizaron los resultados de dichos cuestionarios y se
encontró una correlación directa y positiva entre las variables Integración Continua y el Desarrollo
de Software.
20
2.1 Marco Teórico
2.1.1 La Integración Continua
La integración continua es una práctica que se aplica al desarrollo de software realizado
con metodologías ágiles, que se puede ejecutar siempre y cuando se implementen
automatizaciones en sus procesos de requerimientos, diseño, desarrollo, pruebas y despliegues, lo
que permite realizar cambios en el código, compilar y probarlo el mismo día, las veces que sea
necesario, siendo reglamentario que todos los desarrolladores del equipo integren su parte de
código por lo menos una vez al día.
Martin Flower (2015), asegura que tener el desarrollo como un proceso disciplinado y
automatizado, es esencial para un proyecto controlado, cuando esto se logra el equipo está más
preparado para modificar el código cuando sea necesario, debido a la confianza en la identificación
de los errores en la integración; una vez se realiza una integración los errores son detectados de
inmediato, permitiendo identificar más fácilmente de donde proviene el error, reduciendo el
tiempo que se toman los equipos para identificar errores cuando la compilación se hace posterior
varias semanas o meses de desarrollo.
El término Integración Continua fue creado por Martin Fowler (2009), en un patrón de
diseño. IC refiera a las prácticas y herramientas que aseguran la compilación y las pruebas de
manera automática para una aplicación en intervalos frecuentes y se usa un servidor de integración
que funciona como el tablero de control de las automatizaciones del proyecto. IC, puede ser
implementada en múltiples ambientes de desarrollo, hasta los que cuentan con un solo
desarrollador, pero se hace más significativa y notoria la colaboración de esta práctica en
ambientes complicados con muchos desarrolladores y probadores de software.
21
Figura 1. Tipical continous integration cycle
Fuente: http://www.methodsandtools.com
En este momento existen modelos definidos para la implementación de la IC, los cuales
son básicamente para el proceso de codificación de software, donde:
a. Un desarrollador realiza un comimt (cambio) sobre el SCM (Software Configuration
Managmen).
b. Después del comimt el administrador de integración detecta el cambio, toma del repositorio
las últimas versiones y ejecuta los scrips que forman todo el Software.
c. El integrador de Administración continua informa por e-mail a cerca de los resultados de
la compilación a los miembros del grupo configurados en él.
d. El administrador realiza inspección con una frecuencia determinada.
La implantación de IC, trae para una organización un cambio impactante en el área de
mantenimiento y desarrollo de software, ya que introduce altos estándares de calidad en la
22
programación, trayendo un crecimiento en la calidad del producto y de los profesionales
involucrados.
Muchos servidores de IC, proveen alertas para el estado del proyecto, algunos envían
correos electrónicos a los implicados y hasta proveen SMS para que el líder de Desarrollo y/o del
proyecto esté informado de las alertas en la evolución del proyecto, de esta forma se podrán tomar
decisiones y contingencias necesarias para recuperar el flujo normal del proyecto.
Existen muchas herramientas que permiten crear entornos de integración continua, que se
enfocan a diferentes lenguajes de programación, para diferentes plataformas tecnológicas, algunas
de reconocidas empresas como IBM que cuentan con suites que van desde los requerimientos hasta
la integración continua, con costos altísimos, también existen herramientas Open Source que
proveen la automatización en diferentes fases de la IC, siendo integrables con otras herramientas
Open Source, multiplataforma y trabajan con los lenguajes de programación más utilizados en
nuestro país como son C#, Java y .Net
2.1.1 Metodologías de desarrollo ágil
En el año 2001, se realizó una reunión en Utah-EEUU, en la cual se originó el término
“ágil” para ser referenciado con el desarrollo de software. En esta reunión se permitieron generar
los principios y procesos que podrían ayudar a los equipos de desarrollo de software a desarrollar
aplicaciones de forma diferente a la tradicional, de una forma más flexible en cuanto a
documentación y donde se pudiera llevar un control sobre la ejecución de actividades del proyecto,
permitiendo tomar decisiones de forma rápida para solucionar problemas y/o cambios que se
presenten a lo largo del proyecto. La documentación originada de esta reunión se denomina
“Manifiesto Ágil”, un documento donde se resume la filosofía del desarrollo “ágil”.
23
De acuerdo con el Manifiesto Ágil, se valora:
a. A la persona y las relaciones del equipo durante la ejecución del proyecto de desarrollo.
“Es más importante construir un buen equipo que construir el entorno”
b. No producir documentos a menos que sean necesarios de forma inmediata para tomar un
decisión importante”. Esto quiere decir que la documentación debe ser muy puntual y
precisa, de acuerdo con el objetivo de lo que se quiera mostrar.
c. La interrelación del equipo de desarrollo con el cliente debe ser continua buscando que el
proyecto nunca se detenga por definiciones, dejando a un lado las estricciones de una
documentación previa (contratos, requerimientos).
d. Fortalecer la capacidad para reaccionar de forma efectiva a los cambios que se presenten
en la ejecución del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.),
lo que implica que la planificación debe de ser flexible y abierta.
2.1.2 Metodologías ágiles
Programación extrema (extreme programming, xp) xp42. Es una metodología ágil
centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de
software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua
entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes,
simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define
como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y
donde existe un alto riesgo técnico.
2 Beck, K. “Extreme Programming Explained. Embrace Change”, Pearson Education, 1999. Traducido al español como: “Una explicación de la programación extrema. Aceptar el cambio”, Addison Wesley, 2000.
24
Scrum53. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco
para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está
especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales
características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones,
denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento
ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo
largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para
coordinación e integración.
Crystal Methodologies4. Se trata de un conjunto de metodologías para el desarrollo de
software caracterizadas por estar centradas en las personas que componen el equipo y la reducción
al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El
desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado
por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir
esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo
definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por
colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).
Dynamic Systems Development Method (DSDM)5. Define el marco para desarrollar un
proceso de producción de software. Nace en 1994 con el objetivo de crear una metodología RAD
unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de
desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio,
modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son
iterativas, además de existir realimentación a todas las fases.
3 Schwaber K., Beedle M., Martin R.C. “Agile Software Development with SCRUM”. Prentice Hall. 2001. 4 Fowler, M., Beck, K., Brant, and J. “Refactoring: Improving the Design of Existing Code”. Addison-Wesley. 1999. 5 Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. “Agile software development methods Review and analysis”. VTT Publications. 2002.
25
Adaptive Software Development (ASD)6. Su impulsor es Jim Highsmith. Sus principales
características son: iterativo, orientado a los componentes software más que a las tareas y tolerante
a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración
y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del
software; en la segunda desarrollan las características y finalmente en la tercera se revisa su
calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores
y volver a iniciar el ciclo de desarrollo.
Feature-Driven Development (FDD)7. Define un proceso iterativo que consta de 5 pasos.
Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación
del sistema partiendo de una lista de características que debe reunir el software. Sus impulsores
son Jeff De Luca y Peter Coad.
Lean Development (LD)8. Definida por Bob Charette’s a partir de su experiencia en
proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos
proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se
manejan adecuadamente se pueden convertir en oportunidades que mejoren la
6 Highsmith J., Orr K. “Adaptive Software Development: A Collaborative Approach to Managing Complex Systems”. Dorset House. 2000. 5 Coad P., Lefebvre E., De Luca J. “Java Modeling In Color With UML: Enterprise Components and Process”. Prentice Hall. 1999. 8 Poppendieck M., Poppendieck T. “Lean Software Development: An Agile Toolkit for Software Development Managers”. Addison Wesley. 2003.
26
2.2 Herramientas utilizadas en el Ciclo de Desarrollo de Software
2.3 Repositorio para código fuente (control de versiones)
Para algunos profesionales en desarrollo de software recién egresados, desarrolladores
Junior y para profesionales con experiencia que laboran para compañías donde cuentan con
desarrollo de aplicaciones tercerizado o con proyectos de mantenimiento de software de bajo
impacto, no es conocido el uso de un Repositorio de Código Fuente. Los repositorios de Código
Fuente se acostumbran a utilizar donde se trabaja en proyectos donde existen más de 2 recursos
que aporten a la modificación o expansión del código, alguna veces encontrándose en diferentes
ubicaciones.
El Repositorio de Código fuente tiene como fin centralizar en una ubicación (ruta) la última
versión compilada del código fuente de un programa, módulo o aplicativo. El no contar con un
repositorio de código fuente cuando trabajan más de 2 recursos en el desarrollo de la aplicación
puede generar los siguientes inconvenientes:
1. ¿Cómo controlar que no modifiquen el código sobre una versión anterior a la última del
aplicativo?
2. ¿Cómo identifico que dos personas modifican un mismo archivo al mismo tiempo?
3. ¿Qué hacer cuando a mitad de un desarrollo necesito realizar una actualización de la
aplicación? ¿Qué versión debo utilizar? ¿Espero a terminar el desarrollo para poderlo
hacer?
Si se utiliza un repositorio de código fuente se logrará las siguientes ventajas:
1. Manejo de la concurrencia. Cuando varias personas tengan que trabajar con el mismo
archivo, objeto o clase, el repositorio de código ayuda a tener un control sobre todos
los componentes del código
27
2. Seguridad. Esta ventaja se gana porque el Repositorio cuenta con control de acceso, lo
cual permite únicamente a los desarrolladores autorizados realizar modificaciones
sobre el código.
3. Administración de Versiones. Se contará con la opción de retornar a una versión
anterior de la aplicación, generar actualización versiones de aplicaciones, poder replicar
aplicaciones en otros ambientes (pruebas y desarrollo), controlar la información de los
autores de los cambios al código y las fechas de dichas modificaciones
2.3 Automatizar la construcción para construir un comando único para todo el aplicativo
(COMIMT)
En el momento cuando se necesita enviar una nueva versión de código de una aplicación,
hay que realizar un proceso de integración de todos los componentes que forman parte del
software, lo que lleva al desarrollador a realizar varios pasos, como obtener el código fuente,
compilarlo, ejecutar las pruebas, etc.
En la mayoría de los proyectos de software este es un proceso completamente manual y
cada desarrollador lo realiza a su parecer y conocimiento, en empresas con buenas prácticas se
logra documentar, con el fin de mitigar algún error que pudiera presentarse, pero aunque se tenga
control de la ejecución de esta integración, no minimiza el riesgo de poner en producción una
versión que no corresponda, código con cambios no documentados o fragmento de código o
funcionalidades sin pruebas unitarias
Con el fin de mejorar este proceso se llega a la automatización. “Actualmente se cuenta
con herramientas basadas en scripts de compilación. En .NET se utiliza MSBuild, en Javascript
hay opciones como Grunt, en Ruby existe Rake. Todas estas herramientas tienen el propósito de
poder definir las acciones que se deben realizar de manera que se puedan ejecutar en un único
paso. Generar un script requiere de una dedicación de tiempo que incialmente podría verse como
28
tiempo adicional, pero una vez realizado es fácil adaptarlo para nuevos proyectos, por lo que la
inversión de tiempo se recupera rápidamente”9.
2.4 Automatización de pruebas unitarias
De acuerdo con Meudec10, la investigación en la automatización de las pruebas software
destina sus esfuerzos, fundamentalmente, a las tres siguientes líneas de trabajo:
1. Tareas administrativas (registro de especificaciones de prueba, generación de informes)
2. Tareas mecánicas (ejecución y monitorización, utilidades de captura y reejecución)
3. Tareas de generación de casos de prueba. Respecto de la tercera línea citada
(generación de casos), ball et al.
indican así mismo tres enfoques principales: (1) dado un fragmento de código fuente,
generar automáticamente datos de entrada para lograr un criterio determinado de cobertura de
sentencias, ramas o caminos; (2) dado el conocimiento del ingeniero de pruebas del código fuente
y de su comportamiento esperado, desarrollar algoritmos que generen automáticamente los datos
de entrada y que comprueben las salidas; (3) dada una especificación formal, generar
automáticamente casos de prueba a partir de ella. Si bien las especificaciones formales aumentan
la capacidad de automatizar el proceso de pruebas11, es también cierto que son difíciles de escribir
y mantener, difíciles de aplicar en la práctica, y son raramente utilizadas en entornos industriales.
Así, lo más habitual es que el programador escriba los casos para probar una característica de un
nuevo sistema después de que el código que implementa dicha característica haya sido escrito12,
siendo de este modo el código la fuente más habitual para escribir los casos de prueba13. En los
9 Informacion extraida de: https://ivanator.wordpress.com/2009/01/12/montando-un-entorno-integracion-continua-hudson-ant-svn-netbeans/ 10 Dustin E., Rasca J., Paul J. “Automated Software Testing”, ISBN 0-201-43287-0, Addison Wesley, 1999. 11 Ibíd. 12 Cámara Uruguaya de tecnologías de información (CUTI). http://www.cuti.org.uy/ 13 Centro de Ensayos de Software (CES) .http://www.ces.com.uy, 2007.
29
últimos años se han desarrollado una serie de frameworks (los conocidos entornos X-Unit, como
JUnit o NUnit) para automatizar las pruebas unitarias, y hay multitud de entornos de desarrollo
que ya incorporan plugins y componentes que permiten su integración. Algunos plugins y
herramientas utilizan X-Unit para generar automáticamente casos de prueba: normalmente, el
usuario elige un método de la CUT (por ejemplo, el método deposit en la clase Account) y la
herramienta genera un método cuya implementación debe ser suministrada por el usuario (así,
crearía un método testDeposit, que el usuario debería completar con la llamada deseada, asignando
los valores adecuados a los parámetros y escribiendo el oráculo).
Así pues, en lo tocante a pruebas unitarias, la segunda de las líneas apuntadas por Meudec
(y que citábamos al principio de este artículo) se encuentra suficientemente automatizada con
entornos X-Unit; pero en las otras dos queda todavía mucho trabajo por hacer. Precisamente a
estos dos tipos de tareas se han dedicado los esfuerzos de investigación en la línea de trabajo de
automatización de pruebas del proyecto (TIC2003-02737-C02-02)14, que finaliza en noviembre de
2006. A continuación se presentan los principales resultados obtenidos
2.5 Pruebas funcionales
El objetivo de la prueba funcional es validar cuando el comportamiento observado del
software probado cumple o no con sus especificaciones. La prueba funcional toma el punto de
vista del usuario15. Las funciones son probadas ingresando las entradas y examinando las salidas.
La estructura interna del programa raramente es considerada16. Para realizar pruebas funcionales,
la especificación se analiza para derivar los casos de prueba. Técnicas como partición de
equivalencia, análisis del valor límite, grafo causa-efecto y conjetura de errores son especialmente
pertinentes para las pruebas funcionales. Se deben considerar condiciones inválidas e inesperadas
de la entrada y tener en cuenta que la definición del resultado esperado es una parte vital de un
14 Informacion extraida de: http://in2test.lsi.uniovi.es/pris2006/PRIS2006-PoloPiattini.pdf 15 Beizer B. “Software testing techniques (2nd ed.)”, ISBN: 0-442-20672-0, Van Nostrand Reinhold Co, 1990. 16 Kaner C., Falk J., Nguyen H. “Testing Computer Software, 2nd Edition”, ISBN: 0471358460, Wiley, 1999.
30
caso de prueba. El propósito de la prueba funcional es mostrar discrepancias con la especificación
y no demostrar que el programa cumple su especificación17.
Un caso de prueba (test case) es un conjunto de valores de entrada, precondiciones de
ejecución, resultados esperados y poscondiciones de ejecución, desarrollados con un objetivo
particular o condición de prueba, tal como ejercitar un camino de un programa particular o para
verificar que se cumple un requerimiento específico18.
Un script de prueba (test script) son los datos y las instrucciones escritas con una sintaxis
formal, almacenado en un archivo y usado por una herramienta de automatización de las pruebas.
Un script de prueba puede automatizar uno o más casos de prueba, navegación, inicialización u
operaciones de configuración del entorno. Un script de prueba previsto para la ejecución manual
de las pruebas es un procedimiento de prueba19. Una suite de pruebas es uno o más conjuntos de
pruebas reunidos para satisfacer un objetivo de prueba20. Un conjunto de prueba incluye scripts y
documentación. En nuestro caso, las suites constituyen un conjunto de scripts y el orden de
ejecución de los mismos.
Las pruebas de regresión tienen como objetivo verificar que no ocurrió una regresión en la
calidad del producto luego de un cambio, asegurándose que los cambios no introducen un
comportamiento no deseado o errores adicionales. Implican la reejecución de alguna o todas las
pruebas realizadas anteriormente21. Las pruebas de humo son un conjunto de pruebas aplicadas a
cada nueva versión, su objetivo es validar que las funcionalidades básicas de la versión se
comportan según lo especificado. Estas pruebas buscan grandes inestabilidades o elementos clave
faltantes o defectuosos, que hacen imposible realizar las pruebas como fueron planificadas para la
17 Myers G. “The art of software testing, 2nd edition”, ISBN 0-471-46912-2, John Wiley & Sons Inc., 2004. 18 IEEE Standard Glossary of Software Engineering Terminology Institute of Electrical and Electronics Engineers, ISBN: 155937067X, 1990. 19 Software Test Automation, Effective use of test execution tools. Mark Fewster & Dorothy Graham. ISBN 0-20133140-3 20 Ibid. 21 Black R. “Managing the Testing Process, 2nd Edition”. ISBN 0-471-22398-0, Editorial Wiley, 2002.
31
versión. Si la versión no pasa las pruebas de humo, no se comienza la ejecución de las pruebas
planificadas de la versión.
2.6 Automatización de pruebas funcionales
Hay herramientas que apoyan diversos aspectos de la prueba. A continuación se presenta
una clasificación posible para las herramientas22:
a. Administración de las pruebas y el proceso de pruebas: herramientas para la
administración de las pruebas, para el seguimiento de incidentes, para la gestión de
la configuración y para la administración de requerimientos.
b. Pruebas estáticas: herramientas para apoyar el proceso de revisión, herramientas
para el análisis estático y herramientas de modelado.
c. Especificación de las pruebas: herramientas para el diseño de las pruebas y para la
preparación de datos de prueba.
d. Ejecución de las pruebas: herramientas de ejecución de casos de prueba,
herramientas de pruebas unitarias, comparadores, herramientas de medición del
cubrimiento, herramientas de seguridad. Desempeño y monitorización:
herramientas de análisis dinámico, herramientas de desempeño, de carga y de
estrés, herramientas de monitorización.
Para la automatización de las pruebas funcionales son especialmente indicadas las
herramientas de ejecución de las pruebas de captura y reproducción. Estas herramientas permiten
al tester capturar y grabar pruebas, para luego editarlas, modificarlas y reproducirlas en distintos
entornos. Herramientas que graban la interfaz de usuario a nivel de componentes y no de bitmaps
son más útiles. Durante la grabación se capturan las acciones realizadas por el tester, creando
automáticamente un script en algún lenguaje de alto nivel. Luego el tester modifica el script para
22 International Software Testing Qualifications Board, Certified Tester Foundation Level Syllabus, Version 2005. Extraido de: http://www.istqb.org/fileadmin/media/SyllabusFoundation.pdf
32
crear una prueba reusable y mantenible. Este script se vuelve la línea base y luego es reproducido
en una nueva versión, contra la cual es comparado. En general estas herramientas vienen
acompañadas de un comparador, que compara automáticamente la salida en el momento de
ejecutar el script con la salida grabada23.
2.7 Herramientas para análisis estático de código
Los defectos que son detectados por las herramientas de análisis estático se encuentran:
1. Referenciar una variable con un valor indefinido.
2. Interfaces inconsistentes entre módulos y componentes.
3. Variables que no se utilizan o que se declaran de forma incorrecta.
4. Código inaccesible (muerto).
5. Ausencia de lógica o lógica errónea (posibles bucles infinitos).
6. Construcciones demasiado complicadas.
7. Infracciones de los estándares de programación.
8. Vulnerabilidad de seguridad.
9. Infracciones de sintaxis del código y modelos de software.
Las herramientas de análisis estático generalmente las utilizan los desarrolladores (cotejar
con las reglas predefinidas o estándares de programación) antes y durante las pruebas de
componente y de integración, o durante la comprobación del código, para configurar las
herramientas de análisis estático pueden producir un gran número de mensajes de advertencias que
23 Dustin E., Rasca J., Paul J. “Automated Software Testing”, ISBN 0-201-43287-0, Addison Wesley, 1999.
33
deben ser bien gestionados para permitir el uso más efectivo de la herramienta. Los compiladores
pueden constituir un soporte para los análisis estáticos, incluyendo el cálculo de métricas.
Open source
Esta iniciativa define al software open source como un software que puede ser utilizado
libremente, modificado y compartido por cualquier persona. Este es desarrollado por diferentes
personas y se distribuye a partir de licencias que deben cumplir la definición que establece el Open
Source. La iniciativa Open Source fue fundada por Erick Raymon y Brunce Perens en febrero de
1998, convirtiendose en las personas referents en la comunidad Open Source24
Aseguramiento de calidad (QA)
El aseguramiento de calidad dentro del proceso de desarrollo de software corresponde a
planear, organizar, dirigir y controlar la calidad de un sistema con el objetivo de dar al cliente
una calidad adecuada en su producto.
Control de calidad (QC)
En el marco de la ingeniería de software son los mecanismos, acciones y herramientas
que se utilizan para detectar presencia de errores dentro de un producto de software. Por ende es
un recurso que se utiliza dentro del aseguramiento de la calidad
El aseguramiento de la calidad (QA) es proactivo, ya que trata sobre los procesos y como
prevenir defectos (por ejemplo: definición de procesos, definición de necesidades,
entrenamiento, auditorías, etc.) mientras que el control de Calidad (QC) es reactivo ya que trata
sobre los productos y como encontrar defectos (Testing, revisión de pares, Inspecciones)
24 Informacion extraida de: http://opensource.org
34
Existen dos tipos de aseguramiento de la calidad: QA Estático y QA Dinámico.
QA Estático: Es cuando se buscan defectos en el sistema estando este fuera de servicio,
se puede aplicar sobre artefactos de requerimientos, análisis, diseño y código, a esta técnica se le
llama análisis estático de documentación, y se aplica en forma de revisiones, inspecciones,
auditorias de calidad.
a. Los puntos que se pueden revisar en un análisis estático son:
b. Estándares de programación. (Brindados por el área de Arquitectura de Software)
c. Diseño Funcional de la aplicación (análisis de flujos).
d. Fuentes y uso de datos
e. Complejidad de la programación (ejecución ciclomática).
QA Dinámico: Son las pruebas que se realizan al sistema directamente en ejecución en ambientes
replicados al ambiente de producción en donde funcionaría finalmente la aplicación. Consiste en
ejecutar una acción sobre el programa de software y revisar su forma de reaccionar a dicha acción,
verificando si es la respuesta esperada de acuerdo con el requerimiento inicial. Como recursos para
el aseguramiento de calidad del software se cuenta con los siguientes Niveles de testing:
De unidades (Unitarias): son las pruebas que se realizan de manera individual a los módulos,
Funcionalidades, que hayan sido creados o modificados en el código
De integración: son las pruebas que se realizan a los módulos, Funcionalidades, que hayan sido
creados, modificados de manera conjunta con los demás componentes de la aplicación.
Funcionales: son las pruebas encargadas de evaluar el funcionamiento, de las entradas, el proceso,
las salidas de acuerdo con los requerimientos del solicitante
De aceptación: son las pruebas que realiza el usuario, donde se verifican los resultados aplicados
a la operación del negocio
35
De uso: son las pruebas donde se verifica la calidad de uso, están pueden ir inmersas en las
funcionales y de aceptación
De volumen: Son pruebas que se realizan a través de herramientas donde se verifican que el
sistema soporte grandes volúmenes de datos
De Carga o Stress: Son pruebas que se realizan a través de herramientas donde se verifica el
funcionamiento del sistema con grandes cargas de procesamiento y concurrencia de
solicitudes de usuarios
Testing automatizado: Son las pruebas que se diseñan escribiendo programas en herramientas de
automatización de pruebas, para que dicho programa realice pruebas que se ejecutan de
forma manual, reduciendo tiempo y costos de personal tester.
También es importante definir dentro del aseguramiento de la calidad de software la diferencia
que existe entre validar y verificar. Estos términos son muy utilizados por lo general como
sinónimos, pero en el campo de la calidad del software son acciones muy diferentes
La validación es la acción de evaluar un resultado final y comprobar que cumple con los
requerimientos solicitados.
La verificación es la acción de comprobar los requisitos de cada una de las fases, en esta actividad
son muy utilizadas las listas de chequeo, como recurso para permitir el inicio de la fase
siguiente.
3 Metodología
La metodología de la investigación se estructura en los siguientes pasos:
1- Recolección bibliográfica en las bases de datos bibliográficas digitales con el fin de
ubicar literatura y artículos que se refieran a la integración continua, realizar
recolección de datos y fuentes de información de la práctica de integración
36
continua, referenciar, ubicar y conocer los casos exitosos de implementación de esta
práctica en las empresas donde se ha logrado y funciona de manera habitual, con el
fin de identificar los puntos comunes en dichas implementaciones para apoyar la
creación de un modelo estándar de implementación.
2- Realizar un comparativo de las diferentes herramientas existentes en el mercado
actual, utilizadas en cada una de las diferentes etapas de la implementación de la
IC, para conocer las ventajas en cuanto a compatibilidad e integralidad con las
plataformas utilizadas más comúnmente en el ámbito de desarrollo de software
Colombiano, tratando de mostrar en mayor parte las herramientas tengan la forma
de adquisición open source, pensando en la facilidad de adquisición para cualquier
tipo de empresa
3- Generar el diseño de la mejor forma de implantar la práctica de Integración
Continua, basado en los resultados de la información obtenida en los de pasos
anteriores, cuidando que, esta realización sea por fases e indique las precondiciones
para implementarla y las postcondiciones que se deben esperar para continuar con
la fase siguiente, y brindado las recomendaciones advertencias necesarias para
minimizar la ocurrencia de errores que se puedan presentar en la implementación
del modelo propuesto
4- Finalmente se procederá a presentar el modelo propuesto en el documento de
trabajo de grado, con el fin de cumplir con el objetivo general de la investigación.
3.1 Tipo de investigación
Este estudio se realizará a través de investigación explicativa, con la cual se pretende
proponer un modelo para implementación de la práctica de integración continua que brinde
aseguramiento de la calidad del Software en entornos de desarrollo.
37
4. Propuesta final
4.1 Comparativo herramientas existentes en el mercado que apoyan los procesos de
Integración Continua
Cuando se realiza cualquier tipo de proyecto es inevitable la existencia de los riesgos, y
aún más cuando hablamos de proyectos de desarrollo de aplicaciones informáticas, algunos de los
más frecuentes pueden ser controlados mediante la Integración Continua; la cual es una práctica
que da un paso hacia adelante en el aseguramiento de la calidad del Software; funciona realizando
comprobaciones interconectadas entre diferentes herramientas que miden o controlan un proceso
dentro del desarrollo de Software, para conseguir un producto de software de mejor calidad, yendo
más allá de instalar herramientas para la automatización del tareas en el desarrollo del producto,
logrando establecer unos estándares y llevándolos a cabo por todo el grupo de personas que haga
parte de la implementación del software. De acuerdo con la definición de Charles Climent “La
integración continua es un conjunto de buenas prácticas que tratan de combatir los problemas de
integración, integrando más a menudo y desde etapas más tempranas de lo acostumbrado”
La investigación se realiza con el fin de demostrar cómo se mitigan los riegos de fallos en
producción, se minimiza la Falta de visibilidad del proyecto, se logra coordinar la comunicación
asertiva, aumenta la calidad del proceso, la calidad del producto y la calidad profesional en las
personas que hacen parte del proyecto, a través de la utilización de herramientas para desarrollo
de software y la implementación de la integración continua entre ellas
Para lograr llegar a la totalidad de implementación de integración continua, son muchos
los componentes a interrelacionar, se debe ir paso a paso, si se quisiera hacer todo al mismo tiempo,
se tiende al fracaso, se identificarán las herramientas con que se dispone actualmente en las
diferentes etapas de la IC, sus características de manera que se visualice los aportes de cada una,
aunque la investigación inicial es muy puntual, se ha intentado que los resultados de este
38
comparativo sean suficientemente representativos para facilitar la decisión de qué herramientas
utilizar en proyectos de Desarrollo de Software, para lograr una implementación exitosa de la IC
4.1.1 Metodología general
Para poder realizar el estudio comparativo se han identificado los procesos en los que
interviene la práctica de Integración Continua y una serie de herramientas que permiten
controlar y ejecutar el proceso identificado
Tabla 1. Los procesos identificados y las herramientas a evaluar.
PROCESO HERRAMIENTAS
Control de Versiones Sistemas Controladores de Versiones, Administradores de versiones, repositorios de Código Fuente
Automatización Pruebas Unitarias Automatizador Pruebas Unitarias
Construcción de Código Fuente Herramienta de Revisión Estática de Código
Automatización Pruebas Funcionales
Sistemas de Automatización de Pruebas Funcionales, Robots de Pruebas
Despliegues Sistemas de Automatización de Despliegues
Integración Continua Servidor de Integración Continua
Fuente: Autor
4.1.2 Análisis comparativo
4.1.2.1 Comparación de Herramientas para Proceso de Control de Versiones
39
Definiendo el control de Versiones como el proceso de gestionar los cambios que se
realizan a una aplicación de software, ya sean modificaciones al código fuente o la
configuración de la misma. Una versión se produce en un estado y momento de tiempo
definido para que este se pueda desplegar en el ambiente de pruebas o en el ambiente de
producción dependiendo de la etapa de Ciclo de Vida de Software.
Las características que se tuvieron en cuenta para realizar la comparación de las
herramientas son las siguientes: Forma de adquisición: se identificará de 2 formas
Open Source: Código Abierto
Propietario: con costo, pago por licencia.
Tipo de Repositorio: Existen 2 modelos en las herramientas del mercado
Cliente-Servidor: funciona de manera que los desarrolladores usan un repositorio de
código Fuente central al que acceden mediante un cliente desde su máquina
Distribuido: opera de forma que cada desarrollador trabaja directamente con un
repositorio de código Fuente local y los cambios que realice se publican en otros
repositorios posteriormente
Historial de Cambios:
Snapshot: Es el Historial de Versiones compara todos los árboles de Directorios
para generar una nueva versión
Changeset: realiza ramificaciones y fusiones de manera más rápida, utiliza menor
espacio de almacenamiento
Permisos: permite administrar los accesos a los diferentes ficheros
Traza del Historial de Cambios: Indica la capacidad de la herramienta para conservar
la historia de los cambios en los ficheros o directorios
Etiquetas para Revisiones: Creación de etiquetas para identificar o diferenciar versiones
40
Administración de Archivo: Renombrar y/o fusionar versiones sin perder la historia del
cambio
Tabla 2. Herramientas para Proceso de Control de Versiones
Características Forma de Adquisición
Tipo de Repositorio
Historial de Cambios
Permisos Traza de Cambios
Etiquetas para Revisiones
Administración de Archivo
Concurrent Versions System (CVS)
Open Source
Cliente-Servidor
Snapshot X X X
Subversion Open Source
Cliente-Servidor
Snapshot/ Changeset
X X X
AccuRev Propietario Cliente-Servidor
Changeset X X X
Clear Case (IBM)
Propietario Cliente-Servidor
Changeset X X X X
Bazaar Open Source
Distribuido
Snapshot X X X X
Team Foundation Server
Propietario Cliente-Servidor
Snapshot X X X X
GIT Open Source
Distribuido
Snapshot X X X
Fossil Open Source
Distribuido
Snapshot X X X X
Fuente: Autor
Integración: capacidad de interacción y Plugins para ser integrado con otras
Plataformas utilizadas actualmente.
Interfaz WEB
Interfaz GUI
41
Tabla 3. Integracion/Interfaz Web y GUI
Características Integración Interfaz Web Interfaz GUI
Concurrent Versions System (CVS)
Visual Studio, Eclipse Si Windows, Unix, Linux, Mac OSX, BeOS
Subversion BBEdit, Eclipse, NetBeans, Visual Studio, Emacs, IntelliJ IDEA, KDevelop, Komodo IDE
Incluido módulo Apache 2, WebSVN, ViewSVN, ViewVC, Trac, SharpForge,sventon, Warehouse, codeBeamer
Anjuta, BBEdit, Eclipse, Visual Studio, Emac, IntelliJ IDEA, KDevelop, Komodo IDE, MonoDevelop, NetBeans, Textmate, RabbitVCS.
AccuRev Visual Studio, Eclipse, IntelliJ IDEA Web Interfaz Windows, Unix, Linux, Mac OSX, BeOS
Clear Case (IBM) Emac, Eclipse, Visual Studio, Kdevelop, IntelliJ IDEA
Web Interfaz MS Windows, Unix, Clientes TSO para z/OS
Bazaar Visual Studio, Eclipse, Text Mate, Komodo IDE
Permite utilización de Servidor WEB
Bazaar Explorer, Tortoise Bzr (Windows)
Team Foundation Server
Visual Studio, IntelliJ IDEA SSWI, VSS Remoting Windows, Linux, Mac OS, Solaris, SourceAnyWhere for VSS
GIT Aptana 3 Beta, Eclipse, Emacs, Text mate
gitWeb, wit, cgit, gitHub, gitorius, code Beamer
Gitk, git-gui, tig, TortoiseGit, qgit, gitg, git-cola, Tower, Source Tree, GitX
Fossil Eclipse Team Provide for Fossil Incluido Fossil GUI
Fuente. Autor
Una de las características en que más nos debemos fijar es en la cantidad de interfaces
que ofrezca la herramienta de control de versiones, en la tabla anterior podemos apreciar la
cantidad de interfaces que ofrecen los fabricantes, en este momento los desarrollos de
aplicaciones necesitan interfaces, Web, GUI y plugins, de maneja que sea más fácil su manejo.
Los sistemas operativos con los que se acopla facilita el acceso sea web o escritorio, siendo
42
los más utilizados Windows, Linux, Mac Os y Solaris, Pero la característica más relevante es
la integración con las plataformas de desarrollo, la de uso más general, es la del entorno de
desarrollo IDE, por eso hay que fijarse en las que ofrecen integración con Eclipse y Visual
Studio.
4.1.2.2 Comparación de Herramientas para Proceso de Construcción de Código
Fuente
Pruebas Estáticas de código: En un negocio de construcción de software, se debe
garantizar la calidad del código fuente que proveen sus desarrolladores, para lograr estándares
claros, se debe contar con unos lineamientos para la codificación y para validar el
cumplimiento de estos lineamiento se utilizan las pruebas estáticas de código. En la realización
de estas pruebas es fundamental contar con una herramienta que facilite el encontrar errores
como: código muerto, código quemado, código no documentado, ciclos mal construidos,
errores de sintaxis, etc.
Tabla 4. Herramientas Construcción Código Fuente.
Herramienta Forma de Adquisición Plataforma Lenguaje Integración Documentación
PHPLint Propietario Windows/ Linux PHP Jenkins Tutorial / Manual
YASCA Open Source Windows/Linux
Java, .NET, PHP, HTML, CSS, etc.
ClamAV, Cpp Check, PHPlint, FindBugs Manual
PMD Propietario Windows/ Linux Java No se Integra Tutorial/ Manual
FindBugs Open Source Windows/ Linux
Java, Eclipse, NetBeans, IntelliJ IDEA Jenkins Tutorial/ Manual
SonarQube Open Source Windows/Linux
Java, .NET, PHP, HTML, CSS, etc. Eclipse, NetBeans, IntelliJ IDEA
Maven, Ant Jenkins, Hudson Tutorial/ Manual
Fuente: Autor.
43
Para la elección de la herramienta de pruebas estáticas de código las características más
relevantes son el los lenguajes de programación y las plataformas que se utilizan en la
compañía y la integración con las demás herramientas con las que se desee trabajar.
4.1.2.3 Comparación de Herramientas Pruebas Unitarias
Para estas pruebas el uso de herramientas agiliza actividades de pruebas atómicas como
probar una clase o un módulo en particular. Las herramientas dependen del lenguaje utilizado.
La mayoría de ellas funcionan como un framework para la automatización de las pruebas
unitarias y de integración. Contienen clases y métodos que facilitan la tarea de realizar pruebas
en el sistema y así asegurar la consistencia y funcionalidad, proporcionan la forma de diseñar
y ejecutar pruebas unitarias de forma mucho más ágil y controlada.
Tabla 5. Herramientas Pruebas Unitarias.
Herramienta Licencia Plataformas Lenguaje Integración Documentación
JUnit Open Source Windows/ Linux Eclipse, NetBeans
Jenkins Hudson, Ant, Maven Coockbook/Foro /FAQ
PHPUnit Open Source Windows/ Linux PHP Jenkins Manual
SimpleTest Propietario Windows/ Linux Eclipse Hudson Tutorial/How to
TestNG Open Source Windows/ Linux Java Jenkins, Maven Tutoriales
CPPUNit Open Source Windows/ Linux C/C++ Jenkins Tutoriales
Nunit Open Source Windows/Linux .NET Jenkins Tutoriales
Fuente: Autor
Como puede verse en este segmento, existen muchas herramientas que ayudan al
equipo de desarrollo de un proyecto a realizar sus pruebas para alcanzar altos niveles de
44
calidad. Elegir las más adecuadas no es una tarea sencilla. La comparación de estas
herramientas permite mostrar un panorama de las herramientas más populares y utilizadas para
las pruebas realizadas durante la construcción del código y facilitar la toma de esta decisión
de acuerdo con las características relevantes para una organización.
4.1.2.4 Comparación de Herramientas para Proceso de Pruebas Funcionales
La realización de las pruebas funcionales de una aplicación, requiere de una inversión
en recurso humano y tiempo para el diseño y ejecución de las pruebas, sin contar con el tiempo
de capacitación, si las pruebas las realizará un tercero. Buscando minimizar este impacto en
los proyectos de Software se creó la automatización de Pruebas de software, la cual se
realiza a través de una herramienta diseñada para ese fin, a través de esa herramienta se puede
controlar la ejecución de las pruebas y la comparación de resultados obtenidos vs los resultados
esperados. El impacto de utilizar automatización de pruebas se refleja en negocios donde las
pruebas son repetitivas o requiere un gran esfuerzo para hacerlas de forma manual
Tabla 6. Herramientas Pruebas Funcionales.
HERRAMIENTAS
SIMULACIÓN EXACTA DEL ESCENARIO
ADMIN DE OBJETOS.
UTILIZA DIFERENTES NAVEGADORES.
INTEGRACIÓN CON HERRAMIENTAS DE GESTIÓN DE PRUEBAS
SISTEMA OPERATIVO / PLATAFORMAS
FACILIDAD DE CREACIÓN DE SCRIPTS.
SOPORTE TÉCNICO.
LENGUAJES SOPORTADOS PARA LA CREACIÓN DE SCRIPTS.
Unified functional testing (HP)
X X X X Windows X X Visual Basic
Selenium By SeleniumHQ X X
X X Windows, MacOS y Linux
X Visual Basic, Java, .NET
Eggplant by TestPlant
X X X X
Windows, MacOS y Linux
X X Sense Talk
Ranorex X
X X Solo WEB
Windows X X Visual Basic, Java, .NET
45
Testcomplete X
X X X Windows X X Visual Basic, Java, .NET
Microsoft test manager X
X X X Windows X X Visual Basic, Java, .NET
QMatic by QVision
X X X X
Windows, MacOS y Linux
X X Visual Basic, Java, .NET
Fuente: Autor
No se identifica ninguna herramienta superior de otra, la clave para seleccionarla seria
basada en los lenguajes de programación utilizados en la organización y a la inversión que se
desee realizar, ya que todas las herramientas son propietario a excepción de Ranorex.
4.1.2.5 Comparación de Herramientas para Integración Continua
La práctica de integración continua busca principalmente verificar que cada
modificación que se realice al código de una aplicación no genere problemas al momento del
despliegue en los ambientes de pruebas o Productivo. La IC es una práctica dentro del
desarrollo de Software que se origina de la metodología XP y que se puede implementar en
organizaciones que desarrollen con modelos ágiles.
Lo más complejo en el momento de desplegar un desarrollo es conocer el impacto real de una
actualización sobre la aplicación. La IC permite al desarrollador tener la totalidad de la
aplicación y su comportamiento ante cualquier cambio, debido a que todas las integraciones y
las pruebas se realizan en un ambiente equivalente al de Producción.
46
Tabla 7. Herramientas para Integración Continua
Herramientas Forma de
Adquisición Plataformas Lenguajes Integración
Cruise Control
Open Source
Windows, MacOS y Linux
J2EE, .NET Ant, Maven,
Subversion, CVS
Jenkins/Hudson
Open Source
Windows, MacOS y Linux
J2EE, .NET
CVS, Subversion, Git, Ant, Maven,
Jenkins
Continuum Open Source Windows, Linux Java Subversion, Ant
Bamboo Propietario
Windows, MacOS y Linux
Java Mercurial, Git, Fuente: Autor
4.2 Modelo de implementación de integración continua
La finalidad de esta investigación es proponer un modelo de implementación de integración
continua que aporte al aseguramiento de la calidad en el ciclo de vida del desarrollo de software,
teniendo en cuenta que el principal componente es el aseguramiento de la calidad, se utilizará
como base para la generación de este modelo, el Modelo en V del ciclo de Vida del desarrollo de
software.
El modelo en V deriva directamente del modelo en cascada (Waterfall model), y se usa
como base de procesos dentro del ciclo de vida de software. El modelo considera el testing como
una actividad paralela al SDLC (Sofware development Life Cycle) y no como una actividad aislada
que se realiza al final del desarrollo. Fue desarrollado en Alemania por el Ministerio de Defensa.25
25 Información extraída de: guia_de_ingenieria_del_software.pdf
47
Figura 2. Modelo en V
Fuente: guía_de_ingenieria_del_software.pdf
Este modelo ha sido adoptado por diferentes organizaciones y ha llegado a tener
profundidades de alta complejidad. Lo que hace superior a este modelo comparado con el modelo
en Cascada es que permite realizar la revisión en cada una de las etapas del ciclo de vida del
Desarrollo del Software, lo que conocemos como validación y verificación.
Los objetivos de este modelo son:
Conocer, gestionar y mitigar los riesgos del proyecto.
Garantizar la calidad del proyecto, impactando directamente en la calidad del producto.
Facilitar la comunicación entre los Involucrados del proyecto.
En definitiva se trata de un modelo más robusto y completo que el Modelo de Cascada, y
puede producir software de mayor calidad. El modelo en V permite encontrar Defectos más rápido
ya que no espera hasta el final del proyecto para realizar Pruebas. También muestra que las pruebas
no son sólo una actividad basada en la ejecución. Hay una variedad de actividades que se han de
48
realizar antes del fin de la fase de codificación. Estas actividades deberían ser llevadas a cabo en
paralelo con las actividades de desarrollo, y los técnicos de pruebas necesitan trabajar con los
desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y producir
una serie de entregables de pruebas. Los productos de trabajo generados por los desarrolladores y
analistas de negocio durante el desarrollo son las bases de las pruebas en uno o más niveles.
El modelo en V es un modelo que ilustra cómo las actividades de prueba (verificación y
validación) se pueden integrar en cada fase del ciclo de vida. Dentro del modelo en v, las pruebas
de validación tienen lugar especialmente durante las etapas tempranas, por ejemplo, revisando los
requisitos de usuario y después. La parte izquierda de la V representa la descomposición de los
requisitos y la creación de las especificaciones del sistema. El lado derecho de la V representa la
integración de partes y su verificación. V significa “Validación y Verificación”.
Figura 3. Detalles del modelo V
Fuente: http://excelza.blogspot.com.co/2009/12/sobre-pruebas-de-software-y-servicios.html
49
Aunque la Validación y la Verificación son acciones diferentes, sus objetivos si son los
mismos:
Facilitar la detección temprana y corrección de los posibles errores que se hayan
cometido en el proceso.
Fomentar y favorecer la intervención de las partes implicadas en todas las fases del
proceso.
Proporcionar medidas de apoyo hacia el proceso para mejorar el cumplimiento de los
requisitos establecidos.
4.2.1 Cubrimiento de la IC dentro del ciclo de vida de software en el modelo en
V
Modificado de: http://excelza.blogspot.com.co/2009/12/sobre-pruebas-de-software-y-servicios.html
El modelo que se propone resultado de esta investigación, iniciará desde la codificación,
dando como recomendación surtir la etapa de análisis y diseño con las respectivas verificaciones,
50
con el fin de contar con un aseguramiento de calidad desde el inicio del proyecto, como debe ser.
El modelo propuesto, aporta a la verificación del código y a las validaciones que se
requieren en el modelo en V proporcionándola automatización de las validaciones y la posibilidad
de realizarlo en metodología tradicional de desarrollo de software o a diario con el uso de una
metodología de desarrollo ágil, como lo propone Martin Flower, se deberá integrar mínimo una
vez al día por cada desarrollador del equipo del proyecto.
4.2.2 Vista de Modelo de Integración Continua en Ciclo de Vida del Software
(Metodología Tradicional)
Figura 4. Aseguramiento de la calidad del software apoyado en IC visto en metodología
tradicional.
Fuente: Autor
51
En la Figura anterior podemos tener la visión de la integración continua en una metodología
tradicional, se pueden apreciar los procesos en los que genera apoyo y automatización de los
procesos. Sin embargo la metodología tradicional propone realizar integración de código fuente y
pruebas funcionales hasta cerrar la etapa de desarrollo, lo que no permitiría apreciar las bondades
del esfuerzo realizado al automatizar procesos, si bien la automatización de pruebas funcionales
reduce sustancialmente los tiempos de ejecución de pruebas y las hace confiables, si se llega a
encontrar algún tipo de defecto en el código puede resultar complicado en algunos casos para el
desarrollador realizar la solución, en vista que al solucionar la parte que está fallando, puede
impactar otra que ya se había probado, generando reprocesos en el proceso de pruebas funcionales
y desarrollo.
4.3 Propuesta de Modelo de Integración Continua para Entornos de Desarrollo Ágil
Para efectos de calidad en el desarrollo software en la mayoría de las empresas de desarrollo
se cuenta con un repositorio de Código Fuente administrable, pero la totalidad de las
funcionalidades del aplicativo no se utilizan, desperdiciando cerca del 50% de las posibilidades
que brinda una aplicación para este fin.
Una forma de aprovechar la implementación continua en metodologías tradicionales es
planear el desarrollo de manera que las funcionalidades o módulos se vayan generando de manera
iterativa, dentro de una misma iteración, esto permitirá integrar varias veces antes de terminar la
etapa de desarrollo de la iteración, de esta manera se tendrá certeza de que cuando se despliegue
el producto en pruebas funcionales, se ejecutará el código sin interrupciones, permitiendo una fase
de pruebas sin Stoppers o errores bloqueantes.
El modelo propuesto en la Figura N° 5. Ilustra que hace necesario realizar los siguientes
pasos:
52
1) Contar con un repositorio para código Fuente (Control de versiones)
2) Automatización de Pruebas Unitarias
3) Revisión Estática de Código
4) Realizar Integración Diaria en un servidor de IC
5) Automatización de Pruebas Funcionales
6) Automatización de Despliegues
Figura 5. Aseguramiento de la calidad del software apoyado en IC visto en metodología
ágil.
53
Fuente: Autor
Para iniciar nuestro modelo de integración continua debemos contar con el aseguramiento
de la calidad de las etapas de análisis y diseño, con sus respectivas pruebas (validaciones), las
cuales fueron descritas en el marco teórico. El diseño me garantiza una línea base definida, unos
estándares de programación documentados y divulgados a mi equipo de desarrollo.
54
La primera herramienta que se debe implementar es Repositorio de Control de Versiones
(Administrador de Versiones), con la configuración del proyecto de Software y los permisos
necesarios para el equipo de desarrollo. Entre estas herramientas tenemos Team Foundation
Server, Subversion, CVS y otros (Ver 4.1 Comparativo de Herramientas)
Pero el modelo realmente comienza cuando los desarrolladores inician la codificación,
igualmente deberán construir (automatizar) la prueba unitaria para la porción de código. Al inicio
se tornará pesado para los desarrolladores, pero a medida que el desarrollo vaya avanzando y se
realicen las pruebas integrales, se verá el valor de estas pruebas, ya que solo se construyen una
sola vez y se reutilizarán durante la construcción del proyecto cada que se modifique algún
componente que se relacione con la porción de código implicada. Para este punto tenemos
herramientas como NUnit, JUnit, MbUnit, PHPUnit y otros, estas herramientas varían
dependiendo del lenguaje de programación que se utilice (Ver 4.1 Comparativo de Herramientas)
De la misma manera que las pruebas unitarias, se deberá configurar la herramienta de
revisión estática de código, basada en los estándares de programación definidos por la empresa y
con las métricas que cumplan las expectativas de medición que se plantee para el éxito del
proyecto. Entre estas herramientas tenemos: Sonar y otros.
Una vez es comprobado el funcionamiento del código, el desarrollador ejecuta la
integración en su equipo de su código fuente contra el código fuente que se encuentra en el
repositorio de control de versiones, si se presentan defectos el desarrollador deberá solucionarlos
y realizar de nuevo las pruebas unitarias y deberá realizarlo cuantas veces se presenten
inconvenientes; una vez sean sorteados los impases, se procederá a actualizar en el repositorio de
código fuente, cuando se publica la nueva versión se inicia la comunicación con el Servidor de
Integración Continua. Entre los servidores de integración continua tenemos: Hudson, Bamboo,
Cruise Control, y otros.
55
Se debe construir un comando único para todo el aplicativo (comimt), después del comimt
el administrador de integración detecta el cambio, toma del repositorio las últimas versiones y
ejecuta los scrips de construcción (comimt) que forman todo el Software, el servidor de integración
continua ejecuta las pruebas, realiza la integración de la base de datos (si es que hubiese) y
construye el software.
Figura 6. Practicas del trabajo SCM
Fuente: Autor
Luego comunica a la herramienta de análisis estático de código para iniciar la verificación
de código, la herramienta revisa los aspectos de calidad del software, los estándares de código,
muestra el código repetido, el cubrimiento de las pruebas en porcentaje y el tipo de complejidad
ciclomática del código (medida cuantitativa de los ciclos diferentes que se encuentran en un
fragmento de código, la herramienta de verificación de una vez ejecutada la inspección al código,
entrega los informes de las métricas de la calidad del código fuente que se configuraron
inicialmente.
El Administrador de integración continua informa por e-mail a cerca de los resultados de
la compilación a los miembros del grupo configurados en él. El administrador de integración
Continua realiza inspección de nuevas versiones con la frecuencia que se programe. Si existen
inconsistencias en el proceso de integración continua, el desarrollador responsable solucionará el
56
defecto, en caso que sea de gran magnitud, deberá ser apoyado por todo el equipo de desarrollo,
para poder continuar con nuevas porciones de código
Si no existen fallos, el servidor de integración continua despliega el software en el
servidor de pruebas Funcionales automáticas, el cuál de acuerdo con la programación
realizada ejecutará las pruebas y entregará la información resultante de ellas al Servidor de
IC, esté publicará los resultados a modo de tablero de Control. Posteriormente el Servidor
de IC de acuerdo a su programación podrá desplegar en ambientes de pruebas de calidad,
de pruebas de usuario y en Producción las versiones de código que han cumplido con todo
el ciclo de integración Continua.
4.4 Precondiciones para implementar Integración Continua
1. Concienciar al equipo de desarrollo de realizar integraciones con frecuencia, en
metodologías ágiles es su razón de ser, pero en metodologías tradicionales se espera hasta
finalizar el proyecto, se podría plantear en una metodología tradicional, construir por
módulos e ir integrando sus funcionalidades, es decir realizar integraciones de manera
iterativa dentro de una iteración.
2. Crear el hábito en el equipo de desarrollo de la realización de pruebas unitarias de cada
porción de código
3. En la empresa donde se quiera implementar Integración Continua deberán existir los
procesos de Gestión de la Configuración, Gestión de Despliegues documentada y
divulgada, de manera que el modelo de integración Continua se ajuste a los procesos y
procedimientos planteados y se conserve un estándar de estos procesos para todos los
proyectos.
4. Las competencias de las personas que se van a involucrar en el proceso de integración
continua, estará enfocado a profesionales de sistemas con conocimientos en Arquitectura
57
de Software, altos estándares de codificación (dependiendo del lenguaje de programación
utilizado), desarrolladores con formación y vocación para metodologías ágiles, con
capacidad para el trabajo colaborativo y sean propositivos a la hora de solucionar
problemas
5. Se deberá definir los roles del equipo de desarrollo con el fin de determinar fácilmente la
configuración de las notificaciones que va a arrojar el Servidor de Integración Continua
6. Se deberá definir quién administrará la configuración del Servidor de Integración Continua
y de cada uno de sus componentes. Para ello se debe tener en cuenta que el Servidor de
Integración Continua que se adquiera debe permitir la creación de usuarios, creación de
grupos y roles, configurar seguridad por usuario y otros.
4.5 Ventajas de la integración continua
Las ventajas que aporta la integración Continua al aseguramiento de la calidad en el ciclo
de vida del desarrollo del software se han evidenciado a la largo de este documento, sin embargo
este apartado se encargará de resumirlo
Si se llegase a implementar Integración Continua el proceso de desarrollo de software de
una compañía contaría con:
Una metodología de desarrollo definida, divulgada y aplicada
Estándares de generación de código definidos, divulgados y aplicados
Revisión de código diaria lo que da certeza al punto anterior
Ambientes estables de desarrollo y pruebas
Equipo de Trabajo de alta calidad (disciplina, conocimiento e innovación)
58
Equipo de Trabajo con aptitudes colaborativas
Tablero de control en tiempo real del estado del proyecto
Roles Establecidos para la ejecución de tareas
El control de la complejidad del código reduce los riesgos del desarrollo de software.
Control total de los despliegues de aplicaciones
Comunicación asertiva en cada etapa del ciclo de vida de desarrollo del software
Capacidad de reacción a los errores
Capacidad de reacción a los cambios en los requerimientos del proyecto
Clientes satisfechos con los tiempos de ejecución del proyecto
Clientes satisfechos con la calidad del producto
Clientes satisfechos con la calidad del proyecto
4.6 Desventajas de la integración continua
Las desvtajas que se pueden evidenciar al tomar la desición de implementar la integración
Continua para buscar el aseguramiento de la calidad en el ciclo de vida del desarrollo del software
se presentan a continuación:
La mayoría de los desarrolladores consideran las pruebas unitarias una perdida de tiempo,
por lo general sus pruebas consisten en compilar y ejecutar su porción de código, no se documenta
la prueba, no se evidencia la ejecución de las mismas. Crear la cultura de realizar pruebas unitarías
y más si se deben codificar para automatizarlas, será todo un reto para la organización.
El ser humano es siempre reacio al cambio, el hecho de traer una herramienta para
automatizar un proceso manual tendrá poca acogida en todo el equipo y aún más complicado
si no se lleva una sino varias herramientas al tiempo. Implementar Integración Continua se
deberá manejar como un proyecto más de la compañía, deberá tener presuspuesto para
capacitaciones y talleres de aceptación del cambio
59
Dependiendo de la compañía el proceso de implementación de Integración Continua
durará un tiempo determinado, sin embargo si la compañía ya cuenta con repositorio de código
fuente, si cuenta con base de conocimiento de pruebas unitarias y funcionales (Casos de Prueba
reutilizables), el tiempo de implementación será razonable, si la compañía iniciará su
implementación de cero, deberá iniciar con una buena planificación de proyecto y darse un
tiempo prudencial para la con figuración de herramientas.
Se debe realizar una inversión inicial en Hardware, si bien la mayoría del software es
open source, se deberá contar con máquionas que alojen las herramientas y su procesamiento
además del Servidor de integración Continua y la comunicación entre ellas.
Para lograr una buena implementación no solo es necesario no solo es necesaria la
inversión en equipo y software sino que se necesita personal idoneo para la configuración,
administración de las herramientas, también se requiere de personal con alto conocimiento en
codificación, se podría contar con desarrolladores Junior, pero guiados por desarolladores
Senior que los formen y auditen en su trabajo, y contar con coordinador o líder de proyecto
que realice el control y seguimiento, genere las alertas y brinde soluciones a los imprevistos
que se presenten.
Para el proceso de pruebas funcionales las personas de calidad, deberán tener un alto
perfil, donde ellos programen sus pruebas automátizadas, sepan interpretar los resultados que
arroje la herramienta y realicen las pruebas que no se pueden automatizar (no todo es
automatizable). El personal de QA deberá tener altos conocimiento en generación de
escenarios y casos de prueba de manera que se pueda aprovechar al máximo la herramienta de
autimatización de pruebas.
60
Conclusiones
La implementación de IC representa agilidad en los procesos de validación y verificación
del modelo en V para el ciclo de vida del desarrollo de software, ya que permite automatizar
acciones que se realizan en muchas compañías de manera manual o por el mismo tiempo que
implica en la ejecución del proyecto son obviadas.
Al incluir las herramientas que conforman la integración continua, se garantiza contar con
la información en tiempo real de la ejecución del proyecto, al convertirse el servidor de Integración
Continua en el Tablero de Control del proyecto.
Implementar un servidor de integración continua puede resultar un poco complicado al
principio. Si se desea montar el modelo completo, existen muchas herramientas y opciones de
configuración, lo cual hace difícil tomar decisiones de adquisición, sin embargo antes de realizar
cualquier acción se debe estructurar el proyecto para identificar que partes del proyecto deben
priorizarse para la automatización.
Existe una gran cantidad de herramientas en el mercado de acceso económico (open
source), que facilitan tomar la decisión de avanzar hacia la práctica de integración continua, es
cuestión de investigar la integrabilidad con las plataformas, la infraestructura y los lenguajes de
programación utilizados en la compañía para dar este paso.
El costo puede parecer elevado inicialmente, pero se debe tener en cuenta que todo lo que
se realice al principio es reutilizable en el mismo o en otros proyectos, por la misma razón se debe
documentar la estructuración de los proyectos y de esta forma al reutilizar uno anterior solo se
deberán ajustar las rutas en los scripts de compilación, seguir enriqueciendo las pruebas unitarias
y las pruebas funcionales. Cada vez la construcción será más pequeña y se contará con una sólida
base de conocimiento en el área de desarrollo.
61
Realizando la comparación de los beneficios que trae la implementación de la práctica de
integración Continua, se puede apreciar que se evidencia que el retorno de la inversión es mucho
más rápido y se perciben mayores beneficios al implementarlos en entornos de desarrollo de
software donde se aplican metodologías ágiles de desarrollo, el hecho de integrar y probar a diario
las porciones de código modificadas, permite detectar errores y solucionarlos rápidamente, si se
realiza en metodología tradicional, lo errores se detectarían en fases avanzadas del desarrollo, lo
que conllevaría a no ser identificados fácilmente los errores y costaría mucho más su resolución
en cuanto a tiempo y costos, lo que siempre hace tediosa la fase de despliegue, lo que precisamente
logra la integración Continua, mitigar el pánico escénico de salir a producción.
Son más la ventajas que las desventajas que ofrece la Integración Continua en el paso al
aseguramiento de la calidad del software, si la empresa de desarrollo es pequeña puede iniciar con
pequeños pasos, pero siempre mirando al horizonte donde quiere llegar, adelantando procesos
como cultura de pruebas unitarias, creación de base de conocimiento de casos de prueba unitarios
y funcionales, de esta manera cuando llegue el momento de automatizar estos procesos no resultará
tan impactante para el equipo de trabajo.
.
62
Prospectiva
Esta investigación se puede continuar realizando la implementación del modelo propuesto,
llevando métricas de los procesos, de manera que se puedan aportar las cifras y estadísticas para
evaluación del modelo, a su vez proponer mejoras al modelo propuesto, basado en las métricas
que se tomen en el o los proyectos implementados con Integración Continua.
Otra investigación que se podría continuar, es investigar como las herramientas que apoyan
las etapas de Requerimientos y diseño de arquitectura, se podrían integrar al modelo, de manera
que al tener desarrollo de software por iteraciones se podría tener un tablero de control de la
totalidad del proyecto.
63
Recomendaciones
Cómo Elegir las herramientas a utilizar en la implementación de Integración Continua?
De acuerdo con la comparación de las características descritas en las tablas de los
procesos descritos en el punto comparación de herramientas que apoyan la Integración
Continua, se podrían identificar las herramientas que necesita el negocio de acuerdo con los
siguientes criterios:
1. Características de los entornos de desarrollo y pruebas de la organización
2. Necesidades de la organización en el mejoramiento del proceso de desarrollo de
aplicaciones
3. Análisis de inversión y agilidad en el retorno de la inversión esperada
4. Análisis de posibilidades de obtención de soluciones
5. Candidatizar las mejores opciones de acuerdo con tiempos de respuesta esperados
6. Tomar la decisión
64
Bibliografía
Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. “Agile software development methods
Review and analysis”. VTT Publications. 2002.
Beck, K... “Extreme Programming Explained. Embrace Change”, Pearson Education, 1999.
Traducido al español como: “Una explicación de la programación extrema. Aceptar el
cambio”, Addison Wesley, 2000.
Beizer B. “Software testing techniques (2nd ed.)”, ISBN: 0-442-20672-0, Van Nostrand
Reinhold Co, 1990.
Black R. “Managing the Testing Process, 2nd Edition”. ISBN 0-471-22398-0, Editorial Wiley,
2002.
Cámara Uruguaya de tecnologías de información (CUTI). http://www.cuti.org.uy/
Centro de Ensayos de Software (CES) .http://www.ces.com.uy, 2007.
Coad P., Lefebvre E., De Luca J. “Java Modeling In Color With UML: Enterprise Components
and Process”. Prentice Hall. 1999.
Dustin E., Rasca J., Paul J. “Automated Software Testing”, ISBN 0-201-43287-0, Addison
Wesley, 1999.
Dustin E., Rasca J., Paul J. “Automated Software Testing”, ISBN 0-201-43287-0, Addison
Wesley, 1999.
Fowler, M., Beck, K., Brant, and J. “Refactoring: Improving the Design of Existing Code”.
Addison-Wesley. 1999.
Highsmith J., Orr K. “Adaptive Software Development: A Collaborative Approach to Managing
Complex Systems”. Dorset House. 2000.
IEEE Standard Glossary of Software Engineering Terminology Institute of Electrical and
Electronics Engineers, ISBN: 155937067X, 1990.
Informacion extraida de: guia_de_ingenieria_del_software.pdf
65
Informacion extraida de: http://in2test.lsi.uniovi.es/pris2006/PRIS2006-PoloPiattini.pdf
Informacion extraida de: http://opensource.org
Informacion extraida de: https://ivanator.wordpress.com/2009/01/12/montando-un-entorno-
integracion-continua-hudson-ant-svn-netbeans/
International Software Testing Qualifications Board, Certified Tester Foundation Level Syllabus,
Version 2005. Extraido de: http://www.istqb.org/fileadmin/media/SyllabusFoundation.pdf
Jeffries, R., Anderson, A., Hendrickson, C. “Extreme Programming Installed”. Addison-Wesley.
2001
José H. Canós, Patricio Letelier yMª Carmen Penadés DSIC -Universidad Politécnica de
Valencia Camino de Vera s/n, 46022 Valencia {jhcanos | letelier | mpenades
Kaner C., Falk J., Nguyen H. “Testing Computer Software, 2nd Edition”, ISBN: 0471358460,
Wiley, 1999.
M. Flower. Continous Integration – Improving software Qality and Reducing Risk. Estates
Unidos. Pearson Education, 2007 .p. 23
Macario Polo Usaola y Mario Piattini Velthuis Grupo Alarcos - Departamento de Tecnologías y
Sistemas de Información - Escuela Superior de Informática Universidad de Castilla-La
Mancha Paseo de la Universidad, 4; 13071-Ciudad Real e-mail: [email protected],
[email protected]. http://in2test.lsi.uniovi.es/pris2006/PRIS2006-PoloPiattini.pdf
Métodologías Ágiles en el Desarrollo de Software
Myers G. “The art of software testing, 2nd edition”, ISBN 0-471-46912-2, John Wiley & Sons
Inc., 2004.
Poppendieck M., Poppendieck T. “Lean Software Development: An Agile Toolkit for Software
Development Managers”. Addison Wesley. 2003.
Schwaber K., Beedle M., Martin R.C. “Agile Software Development with SCRUM”. Prentice
Hall. 2001.
Software Test Automation, Effective use of test execution tools. Mark Fewster & Dorothy
Graham. ISBN 0-20133140-3
66
Stapleton J. “Dsdm Dynamic Systems Development Method: The Method in Practice”. Addison-
Wesley. 1997.
67
Glosario
Build: Es el total de etapas necesarias para la compilación, creación de entregables al
momento de ejecutar los test (funcional, unitarios, etc).
Commit: Es la operación que permite la validación de las actualizaciones del código fuente
existente en el directorio de trabajo local de la máquina del desarrollador por medio de la
herramienta de gestión de configuración.
IDE: (Integrated Development Enviroment) Es un entorno de programación que ha sido
empaquetado como un programa de aplicación, es decir, consiste en un editor de código,
compilador entre otras herramientas que ayudan al desarrollador en su tarea
Integración a los entornos de desarrollo de integrado (IDE): Los servidores de
Integración comúnmente brindan una serie de accesorios para que el desarrollador pueda
visualizar el estado de las aplicaciones a través de su herramienta de desarrollo. Entre los
IDE más conocidos tenemos: Eclipse, Visual Studio, NetBeans y otros.
Plan Maestro de Pruebas: Documento que describe el alcance, enfoque, los recursos y
planificación de las actividades de pruebas previstas. Identifica, entre otros, los elementos
de prueba, las prestaciones a ser probadas, las tareas de pruebas, quien realiza cada tarea,
el grado de independencia del probador, el entorno de pruebas, las técnicas de diseño de
pruebas y los criterios de entrada y salida a utilizar, y los motivos para cada elección, y
cualquier riesgo que requiera un plan de contingencia. Es un registro del proceso de
planificación de pruebas.
Procesos Agiles: Conocidos anteriormente como metodologías livianas, intentan evitar los
tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente
y los resultados
68
Open Source: es una expresión de la lengua inglesa que pertenece al ámbito de la informática.
Aunque puede traducirse como “fuente abierta”, suele emplearse en nuestro idioma
directamente en su versión original, sin su traducción correspondiente.
Se califica como open source, por lo tanto, a los programas informáticos que permiten el acceso
a su código de programación, lo que facilita modificaciones por parte de otros programadores
ajenos a los creadores originales del software en cuestión.
Scrum: Es un modelo de desarrollo ágil caracterizado por adoptar una estrategia de
desarrollo incremental, en lugar de la planificación y ejecución completa del producto.