Você está na página 1de 42

Time to Delivery!

Creando software listo para liberar









Jonathan Carrera Daz
Edgar Martnez Duarte

V 0.2






Release 1.0 is the beginning of your softwares life, not the end of the project. Your quality of life after
Release 1.0 depends on choices you make long before that vital milestone.
Michael T. Nygard










ndice
1. Resumen ........................................................................................................................................................... 3
En el presente documento se propone una serie de tcnicas y prcticas, as como una serie de
adecuaciones a los procesos que actualmente existen en conjunto con el uso de herramientas de
software con el fin de llevar a cabo liberaciones de sistemas de forma exitosa reduciendo el riesgo
de fracaso. .................................................................................................................................................................. 3
2. Glosario de Trminos .................................................................................................................................. 3
3. Antecedentes ............................................................................................................................................... 43
4. Problemtica ................................................................................................................................................ 54
5. Anlisis ........................................................................................................................................................... 65
5.1. Caso de Estudio ........................................................................................................................................... 6
5.2. Otras Metodologas .............................................................................................................................. 108
5.3. Herramientas ......................................................................................................................................... 119
6. Solucin Propuesta ............................................................................................................................... 1210
6.1. Diseo de la arquitectura ............................................................................................................... 1611
6.2. Desarrollo, pruebas y CI a la Agile ............................................................................................... 1812
6.3. Control de Versiones y CI ................................................................................................................ 2014
6.4. Pruebas (Unidad, Sistema, Estrs...) .......................................................................................... 2015
6.5. Deployement & Release .................................................................................................................. 2418
7. Anlisis Costo-Beneficio ..................................................................................................................... 2620
8. Conclusin................................................................................................................................................ 2620
9. Referencias .............................................................................................................................................. 2620
10. Apndices .............................................................................................................................................. 2721
1. Resumen ........................................................................................................................................................... 3
2. Glosario de Trminos ................................................................................................................................. 3
3. Antecedentes .................................................................................................................................................. 3
4. Problemtica .................................................................................................................................................. 4
5. Anlisis .............................................................................................................................................................. 5
5.1. Caso de Estudio ........................................................................................................................................... 6
5.2. QSSDP ............................................................................................................................................................. 8
5.3. Otras Metodologas ................................................................................................................................... 9
5.4. Herramientas ........................................................................................................................................... 10
6. Solucin Propuesta .................................................................................................................................... 12
6.1. QSSDP .......................................................................................................................................................... 12
6.2. Diseo de la arquitectura .................................................................................................................... 15
6.3. Desarrollo, pruebas y CI a la Agile .................................................................................................... 17
6.4. Control de Versiones y CI ..................................................................................................................... 18
6.5. Pruebas (Unidad, Sistema, Estrs...) ............................................................................................... 19
6.6. Deployement & Release ....................................................................................................................... 23
7. Conclusin..................................................................................................................................................... 24
8. Referencias ................................................................................................................................................... 25
9. Apndices ...................................................................................................................................................... 26













1. Resumen
En el presente documento se propone una serie de tcnicas y prcticas, as como una serie de
adecuaciones a los procesos que actualmente existen en conjunto con el uso de herramientas de
software con el fin de llevar a cabo liberaciones de sistemas de forma exitosa reduciendo el
riesgo de fracaso.
2. Glosario de Trminos
Liberacin de Software (delivery)- La liberacin de un producto de software se refiere a una
serie de tareas y esfuerzos enfocados en poner el producto a disposicin de los usuarios. La
liberacin implica que el producto de software se encuentre en ejecucin sobre el ambiente
productivo. Algunos de los aspectos ms importantes que se deben considerar como parte de la
liberacin son:
Construccin del producto
Configuracin del ambiente
Migracin de datos
Instalacin
Pruebas
Capacitacin
Soporte
Monitoreo
Optimizacin


Deployment - Se refiere a las tareas asociadas a la preparacin de la aplicacin para su
instalacin en un ambiente de ejecucin. El deployment no necesariamente implica la liberacin
del producto a los usuarios finales ya que se puede realizar un deployment a un ambiente de
pruebas. El deployment involucra el empaquetamiento del producto para convertirlo en un
artefacto ejecutable, la distribucin del artefacto ya sea a un servidor o en equipos cliente, la
configuracin del ambiente de ejecucin y la instalacin del artefacto ejecutable.

3. Antecedentes
Durante nuestra experiencia en Quarksoft hemos participado en diversos proyectos con
caractersticas muy distintas. Algo que parece ser una constante en la mayora de los proyectos
son los problemas que se presentan al liberar la aplicacin en el ambiente productivo.
Generalmente en esta etapa se presentan una serie de complicaciones que provocan un ambiente
de tensin muy caracterstico que lamentablemente se ha hecho familiar para quienes hemos
vivido la experiencia. Esta etapa se caracteriza por un ambiente general de tensin en el equipo
de desarrollo, impaciencia por parte del cliente y una gran presin sobre todo el equipo y en
particular sobre el arquitecto y el lder de proyecto. La razn de todos estos sntomas es la
incertidumbre que se tiene de que el producto pueda funcionar en el ambiente productivo de la
manera en la que se concibi. El riesgo de que pueda ocurrir algn problema durante la
liberacin del producto es alto y el costo asociado a la ocurrencia del problema puede ser mayor
an. Ciertamente nuestros procesos de desarrollo estn orientados a que la calidad del producto
est garantizada y para ello se tienen diversos mecanismos que nos ayudan a lograr este objetivo,
sin embargo es evidente que existe una deficiencia en la definicin de los procesos, en su
entendimiento o en nuestra efectividad al momento de aplicarlos.
Es incuestionable que los problemas surgidos durante la liberacin de un sistema tienen un costo
indeterminado en los desarrollos actuales (an aquellos de pequea y mediana escala) y por ello
es necesario que se puedan identificar las causas que originan esta desviacin ya que de otra
manera no es posible plantear soluciones efectivas. El propsito de este anlisis es proponer
mejoras a los procesos actuales que permitan llevar a cabo esta transicin de manera controlada.
En su forma ideal, el proceso de liberacin de un sistema debe ser como el resto de nuestros
procesos: repetible, medible, confiable y adaptable.
Con el fin de llegar a una propuesta que aporte un valor para la organizacin tenemos que partir
de un anlisis de nuestra situacin actual y de nuestras experiencias pasadas para conocer en
dnde estamos fallando y encontrar entonces qu podemos hacer para mejorar. De nuestra
propia experiencia podemos aportar prcticas que hemos aplicado y que han probado ser
benficas a nuestro proceso. La experiencia vivida durante el desarrollo y puesta en produccin
de MidasSistema X ha servido como fuente principal de inspiracin para esta propuesta que
resulta una suerte de postmortem donde analizamos lo que se hizo bien y lo que se hizo mal.
Aunado a nuestra experiencia estn las experiencias de toda una comunidad que se ha enfrentado
a problemas similares y que tambin nos pueden aportar beneficios. Por ello nuestra propuesta
parte del anlisis de los siguientes puntos:
Caso de estudio (Midas, NMP)
Nuestro proceso de desarrollo actual (QSSDP)
Manejo del delivery en otras Metodologas
Herramientas de apoyo
4. Problemtica
El delivery de un producto de software es un proceso generalmente doloroso para el equipo de
desarrollo debido mayormente a la incertidumbre que plantea la ejecucin en un ambiente
productivo. En trminos bsicos el problema del delivery se resume en trasladar una aplicacin
de un ambiente de ejecucin controlado por el equipo de desarrollo a un ambiente de ejecucin
productivo donde generalmente existen muchos factores impredecibles que son difciles de
replicar en los ambientes de pruebas.

Uno de los problemas ms graves del delivery es que an con nuestros procesos y mtricas no
somos capaces de estimar ni medir el costo en tiempo y esfuerzo que va a tomar la puesta en
produccin de la aplicacin. De acuerdo a nuestros procesos la liberacin es un mero trmite
cuyo costo no es considerable, sin embargo la realidad nos ha demostrado que la liberacin
requiere de planeacin, tiempo y esfuerzo y que generalmente este esfuerzo va ms all de
desplegar la aplicacin en el servidor productivo.

Es complicado cuantificar el costo generado por una liberacin no planeada ya que los costos
repercuten tanto del lado del cliente como de nuestro lado. El cliente puede estar perdiendo
dinero por cada da de retraso del producto en produccin. De nuestro lado, al no estar planeado
adecuadamente, la consecuencia es una desviacin en el plan que repercute en costos por los
recursos y tiempo no planeados adems de posibles sanciones econmicas establecidas en el
contrato de trabajo.

De manera general se pueden identificar los siguientes problemas asociados al delivery:
Situaciones o elementos no previstos (pueden ser de carcter tcnico, tecnolgico,
arquitectnico, de infraestructura o administrativo).
Deficiencias en el cumplimiento de los requerimientos no funcionales.
Nmero de defectos encontrados en produccin mayor a lo planeado.
Tiempo no planeado para la configuracin, estabilizacin y puesta a punto de la
aplicacin.
Dificultad para diagnosticar y resolver problemas de la aplicacin que no pueden ser
replicados en el ambiente de pruebas.

En las secciones subsecuentes se presenta un anlisis que pretende encontrar soluciones
concretas que nos permitan reducir el grado de incertidumbre que implica la liberacin de un
producto de software.
5. Anlisis
En esta seccin se describe de manera general el anlisis que se llevo a cabo para encontrar los
posibles puntos en los que estamos fallando como organizacin para garantizar un delivery
exitoso.
Para ello se estudi un caso en particular, que es el sistema MIDAS (sistema core de Nacional
Monte de Piedad) el cual es un claro ejemplo de la problemtica que estamos viviendo. Tambin
se consider importante analizar nuestros procesos para determinar si la causa de las principales
fallas es un seguimiento inadecuado de los procesos o es que nuestros procesos no nos proveen
de gua suficiente para alcanzar el objetivo de delivery y por ltimo se llevo a cabo un anlisis de
algunas herramientas que nos pueden facilitar las tareas para lograr el objetivo deseado.

5.1. Caso de Estudio
MidasSistema X es la aplicacin que da soporte a la operacin diaria de NMP en ms de 200
sucursales distribuidas en el territorio nacional. MidasSistema X es probablemente el sistema de
mayor escala que se ha desarrollado en QuarksoftLa Empresa y debido a eso es que su liberacin
ha sido una de las ms complicadas que hemos experimentado.

El anlisis de lo sucedido durante la liberacin de MidasSistema X nos llev a identificar los
problemas que se presentaron y sus posibles causas (ver Apndice A). A pesar de que los
problemas identificados pueden parecer muy particulares de la aplicacin, en el fondo se puede
detectar que las causas tienen su origen en decisiones o acciones ejercidas en etapas anteriores.

Las decisiones que se toman en etapas tan tempranas como preanlisis o Diseo de Alto Nivel
(HLD) son fundamentales para que el producto final pueda funcionar en un ambiente productivo
de la manera en que fue concebido. A partir del anlisis de los problemas identificados en
MidasSistema X hemos determinado una clasificacin que generaliza los problemas
identificados:
1. Arquitectura
Seleccin tecnolgica inadecuada (seleccin basada en tendencias de las
comunidades de desarrollo, seleccin basada en solicitudes poco fundamentadas
del cliente).
Insuficiencia en anlisis de factibilidad (infraestructura disponible, atributos de
calidad, tecnologa).
No se llevan a cabo pruebas de concepto como una prctica comn.
1. Ambiente
Indefinicin del ambiente productivo desde etapas tempranas del desarrollo.
Diferencias entre el ambiente de desarrollo/pruebas y el ambiente productivo
No contar con un ambiente de pruebas de sistema que sea lo ms cercano posible
al ambiente productivo.
Capacidad para almacenar/replicar/recrear ambientes completos para pruebas.
2. Tecnolgico/infraestructura
Subestimacin de requerimientos de infraestructura y/o tecnolgicos.
Disponibilidad de hardware y software que permita crear ambientes de prueba
semejantes al ambiente productivo.
Dificultad para determinar con precisin los requerimientos en infraestructura
requeridos por la aplicacin (servidores, memoria, capacidad de procesamiento,
almacenamiento, ancho de banda, etc.)
Carencia de una base de conocimientos y mejores prcticas.
No contamos con institucionalizacin de software para: diseo y arquitectura,
modelado de datos, monitores de mtricas de performance, automatizacin de
pruebas de capacidad.
3. Desarrollo
Falta de identificacin de componentes crticos para su asignacin y cuidado de
aspectos crticos del diseo.
Incompetencia tcnica de los ingenieros (deficiencia en POO, desconocimiento
del lenguaje, poca capacidad de investigacin, profesin errada)
4. Pruebas
Pruebas de capacidad se dejan hasta el final si es que se llevan a cabo.
Pruebas unitarias/integrales deficientes (pruebas de happy path).
Pruebas de sistema no automatizadas.
Pruebas de despliegue inexistentes.
No hay lineamientos ni guas para generar pruebas de capacidad.
Concepto de Integracin Continua mal entendido.
5. Administracin de la configuracin
Uso inadecuado del repositorio.
Scripts de configuracin inexistentes.
Scripts de configuraciones no versionados.
Scripts de BD no versionados.
Liberaciones no versionados.
Liberaciones no documentados (features, fixes, known bugs, etc.)
6. Metodologa
No existe un plan de liberacin.
No existe una estrategia de liberacin.
La estrategia de pruebas se ha convertido en un formato ms que hay que llenar
para cumplir con los procesos.
No existe estrategia/plan de soporte.
No existen guas o mejores prcticas para la actividad de soporte.
No existe un plan de transicin de la nueva aplicacin hacia el personal de
operaciones del cliente.
Nuestros procesos ven la liberacin como un mero trmite administrativo no
como una transicin en la que intervienen muy diversos factores que hay que
medir y controlar para alcanzar el objetivo.
7. Administrativo
Cmo establecer estrategias de interaccin con el cliente y otros proveedores
involucrados.
Cmo manejar la Tercerizacin del desarrollo (interaccin con otros
proveedores).

Cabe sealar que algunos de los problemas mencionados salen del alcance de la presente
propuesta ya que involucran un anlisis ms profundo y la participacin de otras reas como
Recursos Humanos. Nuestra propuesta se enfoca mayormente en el aspecto tcnico/tecnolgico y
metodolgico del rea operativa.



5.2. QSSDP
Fase de Estimacin y Planeacin
Proceso de Preanlisis: En s el proceso es bastante claro en cuanto a su alcance y
propsito. El problema que hemos detectado es durante la ejecucin del proceso. Son
muchas las ocasiones en las que no se le dedica el tiempo suficiente al preanlisis o no se
le da la importancia necesaria. Otra observacin del proceso de preanlisis es que si parte
de un anlisis muy superficial o con informacin limitada, la lista de componentes y la
estimacin es generalmente una aproximacin muy lejana a la realidad.
Formato para la estimacin de recursos crticos de computadora: En este template se
mencionan aspectos relacionados al hardware como: memoria, espacio, procesamiento
que son importantes para la operacin de la aplicacin durante el desarrollo y puesta en
produccin. Sin embargo no se consideran los recursos necesarios para realizar las
pruebas correspondientes al sistema.
Fase de aceptacin del proyecto
Forma STRAT: Este formato contiene la estrategia completa del proyecto. Todas las
actividades y artefactos entregables se definen en este formato para ser adecuadamente
planeados y contemplados en los costos asociados al proyecto. El proceso en si es claro y
adecuado. Las fallas generalmente provienen de la falta de comunicacin o experiencia
tanto del lder de proyecto como del arquitecto. Actualmente en la mayora de proyectos
realizados por Quarksoft no se contemplan en la estrategia todos los recursos y
actividades necesarias para realizar las pruebas, as como capacitacin de los ingenieros
en herramientas necesarias para realizar las pruebas durante el desarrollo del proyecto.

Fase de desarrollo
SPMP (Plan de Administracin del Proyecto de Software): Este proceso define la
estrategia de desarrollo sin embargo no contempla una estrategia de deployment. El
deployment no debe ser visto como una tarea que se inicia slo al finalizar el desarrollo
del producto.
SDP (Plan de Desarrollo de Software): En este formato se definen todas las tcnicas y
prcticas relacionadas con el desarrollo de la aplicacin, sin embargo no se menciona
ninguna prctica que el equipo deber seguir durante el desarrollo, con el propsito de
garantizar el delivery.
Plan de Pruebas: En este formato se define todo lo referente a las pruebas. Una parte
importante que se incluye en este formato son los requerimientos de los ambientes de
pruebas, sin embargo, como sucede con muchos otros formatos del proceso, no se utilizan
con plena conciencia y se terminan rellenando las secciones con el nico propsito de
cumplir con el proceso. Generalmente este formato se llena como un requisito durante el
lanzamiento de la fase de desarrollo cuando debiera ser un documento que debe ser
responsabilidad del arquitecto una vez concluido el HLD que es cuando se tiene plena
conciencia de la arquitectura, los atributos de calidad y el tipo de componentes que se
contemplan.
SRS: En este formato se registran principalmente los requerimientos tanto funcionales
como no funcionales, sin embargo a lo largo de los proyectos, no siempre se fijan las
mtricas correctamente, resultando un tanto ambiguas y complejas de medir.
Estrategia y Plan de Liberacin: Tras revisar todos los procesos y guas del QSSDP no
encontramos alguno que hablara especficamente sobre la planeacin de actividades
enfocadas a la liberacin del producto. Pareciera que se parte de la premisa de que todos
los procesos de desarrollo y pruebas son suficientes para que al final del ltimo ciclo de
desarrollo la aplicacin sea liberada en el ambiente productivo sin ningn problema.
5.3.5.2. Otras Metodologas
RUP
Rational Unified Process (RUP) es una de las metodologas de desarrollo de software ms
conocidas y aceptadas dentro de la industria. RUP es un proceso que puede ser descrito en dos
dimensiones. En el eje horizontal divide el ciclo de vida del proyecto en cuatro fases de las
cuales la ltima de ellas (Transition) es dedicada a transferir el producto de software de un
ambiente de pruebas a su ambiente final en produccin. Dentro de las nueve disciplinasAl mismo
tiempo verticalmente se divide en 6 disciplinas de ingeniera y 3 de soporte, entre las que se
encuentran: Business modeling, Requirements, Analisis and Design, Implementation, Test y Dse
incluye el deployment. que es elEste ultimo es el conjunto de tareas enfocadas a poner el
software a disposicin de los usuarios. La disciplina de deployment se intensifica en la fase de
Transition por obvias razones, pero existen algunas actividades relacionadas con esta disciplina
que se inician desde etapas anteriores (Elaboration y Construction). Tambin es importante
sealar que las tres disciplinas de soporte: Configuration & Change MgmtManagement., Project
Management y Environment sirven como apoyo para alcanzar los objetivos de la fase de
Transition.

Una de las actividades importantes de la disciplina de deployment, es la elaboracin del artefacto
Plan de Deployment en el que se detallan aspectos importantes que deben ser cubiertos durante
la fase de transicin tales como: identificar factores de compatibilidad, estrategias de migracin y
conversin de datos, establecer una agenda para las actividades de deployment, definir una
estrategia de deployment y determinar un plan de capacitacin.

Scrum
Scrum es una de las metodologas mas populares entre las metodologas de desarrollo de
software agiles; es por ello que se llevo a cabo un anlisis especfico de cmo esta metodologa
administra la fase de release.
Una de las principales actividades es definir el Realease Planning, as como el Release Planning
Meeting. El propsito de Release planning es definir los contenidos de una liberacin o
especificar el incremento de un producto entregable. Esto supone identificar y asegurar lo
siguiente:
Un objetivo por cada liberacin.
Un conjunto de requerimientos de mayor prioridad que sern desarrollados en la
liberacin.
Una estimacin poco granular por cada requerimiento
Una fecha para la liberacin

La regla de oro en el Release Planning es no ir al detalle, no es responsabilidad del Relaese
Planning precisar el detalle. Los planes de liberacin deben ser imprecisos, slo cuando el equipo
inicie los trabajos de liberacin, entonces tendr retroalimentacin y empezar a entender que
tan rpidamente se avanzar y cuanto puede ser logrado.

El propsito del release planning meeting, es que cada persona en el equipo entienda y se
comprometa a entregar la liberacin convenida en la fecha acordada, En esta junta debern estar
presentes: el dueo del producto, cualquier otro stakeholder que pueda agregar valor a la junta.

La junta debe tomar el siguiente camino:
1. El dueo del producto explica el objetivo de la liberacin al equipo.
2. Los desarrolladores proporcionan su productividad del equipo. Si el equipo no ha
cambiado, la productividad debera ser el nmero de iteraciones en la liberacin
multiplicado por la productividad de la ultima iteracin.
3. De acuerdo al valor, el dueo del producto introduce cada una de los requerimientos a los
desarrolladores.
4. Los desarrolladores preguntan lo suficiente acerca de los requerimientos hasta ser
capaces de constatar las estimaciones poco granulares.
5. Los desarrolladores evalan los riesgos tcnicos por cada requerimiento y proporcionan
algunas calificaciones, por ejemplo. Alto, medio o, bajo.
6. Dado el objetivo de la liberacin y tomando en cuenta los valores, estimaciones o costos
y riesgos, el dueo del producto, el dueo del producto selecciona los requerimientos de
su lista y hace el plan de liberacin.
7. Se realiza un consenso de las necesidades que sern cubiertas en el plan de liberacin con
cada uno de los presentes.

5.4.5.3. Herramientas
1

Fue necesario realizar un anlisis de herramientas que nos puedan ayudar a llevar a cabo tareas
asociadas a lograr una liberacin exitosa. Principalmente para llevar a cabo pruebas de unidad,
integracin y sistema existen libreras/frameworks que hemos adoptado dentro de la organizacin
para apoyarnos al realizar estas actividades, sin embargo cuando se trata de realizar pruebas de
capacidad, desempeo o concurrencia nos encontramos con que no hay una normatividad que
nos proponga, sugiera u obligue a utilizar alguna herramienta particular. Sin esta gua es muy
fcil perderse entre todas las herramientas que encontramos disponibles en Internet. Por eso es
importante contar con un catlogo de herramientas que provea alguna gua sobre las capacidades
de cada herramienta y preferentemente un tutorial para poder obtener beneficios de la

1
Para mayor detalle sobre este anlisis vase apndice D
herramienta en un corto tiempo y no perder tiempo buscando en la documentacin cmo obtener
un funcionamiento bsico. Aunque existen muchas herramientas no comerciales, en ocasiones no
proveen todas las ventajas que ofrecen algunas herramientas comerciales. A continuacin se
muestra una lista de las herramientas que fueron analizadas y sus principales caractersticas.

Generadores de carga:
Un generador de carga permite simular picos de carga sobre servidores, redes u otros objetos,
permitiendo as encontrar fcilmente cuellos de botella en las aplicaciones.

Herramientas analizadas:
JMeter (Apache):
Silkperfomer (Borland):

Profilers
Hoy en da las aplicaciones han ido cambiando, a tal grado de tener aplicaciones distribuidas,
virtualizadas, clusterizadas, etc.; por lo que desarrolladores, reas de calidad y hasta los dueos
del negocio tienen que trabajar de manera conjunta para poder maximizar el valor del negocio.
Por lo anterior, es difcil liberar una aplicacin sin problemas de desempeo, consumos mnimos
de anchos de banda, cuellos de botella, optimizacin de algoritmos entre otras cosas. Abajo se
muestran las caractersticas de algunas herramientas que ayudan en la solucin de problemas de
este tipo.

Herramientas analizadas:
JConsole (Oracle, OpenSource)
Dynatrace (Comercial)
JProfiler (Comercial)
Yourkit (Comercial)

Automatizacin de pruebas

Herramientas analizadas:
TestMaker

6. Solucin Propuesta
De acuerdo a los objetivos perseguidos y a partir del anlisis realizado en el capitulo anterior, se
pueden formular una serie de propuestas de mejora que repercutan directamente sobre las
liberaciones de sistemas desarrollados por Quarksoft.

Estas propuestas de mejora estn planteadas con la intencin de generar un beneficio
significativo a los equipos de desarrollo dentro de Quarksoft. Estas propuestas, se enfocan
principalmente en el QSSDP, Diseo de Alto Nivel, Diseo de la arquitectura, Administracin de
la Configuracin, Pruebas e Integracin Continua.

6.1. QSSDP
Fase de Estimacin y Planeacin
Proceso de Preanlisis: Normalmente este es un proceso cuya duracin es determinada
parcialmente por las necesidades del cliente. En ocasiones se reciben requisiciones de
propuestas para participar en un concurso en el que se requiere una respuesta en un
periodo de unos poco das.
En este caso lo nico que proponemos es buscar u obtener la mayor informacin
posible de ser posible mediante juntas con el cliente o asignar a un arquitecto con
la suficiente experiencia para proponer una solucin viable, ya que
desafortunadamente, la persona que desarrolla las propuestas inciales es aquella
que no est asignada a un proyecto, lo cual no siempre lleva a que esta persona
sea la ms adecuada para proponer una solucin.
Seguir el procedimiento de diseo de arquitectura basado en la identificacin de
requerimientos de negocio y atributos de calidad. En la medida de lo posible
evitar generar propuestas al vapor que se solicitan con dos o tres das de
antelacin.
En muchas ocasiones se parte de un anlisis muy superficial o con informacin
limitada, la lista de componentes y la estimacin es generalmente una
aproximacin muy lejana a la realidad. La propuesta en este punto es que en casos
en los que de antemano sabemos que nuestro anlisis no es suficientemente
profundo, el lder del proyecto debe tratar de negociar de antemano con el cliente
una reestimacin posterior cuando se hayan determinado todos los requerimientos
y se haya definido una lista de componentes ms acorde a la realidad.
Formato para la estimacin de recursos crticos de computadora: Adems de los
aspectos que ya cubre el documento, proponemos que se deberan establecer todos los
aspectos importantes para configurar un ambiente de pruebas similar o equivalente al que
se espera tener en produccin para llevar a cabo nuestras pruebas durante todos los ciclos
de desarrollo. Si de antemano se conoce el sistema operativo y la versin que se usar, es
importante buscar tener ese mismo sistema operativo en nuestro ambiente de pruebas, si
sabemos que la aplicacin requiere ser clusterizada, es importante considerar tener un
cluster con al menos 2 nodos para las pruebas de sistema. El servidor de aplicaciones y el
servidor de la base de datos que se van a utilizar tambin deben especificarse en conjunto
con las especificaciones para cada ambiente necesario durante el desarrollo. Ya que hoy
en da slo se mencionan los recursos crticos para el desarrollo, pero igual de crticos son
los recursos para realizar pruebas.
Fase de aceptacin del proyecto
Forma STRAT: En lo que respecta al delivery, se debe contemplar en la estrategia todas
las actividades y recursos necesarios para habilitar los ambientes necesarios para las
pruebas y la capacitacin a los ingenieros en las herramientas que se requieran durante las
pruebas. Se debe considerar tambin tiempos para llevar a cabo el proceso de
deployment. Normalmente se llega a esta etapa y ya no hay una tarea especfica para
registrar este tiempo y as es muy complicado cuantificarla y generar datos histricos que
nos permitan medir el comportamiento y costos asociados a esta etapa.

Fase de desarrollo
SPMP (Plan de Administracin del Proyecto de Software): Creemos que el
deployment no debe ser visto como una tarea que se inicia slo al finalizar el desarrollo
del producto, por lo que proponemos que debera iniciar durante el proceso de desarrollo
en forma de despliegues parciales en puntos estratgicos del desarrollo, quizs al trmino
de cada ciclo o como mejor convenga de acuerdo al proyecto y al anlisis realizado por el
equipo. La intencin de los despliegues parciales es hacer ensayos en etapas tempranas
para observar el comportamiento de la arquitectura en un ambiente cercano al productivo.
Es importante monitorear con ello aspectos crticos funcionales, pero principalmente los
aspectos no funcionales. Detectar en forma temprana problemas arquitectnicos o de
diseo; sera vital para poder corregir a tiempo y evitar que el problema se detecte en
etapas posteriores, lo cual es mucho ms costoso de corregir segn nuestros datos
histricos sobre errores y la etapa de correccin.
SDP (Plan de Desarrollo de Software): Proponemos que en este documento se deben
documentar todas las posibles prcticas que el equipo deber seguir durante el desarrollo
con el propsito de garantizar el delivery. Muchas de las prcticas y tcnicas que
proponemos en este documento debieran incluirse como parte del plan de desarrollo para
que sirva como una gua para el equipo de las polticas y prcticas que deben seguir y
respetar.
Plan de Pruebas: Proponemos que sea un requisito establecer el ambiente requerido para
cada tipo de pruebas y apegarse a esa definicin con el fin de reducir riesgos durante la
implantacin. Tambin se reduce la posibilidad de discrepancias entre ambientes de
pruebas (e.g. en pruebas de unidad en el ambiente de un desarrollador pasa la prueba y en
el de otro(s) no pasa.). Cada ambiente tiene caractersticas y configuraciones distintas y
es importante identificarlas desde etapas tempranas del desarrollo. Incluso es posible
tener distintas versiones del ambiente productivo con condiciones distintas que sirvan
para realizar pruebas de capacidad (e.g. un ambiente de pruebas con una sola instancia,
un ambiente de pruebas clusterizado). Para cada ambiente deben considerarse todas las
caractersticas relevantes tales como: versin del sistema operativo, parches requeridos
del sistema operativo, versin de la mquina virtual de Java, versin del servidor de
aplicaciones, versin del servidor de aplicaciones, versiones de los sistemas operativos
cliente soportados, versiones de los navegadores soportados por la aplicacin, entre otros.
SRS: Es necesario establecer mtricas cuantificables ya que de otra forma el uso de
mtricas ambiguas se convierte en un riesgo al llegar a la etapa de liberacin.
Estrategia y Plan de Liberacin: La liberacin de un producto de software implica un
periodo de transicin que involucra tareas de monitoreo, estabilizacin, optimizacin y
puesta a punto de nuestra aplicacin. Tambin involucra tareas de capacitacin a usuarios
y transmisin del conocimiento tcnico, e incluso tareas relacionadas al soporte tcnico.
Otras metodologas como RUP consideran el deployment como una fase ms del proceso
de desarrollo con actividades y procesos muy particulares. Consideramos importante
incorporar en Quarksoft un proceso para planear desde un inicio del proyecto todas las
actividades, riesgos, tcnicas, y condiciones necesarias para llevar a cabo una liberacin
controlada. La estrategia de liberacin debe incluir todos los aspectos que rodean la
liberacin del producto y que requieren de un seguimiento continuo para evitar que se
salgan de nuestro control. Algunos de los elementos que debe contener este documento
son:
Lista de responsables de cada una de las reas que van a participar de alguna
forma en el proceso de liberacin de la aplicacin. Debe incluirse algn medio de
contacto y una descripcin breve de la intervencin dentro del flujo de la
liberacin.
Lista de supuestos, dependencias y restricciones.
Lista de ambientes requeridos para cada etapa de pruebas.
Estrategia de monitoreo de la aplicacin. Se deben establecer los mecanismos o
herramientas que se pretenden utilizar para poder monitorear diversos aspectos de
la aplicacin que permitan diagnosticar cualquier problema de manera rpida y
efectiva.
Descripcin del procedimiento para realizar un deployment en produccin.
Generalmente todas las empresas tienen polticas o protocolos especficos que se
deben seguir para realizar cambios en sus ambientes.
Plan de liberacin. Se debe definir si la liberacin va a ser gradual (para un
nmero limitado de usuarios bajo criterios como: perfil, situacin geogrfica,
funcionalidad, etc.) o global. Si la aplicacin va a sustituir a otra aplicacin se
debe planear una estrategia para llevar a cabo la transicin de la forma ms
conveniente para el negocio y los usuarios. Este plan debe definirse en conjunto
con el cliente.
Plan de contingencia. Debe determinarse el mecanismo mediante el cual puede
recuperarse el estado de la aplicacin luego de algn evento que rompa con la
continuidad de la operacin, as como establecer el tiempo mximo en que este
plan ser ejecutado, para poder garantizar la continuidad de la operacin.
Plan de recursos requeridos por la aplicacin en un ambiente productivo.
Determinar la tasa de crecimiento de la base de datos, ancho de banda requerido,
espacio en disco, memoria.
Plan de depuracin. Si la aplicacin genera muchos datos histricos o archivos
temporales es importante considerar algn mecanismo para depuracin.
Plan de migracin de datos. En ocasiones es necesario realizar migraciones de
datos de aplicaciones anteriores a la nueva aplicacin. Es importante definir la
estrategia que se va a seguir para llevarlo a cabo. Determinar el mecanismo y
establecer el procedimiento para llevar a cabo la migracin.
Estrategia de correccin de defectos. Determinar el procedimiento y herramientas
mediante los que los usuarios van a reportar los errores y la estrategia de atencin
de los errores.
Plan de liberacin para actualizaciones. Determinar el proceso que se va a seguir
para determinar las condiciones para liberar una nueva versin, los das y horarios
que se dispongan y el protocolo necesario para ejecutar la liberacin.
Plan de capacitacin/transicin. Es importante determinar las actividades para
transmitir los detalles tcnicos a los nuevos responsables de la aplicacin.
El Plan de Deployment contiene los detalles tcnicos del procedimiento para liberar una
versin de la aplicacin en el ambiente productivo.
Precondiciones para el primer deployment. Normalmente para el primer
deployment se requieren ciertas configuraciones adicionales que se hacen una sola
vez.
Lista detallada de los artefactos del deployment.
Procedimiento de deployment. Definir los pasos para realizar el deployment en
forma manual y de ser posible su automatizacin explicar tambin cmo ejecutar
el proceso de deployment automtico.
Procedimiento para ejecutar las pruebas de deployment.
Procedimiento de rollback del deployment en caso de que ocurra algn problema.
Ubicacin de las bitcoras de la aplicacin y una descripcin de lo que contienen.
Mecanismos de monitoreo disponibles para la aplicacin.
Documentacin de errores comunes y sus posibles soluciones.

6.2.6.1. Diseo de la arquitectura
El diseo de la arquitectura es una instancia fundamental en la que se puede definir el xito o
fracaso de un producto de software. La arquitectura de software es definida como un conjunto de
decisiones que determinan la estructura de una aplicacin. Una mala decisin o la omisin de
factores importantes pueden repercutir de manera importante en la consolidacin del producto
final as como en la calidad de vida de los integrantes del equipo de desarrollo.
Creemos que eEn la medida en que estas prcticas se lleven a cabo de manera sistemtica en
cada proyecto, el riesgo de que se presenten errores graves de diseo al liberar una aplicacin
ser mucho menor que en la forma en la que tradicionalmente se lleva a cabo el HLD.
Algunas de las prcticas que consideramos importantes en las actividades del diseo
arquitectnico son:
El diseo de la arquitectura se debe llevar a cabo antes de documentar el HLD como una
tarea independiente a la Creacin del documento de HLD, la cual debe ser planeada en la
estrategia como una tarea independiente que se debe planear desde un inicio.
En el diseo de la arquitectura debe participar el/los arquitecto(s) nicamente. La
participacin de los ingenieros generalmente no es productiva. Si el arquitecto lo
determina puede involucrar a algn ingeniero del equipo con mayor experiencia, pero no
debe ser como una imposicin sino como una decisin en conjunto del lder del proyecto
y el arquitecto para determinar las mejores condiciones para llevar a cabo la actividad. La
responsabilidad final sobre la arquitectura y las decisiones de diseo es siempre del
arquitecto.
El proceso de validacin de la arquitectura debe ser promovido y gestionado por el rea
de Operaciones. Es importante contar con disponibilidad planeada de otros arquitectos
para este tipo de actividades. Una sugerencia sera planear a los arquitectos al 8075% en
todos los proyectos para que exista la posibilidad de involucrarlos en alguna
evaluacin/estimacin/preanlisis.
La creacin de prototipos funcionales que demuestren la factibilidad de la arquitectura es
una prctica muy til y que tambin debe ser evaluada la necesidad de realizarlo desde un
inicioetapas tempranas del desarrollo, para que se considere en la planeacin.
Considerar la creacin/adaptacin del arquetipo del proyecto como una tarea o como
parte de la tarea de Diseo de la Arquitectura. El arquetipo constituye una parte
importante para que el desarrollo se inicie de manera ms rpida y controlada.
Considerar en el diseo todos las posibles variables del ambiente productivo que puedan
afectar nuestra aplicacin. Algunos aspectos importantes son: las caractersticas de la red,
caractersticas del servidor, caractersticas de los clientes, versiones de sistemas
operativos de servidor y clientes, requerimientos mnimos de operacin, sistemas
externos, repositorios, bases de datos, mecanismos de seguridad, versiones del navegador
soportadas(en caso de aplicaciones web), versin del manejador de base de datos, versin
del servidor de aplicaciones, entre otras.
Ser cuidadosos en la seleccin tecnolgica. Muchas veces nos dejamos llevar por las
tendencias e innovaciones y buscamos incorporarlas de inmediato en algn proyecto.
Antes de decidir introducir una nueva tecnologa hay que hacer un trabajo de
investigacin y de ser posible pruebas de concepto para asegurarnos de que cubre con
todas las necesidades de nuestro proyecto. Algunos aspectos que se deben cuidar son:
soporte del producto, el tamao de la comunidad de usuarios, casos exitosos actualmente
en produccin, tener en cuenta el tipo de aplicacin, s es una aplicacin web rica en
contenido, s es un aplicacin stand-alone, visitar los foros para darnos cuenta si hay
muchas quejas de bugs sin atender, los tiempos de respuesta a issues, limitaciones del
producto, su licenciamiento.
Solicitar el consejo de otros arquitectos. Formar un comit con otros arquitectos y Charlar
discutir con otros arquitectos acerca de las inquietudes que tenemos sobre nuestra
propuesta arquitectnica es una buena idea. Las experiencias de otros pueden enriquecer
nuestra arquitectura o darnos una visin distinta de las cosas. Mientras no contemos con
una base de conocimientos en la que podamos concentrar las experiencias y lecciones
aprendidas, la mejor manera sigue siendo el contacto directo entre colegas.
Ya que no se cuenta con una base de conocimientos sera bueno que se dedicar cierto
tiempo para que los arquitectos puedan compartir sus experiencias con las tecnologas
que han usado en proyectos reales (no cuentan los Hello World) y as contribuir a que
cada arquitecto pueda hacer una mejor eleccin a la hora de seleccionar una tecnologa.
6.3.6.2. Desarrollo, pruebas y CI a la Agile
Uno de los principios fundamentales del Manifiesto gil es satisfacer la necesidad del cliente a
travs de entregas tempranas y continuas de un software que aporte un valor desde el punto de
vista del negocio. De este principio nace el concepto de Continuous Delivery (CD) que se resume
en una serie de prcticas y patrones para producir desde etapas tempranas del desarrollo
versiones del software listas para proveer parcialmente funcionalidad que ofrezca un valor para
el cliente. La premisa principal detrs del concepto continuous delivery es que la mejor forma de
garantizar que el producto final pueda funcionar en un ambiente productivo como se concibi
originalmente, es mediante constantes ensayos en un ambiente que sea lo ms cercano posible al
ambiente productivo final. Para lograr una prctica real del CD es necesario cumplir con algunos
pre-requisitos y ponerlos en prctica para eventualmente lograr la madurez necesaria para hacer
liberaciones continuas.


Entre las practicas propuestas por CD, esta el uso de Continuos Integration el cual pretende una
integracin frecuente de cualquier cambio o cdigo nuevo existente en el repositorio, lo cual
recientemente se introdujo en La Empresa, sin un gran xito.

Para mejorar esta situacin y obtener el mayor beneficio de nuestro servidor de CI proponemos
los siguientes puntos que consideramos importantes:
Fomentar en el equipo la importancia de realizar una prueba bien hecha y que cada
commit de cdigo debe ir acompaado de sus respectivas pruebas funcionando
correctamente.
Transmitir al equipo la importancia de CI y motivarlos a cumplir con su objetivo.
Fomentar la prctica de check-ins frecuentes, al menos una vez al da.
Formatted: Font: 12 pt, Not Bold
Formatted: Left
Formatted: Font: 12 pt, Not Bold
Prestar atencin a las notificaciones de Bamboo para actuar de forma inmediata cuando
falle un build. Pero principalmente buscar tener el cuidado necesario al realizar un check-
in
Idealmente Bamboo debe ejecutar un build por cada commit en el trunk. La
recomendacin de los agilistas para este punto es: si duele, hazlo con ms frecuencia.
Considerar los reportes de Bamboo como elementos auditables durante las auditoras de
calidad. Mientras no se vuelva parte integral de nuestros procesos, no existe forma de
medir ni cuantificar la eficacia de nuestra herramienta de CI. Otro beneficio es que al ser
un elemento auditable estamos obligados a cumplir con l. A nadie le gusta hacer las
cosas por obligacin, pero es un buen mecanismo cuando los equipos no tienen un grado
mayor de madurez.
Al fallar un build el responsable (el que hizo el ltimo commit) debe detener todo lo que
est haciendo y avocarse a corregir el error. El resto del equipo, al ser notificados del
fallo, deben abstenerse de subir nuevos cambios hasta que reciban una nueva notificacin
de build exitoso.
Establecer tiempos mximos para corregir errores en el build (10 minutos es un tiempo
recomendado). Si al cumplirse el tiempo establecido no ha sido posible corregir el error,
el responsable debe deshacer sus cambios y regresar a la versin anterior para que el resto
del equipo pueda continuar con sus check-ins.
Incorporar un script para el uso correcto del repositorio y el servidor de CI con los puntos
mencionados. El procedimiento recomendado antes de hacer un check-in es: descargar la
versin ms reciente del cdigo desde el repositorio, resolver conflictos por cambios en la
copia local, compilar y correr todas las pruebas de unidad/integracin; si no ocurri
ningn error, entonces se procede a subir el cdigo, en caso contrario se debe corregir el
error y repetir todos los pasos mencionados.
Bajo ninguna circunstancia comentar cdigo de las pruebas, as como archivos de
configuracin para que el build sea exitoso. La experiencia dicta que ese cdigo
permanecer comentado por el resto del desarrollo y eso puede impactar negativamente
en la calidad del producto final.
Contar con la infraestructura adecuada para soportar tanto servidor de versionamiento,
como servidor de CI disponibles en cualquier lugar de forma efectiva. En su
defectoBuscar tener acceso tanto a tu repositorio como al CI desde cualquier parte de
forma directa, ya que mediante VPNs slo provoca que el equipo no quiera realizar un
check-in o un update a su copia local, por el tiempo que va a perder en realizar esta
actividad.
Como se puede observar CI no se trata simplemente de una herramienta como Bamboo, es una
prctica que involucra varias herramientas: control de versiones (SVN), automatizacin de la
construccin y ejecucin de las pruebas (Maven) y una herramienta para automatizar y
monitorear la construccin y pruebas (Bamboo) las cuales a lo largo de la construccin se van
convirtiendo en pruebas de regresin, y lo ms importante es no perder de vista el compromiso
del equipo para practicar CI de la manera correcta.

6.4.6.3. Control de Versiones y CI
En QuarksoftLa Empresa el uso de SVN es una prctica comn en prcticamente todos los
equipos. Todos lo usamos para versionar el cdigo y trabajar de forma distribuida, pero no
hemos aprendido a usarlo como parte integral de CI y en ocasiones lo utilizamos en nuestra
propia contra haciendo de su uso una verdadera odisea.
A continuacin hacemos algunas recomendaciones que ayudarn a mejorar el uso de SVN:
La forma ms efectiva de practicar CI es haciendo integraciones del cdigo directamente
en el trunk. Claro est que esta forma de trabajar requiere no de una varita mgica, sino
de disciplina y compromiso de todo el equipo de desarrollo.
Sincronizar nuestro cdigo local con los ltimos cambios del trunk de manera frecuente.
Entre ms frecuente lo hagamos menos problemas tendremos cuando estemos listos para
incorporar nuestros cambios.
Hacer check-ins frecuentes. No dejar pasar das sin incorporar nuestros cambios ya que
los cambios ms pequeos son ms fciles de incorporar que los cambios grandes. Lo
ideal es hacerlo varias veces al dadespus dar por terminado cualquier componente o
cambio, previamente probado.
Limitar el uso de branches a casos muy particulares. Una buena razn para hacer un
branch es cuando se llega a una versin estable que es candidata para liberacin a
pruebas preproductivas o a produccin (branching for release). La gran ventaja de
generar este branch es que nunca va a ser reincorporado al trunk, su propsito es tener
una versin candidata para liberacin congelada. Mucho mejor que cerrar el acceso al
trunk durante cierto tiempo.
Cuando un branch cumpli con su propsito hay que eliminarlo.
Cuando se tenga una versin estable, candidata a ser liberada, esta deber ser congelada
creando un tag, lo cual nos permitir saber exactamente que se esta liberando.
Evitar usar branches que se mantengan vivos durante largos periodos de tiempo. Este es
un claro anti-patrn de CI.
Documentar cada commit con informacin relevante del cambio. Una buena prctica es
en una sola lnea presentar el propsito general del cambio y en las lneas subsecuentes
explicar detalles adicionales de manera que al consultar el log se pueda ubicar de manera
inmediata cada cambio y cuando sea necesario se pueden consultar los detalles. Es muy
frustrante consultar un log y ver mensajes sin sentido como: Se suben correcciones.
6.5.6.4. Pruebas (Unidad, Sistema, Estrs...)
Pruebas unitarias e integracin
Las pruebas unitarias e integracin sirven bsicamente para garantizar un correcto
funcionamiento de las partes que componen el sistema y las interacciones que tienen los
componentes. El enfoque de estas pruebas no tiene que ser necesariamente orientado a flujos de
negocio sino a un funcionamiento bsico (entradas vs. salidas esperadas). Lo importante de estas
pruebas es que cada componente sea evaluado en todas las posibles condiciones para verificar
que su comportamiento sea el esperado.
Es difcil proponer alguna prctica para lograr pruebas unitarias/integrales eficaces. Lo mnimo
que esperamos de un ingeniero de software es que sea responsable de entender el componente
que hizo y que genere un set de pruebas completo y congruente con lo que se espera del
componente.
Lo que proponemos para aumentar la eficacia de nuestras pruebas unitarias/integrales es :
Calcular la complejidad ciclomtica del cdigo, lo cual lo podemos hacer mediante
alguna herramienta como Cobertura o Cclover.
Utilizar un analizador de cobertura de las pruebas. Es posible configurar el build en
Bamboo para que establezca una poltica de fallo en caso de no cubrir con algn
porcentaje mnimo de cobertura de las pruebas.
Incorporar a nuestro proceso de construccin un analizador de estndares de codificacin
que permita detectar y eliminar malas prcticas de programacin. Una herramienta como
FindBugs permite realizar este anlisis desde el entorno de desarrollo e incluso cuenta
con un plugin para incorporarlo al proceso de build con Maven.
Inspeccionar los casos de prueba o la prueba durante la inspeccin de cdigo.
Al realizar una prueba de unidad, tener en cuenta las 6 reglas
Primero escribe la prueba (Test driven)
Nunca escribas una prueba que pase a la primera
Inicia con el caso Null o algo que creas que no va a funcionar
No tengas miedo en hacer algo trivial para que la prueba pase
Bajo acoplamiento y la capacidad para realizar las pruebas van de la mano
Haz uso de objetos MOCK
Tratar de transmitir a los ingenieros de software la visin completa de la aplicacin y los
conceptos bsicos del negocio. Entre ms conocimiento tengan sobre el propsito de la
aplicacin, mayores argumentos tienen para generar un set de pruebas acorde a los
objetivos del negocio.

Pruebas orientadas al negocio
Las pruebas de sistema tienen un alcance ms amplio y su enfoque debe ser completamente
orientado a los flujos de negocio que cubre la aplicacin. Lo ideal es que este set de pruebas sea
elaborado en conjunto con el cliente para que los escenarios realmente representen algo muy
cercano a lo que se espera en un ambiente productivo. El siguiente paso es definir el mecanismo
para ejecutar las pruebas. Bsicamente se tienen dos opciones: ejecucin manual o automatizada.
La ejecucin manual requiere de recursos y tiempo, lo que generalmente es costoso aunque
Formatted: Font: Italic
Formatted: Font: Italic
cuenta con la ventaja de que se pueden identificar errores o problemas de usabilidad que no se
pueden identificar mediante herramientas de automatizacin.
Se recomienda que siempre que sea posible automatizar las pruebas de sistema se haga. Cada
proyecto es distinto y por eso es tarea conjunta del arquitecto y el lder de proyecto definir la
estrategia de pruebas desde un inicio. No en todos los casos es posible automatizar las pruebas
desde la interfaz grfica de usuario ya que depende del framework o tecnologa utilizada, pero en
tales casos es posible automatizar las pruebas desde la capa subyacente. Si la aplicacin est
correctamente diseada, debiera ser posible correr pruebas contra los servicios detrs de la capa
de vista.
Adicional a las pruebas de sistema automatizadas es recomendable tambin llevar a cabo pruebas
exploratorias que son pruebas manuales desde la interfaz grfica de usuario para encontrar
problemas de usabilidad o errores visuales que son difciles de detectar desde las pruebas
automatizadas. Sin embargo estas pruebas no deben ser exhaustivas ni cubrir todos los escenarios
posibles, son pruebas que incluso pueden ser ejecutadas por usuarios del sistema en un ambiente
de pruebas piloto.
Otro aspecto importante de las pruebas de sistema es el ambiente de ejecucin. Es indispensable
contar con un ambiente lo ms cercano posible al ambiente productivo desde etapas tempranas
del desarrollo para llevar a cabo estas pruebas y verificar que nuestra aplicacin funciona
correctamente en el ambiente que se espera tener en produccin. Se deben tomar en cuenta todos
las posibles variantes del entorno como:
Versin del sistema operativo del servidor
Caractersticas del servidor (memoria y procesador)
Versin del manejador de la base de datos
Versiones de sistemas operativos soportados por la aplicacin para los clientes
Caractersticas de los equipos cliente (memoria y procesador)
Versiones de navegador de Internet soportadas (en el caso de aplicaciones web)
Versin de libreras o dependencias instaladas en los equipos cliente (e.g. versin de la
JVM)
Configuraciones especiales en el servidor o en equipos cliente (e.g. configuracin
requerida de nivel de seguridad del navegador de Internet)
Modelos de dispositivos de hardware, as como firmware del hardware controlados por la
aplicacin (Si aplica)
Caractersticas de la red en el ambiente productivo.
Creemos que eEl ambiente de ejecucin realmente impacta en los resultados de las pruebas y que
en la medida en que se le de mayor importancia a los ambientes de ejecucin, las liberaciones
van a tener un grado mayor de certidumbre.

Pruebas de requerimientos no funcionales
Las pruebas de aspectos no funcionales son quiz las ms difciles de llevar a cabo. Para empezar
es necesario tener bien claro el objetivo de cada prueba y las mtricas que van a usarse para
medir cada atributo de calidad. Es responsabilidad del arquitecto no generar falsas expectativas
desde el inicio y valorar cada atributo de calidad con el que debe cumplir y establecer mtricas
alcanzables por la aplicacin. En general los aspectos no funcionales estn correlacionados de tal
forma que se contraponen uno con otro. Por ello no es posible comprometer una aplicacin a
cumplir con todos los atributos de calidad en las mismas proporciones.
Las recomendaciones para llevar a cabo las pruebas de requerimientos no funcionales son:
Contar con el ambiente adecuado para ejecutar las pruebas. Entre ms cercano sea al
ambiente productivo, ms veracidad tendrn las pruebas. De ser posible, utilizar el
servidor productivo y llevar las pruebas a cabo en instalaciones del cliente.
Evitar caer en especulaciones sobre la capacidad real del sistema basada en mediciones
sobre un ambiente de pruebas. Extrapolar la capacidad del sistema de un ambiente de
pruebas al productivo es un engao. Por ejemplo, pensar que la aplicacin ser el doble
de rpida en produccin debido a que se cuenta con un procesador ms rpido o con ms
memoria fsica.
Definir los escenarios de pruebas. Generalmente se seleccionan algunos escenarios que
son los ms representativos o crticos para el negocio.
Utilizar una herramienta para automatizar la ejecucin de las pruebas mediante la
virtualizacin de usuarios y provocacin de estrs en la aplicacin.
Utilizar una herramienta de profiling para monitorear la ejecucin de las pruebas y
analizar el comportamiento de la aplicacin, as como posibles cuellos de botella, fugas
de memoria entre otras cosas.
Utilizar herramientas para monitoreo de la red. El resultado de nuestras pruebas puede
variar de acuerdo a la carga de la red en el momento en que se ejecutan. El trfico y
calidad de la red son factores impactan las pruebas y que deben considerarse y medirse.
En pruebas de capacidad es recomendable ejecutar una prueba pequea a manera de
calentamiento de la aplicacin antes de ejecutar la prueba que se va a medir. Esto es
porque las aplicaciones normalmente tienen configuraciones de cach que se van
inicializando conforme se va requiriendo. De la misma forma el entorno de ejecucin
tambin puede tener un comportamiento adaptativo como es el caso de la Mquina
Virtual de Java (JVM) que va optimizando algunos aspectos internos conforme se van
descubriendo ciertos patrones durante la ejecucin.
Cuando se realizan cambios a la configuracin del servidor o la JVM con el propsito de
mejorar la respuesta de la aplicacin, hay que tener cuidado de hacer un cambio a la vez
para tener oportunidad de probar, medir y obtener una conclusin sobre la eficacia del
cambio.
Considerar pruebas de longevidad. Observar si el desempeo de la aplicacin vara
despus de mucho tiempo de estar en ejecucin. Este tipo de pruebas permite identificar
fugas en la memoria o problemas de estabilidad.
Considerar realizar pruebas con ciertos volmenes de informacin, ya que el desempeo
de la aplicacin puede variar mucho con respecto a ciertos volmenes de informacin y
esto se debe principalmente al diseo de la base de datos.

Pruebas de despliegue
El ltimo tipo de pruebas que queremos comentar son las que se enfocan en el deployment. Su
propsito es verificar que todas las variables del ambiente de ejecucin de nuestra aplicacin se
encuentran en el estado esperado. Este tipo de pruebas es relevante cuando se libera una nueva
versin a produccin y por ello es importante hacer un check-up de todo lo que sabemos que
puede salir mal:
Verificar que todas las instancias de la aplicacin estn respondiendo en las direcciones y
puertos esperados.
Verificar que todos las instancias de la base de datos responden
Verificar que todos los sistemas externos de los que depende la aplicacin estn
respondiendo.
Adicionalmente es recomendable incluir en las pruebas de deployment una serie de pruebas
rpidas para verificar que la aplicacin no se encuentra en un estado de error. A este tipo de
pruebas se les conoce como smoke tests y su propsito es hacer fallar la aplicacin lo ms pronto
posible si es que va a fallar. Estas pruebas incluyen por ejemplo: iniciar sesin desde cada
instancia de la aplicacin y hacer alguna operacin de consulta por ejemplo para verificar as que
la aplicacin est respondiendo en todas sus capas.
Es importante considerar en automatizar tambin el set de pruebas de deployment para que pueda
ser ejecutado fcilmente por los encargados de realizar el deployment de la aplicacin sin la
intervencin del equipo de desarrollo o pruebas.


6.6.6.5. Deployement & Release
Muchos ven la liberacin de la versin 1.0 como el final del camino, sin embargo nosotros lo
vemos ms como el final de una etapa y el inicio de otra. La liberacin marca el inicio de la vida
de nuestra aplicacin y de este punto en adelante solo resta esperar que la aplicacin soporte en
pie todos los imponderables que se susciten en el ambiente productivo. Todas las pruebas
realizadas previas a este momento son una simulacin de las condiciones que pueden esperarse
en un ambiente productivo, pero nunca igualarn a la realidad. Si nuestra aplicacin sobrevive a
los ataques de un ejrcito de usuarios con conductas impredecibles que nos resultan
generalmente ilgicas, solo entonces podremos estar tranquilos y ciertos de que nuestro trabajo
ha terminado. En el 99% de los casos esto no ocurre as, por lo que nuestra responsabilidad a
partir de ese punto es llevar a nuestra aplicacin a un punto de estabilidad.
La estrategia de liberacin va a ser fundamental para que este proceso no se alargue en demasa y
se logre alcanzar el objetivo en el menor tiempo y con la menor inversin de recursos. A partir
Comment [EM1]: Jorge menciona
agregar una seccin de pruebas de
regresin, pero en realidad yo lo veo como
pruebas funcionales automatizadas, que
es una seccin anterior
de la primera liberacin las condiciones son distintas a las que se tenan en la fase de desarrollo.
Consideramos que es de vital importancia para el proyecto lograr una identificacin temprana de
todos los stakeholders la aplicacin e involucrarlos desde el inicio para preparar el terreno y
lograr una colaboracin adecuada.
Existen algunas prcticas que consideramos son tiles como parte de la estrategia de deployment.
1. Evitar tener un experto en deployment. Lo ideal es tener un script versionado bajo
configuracin que ejecute todos los pasos requeridos para el deployemnt en forma
automtica mediante un simple comando. Adicionalmente todos los ingenieros del equipo
deben conocer y entender desde un principio cul es el procedimiento para ejecutar un
deployment. Depender de una sola persona o de un documento no es una buena estrategia.
2. Automatizacin del deployment. El deployment consiste en una serie de pasos repetible.
La mejor manera de ejecutarla es mediante un script que pueda ser interpretado por una
mquina. De ser posible este proceso automtico de deployment puede registrar cada
accin en una bitcora para tener registro de quin y cundo lo ejecut.
3. Contar con un set de pruebas de deployment. El objetivo de estas pruebas es hacer un
checklist de todo lo que puede afectar nuestra aplicacin. Tambin un conjunto de smoke-
tests que identifiquen problemas con la versin de manera rpida.
4. No corregir errores directamente en el ambiente productivo. Cuando se hacen cambios en
el ambiente productivo se pierde el control de lo que se hizo y las consecuencias pueden
ser muy graves.
5. Considerar un procedimiento de rollback. El costo de que la aplicacin no funcione como
se espera en un ambiente productivo es muy alto. Debemos tener la capacidad de
reaccionar de manera muy rpida ante cualquier problema detectado en la nueva versin.
6. Cuando ocurre algn error debemos tener la forma de encontrar el problema de manera
rpida y transparente. El log de la aplicacin es generalmente el primer lugar donde
debemos buscar y debemos ser cuidadosos con su configuracin. El nivel de logging es
importante mantenerlo en WARNING en el ambiente productivo para evitar que se sature
con mensajes de debugging.
Adems de estas prcticas existen un par de tcnicas para pruebas que pueden ser tiles con
sistemas de alta criticidad que difcilmente pueden estar fuera de operacin por un periodo largo
de tiempo y consideramos que deben ser tomadas en cuenta para sistemas de esta ndole.

Tcnica Blue-Green deployment. La idea de esta tcnica es tener dos versiones idnticas de
nuestro ambiente de produccin (servidores, configuracin, base de datos, etc.). En una de estos
ambientes permanece la versin actual de la aplicacin (verde) y en el otro ambiente (azul) se
deploya la nueva versin que queremos liberar. Basta hacer un cambio en la configuracin de
la red para direccionar a una u otra aplicacin.

Tcnica del canario en la mina de carbn. Esta tcnica hace referencia al uso que se les daba
antiguamente a estas aves como alarmas de la toxicidad en las minas de carbn. Los canarios
eran llevados al fondo de la mina junto con los mineros y al ser animales muy susceptibles al
monxido de carbono o al metano, su muerte era una seal de alarma para que los mineros
desalojaran la mina. En el deployment de software se usa esta analoga para una tcnica que
consiste en liberar una nueva versin a un nmero limitado de usuarios mientras que el grueso de
los usuarios sigue accediendo a la versin estable. Esta tcnica permite detectar rpidamente los
posibles problemas y minimiza el impacto a un grupo pequeo y controlado de usuarios.



7. Anlisis Costo-Beneficio

8. Conclusin
En la presente propuesta se han dado a conocer una serie de blueprints tanto para el diseo como
para la construccin y liberacin de sistemas de software, las cuales fueron tomadas
principalmente de casos de xito, otras metodologas y libros de entidades representativas en el
desarrollo y liberacin de software.

Las practicas aqu recomendadas se supone sean utilizadas, en todas las fases de la creacin del
sistema. Creemos que el uso apropiado de estas practicas ayuda a reducir los riesgos de liberar
un sistema incapaz de satisfacer las necesidades por las cuales fue concebido, adems de reducir
en gran medida el tiempo dedicado a la fase de liberacin.

9. Referencias
[1] Jez Humble, David Farley, Continuous Delivery, Addison Wesley, 2010
[2] Michael T. Nygard, Release It! Design and Deploy Production-Ready Software, The
Pragmatic Bookshelf, 2007
[3] QuarkSoft , Checklist para Pre-anlisis, Mxico D.F., 2003
[4] QuarkSoft , Formato para Monitoreo de Recursos Crticos de Computadora, Mxico D.F.,
2003
[5] QuarkSoft , Forma Estrategia (STRAT), versin 2.5.6, Mxico D.F., 2002
[6] QuarkSoft , Estndar Template SPMP, versin 1.5, Mxico D.F., 2001
[7] QuarkSoft , Estndar Template SDP, versin 1.3, Mxico D.F., 2002
[8] QuarkSoft , Gua para la Generacin y Uso de Prototipos, versin 1.0, Mxico D.F., 2003
[9] QuarkSoft , Template de Plan de Pruebas, versin 1.3, Mxico D.F., 2003
[10] QuarkSoft , Gua Metodolgica de Diseo de Alto Nivel y Detallado, versin 1.2, Mxico
D.F., 2003
[11]QuarkSoft , Descripcin y Gua de Seleccin de Ciclos de Vida de Software, versin 1.0,
Mxico D.F., 2003
[12] Rational Software Corporation , Rationa Unified Process Documentation,
http://www.ts.mah.se/RUP/RationalUnifiedProcess/
[13] Scott Ambler, Effective Software Deployment, 1999, http://drdobbs.com/architecture-and-
design/184415760?cid=Ambysoft
[14] Scott Ambler, The Agile End of Game, 2007, http://drdobbs.com/architecture-and-
design/198800565?pgno=1
[15] Scott Ambler, System Deployment Tips and Techniques, 2005,
http://www.ambysoft.com/essays/deploymentTips.html
[16]John Birtley, Agile Deployment Best Practices for Risk-Free Deployment, 2004



10. Apndices

A. Problemas Identificados en MidasSistema X

Problema Causas
Al realizar el despliegue de la
aplicacin sobre el App.
Server Oracle Weblogic no
levant la aplicacin debido a
problemas del server para
interpretar las interfaces de
EJB 3.0
La definicin del App. Server no se estableci desde el inicio del proyecto.
Fuimos early adopters de EJB 3.0 ya que la especificacin tena algunos meses de haber sido liberada y
apenas unos pocos App.
No contamos con las licencias de la ltima versin de Weblogic que introdujo la primera
implementacin de EJB 3.0
Se inici el desarrollo y las primeras pruebas sobre JBoss app. Server (que tambin tena una
implementacin de EJB 3.0) basados en la premisa de que todos los application servers se basan en una
misma especificacin.
El ambiente de desarrollo y el ambiente de integracin no era semejante al que se esperaba tener en
produccin.
Seleccin tecnolgica
Nuestra propuesta original se basaba en una seleccin tecnolgica orientada a cubrir con los
requerimientos de performance bajo las restricciones de infraestructura del cliente (anchos de banda
limitados) y por ello descartamos el uso de una aplicacin web. Sin embargo hubo pugnas internas
(Cliente) para optar por la aplicacin web argumentando que se mejorara la infraestructura de red y
que de acuerdo a un experto de BEA, una arquitectura JSF/Ajax con EJB y JPA consumira el mismo
ancho de banda que la aplicacin 4GL actual.
No tuvimos elementos suficientes para rebatir la decisin del cliente ya que a pesar de que se hizo una
prueba de concepto y se realizaron algunas pruebas de capacidad, el ambiente de dichas pruebas no era
ni remotamente cercano al ambiente de NMP.
No contamos con herramientas ni expertise suficiente como para hacer pruebas punto a punto que
sirvan como un sustento cuantitativo confiable al momento de tomar este tipo de decisiones
Al intentar crear la estructura
de la BD en Informix a partir
de un DDL creado a partir de
una herramienta de
exportacin ocurrieron
mltiples errores
No contamos con herramientas organizacionales para el mapeo de E-R a DDL. Se utiliz la
herramienta Embarcadero con licencia apcrifa.
Las pruebas de unidad de
componentes terminados
comenzaron a fallar en el
ambiente de integracin
continua por mapeos y tipos
de datos que no haban sido
probados en Informix.
El ambiente de desarrollo utilizaba MySQL en lugar de Informix.
El arquetipo estaba diseado para crear la BD y el set de pruebas sobre MySQL por cuestiones de
simplicidad y limitaciones de algunos equipos de desarrollo.
Idea equivocada de que el cdigo es independiente de la BD y que las diferencias entre una BD y otra
radican slo en parmetros de configuracin.
En el ambiente pre-operativo
del cliente las transacciones
no se podan ejecutar.
La configuracin del esquema de buffering de la base de datos no era compatible con las transacciones
de la aplicacin.
No se llev un control adecuado de las configuraciones necesarias de la BD para poder operar.
No existe un procedimiento o mecanismo adecuado para replicar de manera consistente un ambiente o
configuracin de los sistemas que soportan la aplicacin (SO, RDBMS, LDAP, etc.)
El mecanismo de
autenticacin contra el
directorio de usuarios no
funcion la primera vez que
se instal en un ambiente de
pruebas del cliente.
No se cont con un ambiente de pruebas previo (QS) de integracin/sistema que fuera lo ms cercano
posible a la realidad.
Las integracin de la aplicacin sobre el servidor a utilizar (Oracle Weblogic) fueron muy tardas, lo
que ocasion problemas de configuracin no previstos.
Al realizar el despliegue de la
aplicacin sobre un cluster de
Weblogic ocurrieron
problemas con la
serializacin de objetos entre
la capa de presentacin y el
backend cuando la peticin
era atendida por un nodo
distinto al que origin la
peticin.
A pesar de que en la teora la opcin de separar las capas (front-end y back-end) como aplicaciones
independientes era posible a travs de la invocacin remota de los EJBs, hubo problemas debido al uso
de una librera (cglib) que se utiliz para generar proxys de ciertas clases para la ejecucin de
bsquedas dinmicas.
Aunque se contempl la posibilidad de desplegar la aplicacin bajo este esquema, nunca se hicieron
pruebas.
No se hicieron pruebas de integracin/sistema sobre ambiente clusterizado.
No se replic el ambiente del cliente para pruebas por falta de hardware y licencias.
Problemas de lentitud y con
los dispositivos de impresin.
Ancho de banda limitados a 128kb y 256kb
Una mala configuracin en la aplicacin la cual hacia un consumo excesivo en el ancho de banda.
No se haba considerado la compresin de datos
Applets que se descargaban en cada peticin del cliente (debido a una configuracin errnea)Una mala
configuracin en recursos que deben residir del lado del cliente
Cambio en las versiones del navegador, se realizaron pruebas en una versin y en produccin se tena
otra versin.
Inicialmente no se implement algn esquema de caching a nivel aplicacin.
Liberaciones con defectos de
lgica
Pruebas unitarias e integrales deficientes, aunque existe mucho cdigo de pruebas, no es funcional y no
prueba exactamente lo que tiene que probar, esto se debe principalmente a que los ingenieros que
desarrollan las pruebas, no tienen idea que probar.
Revisiones e inspecciones deficientes.
Falta de mantenimiento al set de pruebas unitarias. Algunas pruebas unitarias comenzaron a fallar y
muchas de ellas terminaron comentadas.
Ambientes de prueba no homologados. En ocasiones no era posible reproducir algunos errores por
diferencias en los ambientes de prueba lo que ocasionaba que se cerraran equivocadamente issues al no
poder reproducirse cuando en realidad el problema prevaleca.
Deficiencias en el equipo de desarrollo. A los ingenieros que se identificaba que no eran buenos
codificando, se les asign la tarea de realizar/ejecutar las pruebas considerando que era una tarea
tcnicamente menos compleja. La estrategia tampoco funcion ya que su falta de habilidad tcnica
llev a que las pruebas no fueran tiles o representativas.
Las pruebas de sistema no fueron automatizadas y por tanto la ejecucin de los escenarios era propensa
a fallas u omisiones.
Escenarios de pruebas de sistema insuficientes o limitados.
Programadores inexpertos o simplemente malos programadores.
Uso inadecuado del servidor de integracin continua.
Inexistencia de un plan de release/deployment que estableciera un procedimiento que pudiera
garantizar la validez de cada release.
Uso deficiente del mecanismo de control de versiones. Frecuentemente se suba cdigo que no se
encontraba probado o listo para produccin.
No se contempl un protocolo o procedimiento para probar el nuevo deploy (lo que se conoce como
smoke tests). Lo ms que se probaba era que todos los nodos respondieran y que se presentara en cada
uno la pantalla de login y si acaso ingresar con un usuario.
Nuevas versiones del cdigo
que no estaban sincronizadas
con cambios en la BD o
viceversa
Problemas de comunicacin entre los miembros del equipo. No haba un canal adecuado para informar
al resto del equipo sobre cambios al esquema de la BD que pudieran afectar al cdigo existente.
Carencia de un protocolo o procedimiento sistemtico para realizar un deploy.
Carencia de mecanismos para replicar configuracin o estado de la BD de manera sistemtica y
controlada.
No se versionaron los scripts de la BD ni se versionaron los releases. De esta forma es imposible llevar
un control sobre la compatibilidad entre versiones de releases y BD.
El deploy del sistema debe incluir todos los elementos o sistemas subyacentes y no nicamente el
cdigo de la aplicacin. Mientras el deploy de un sistema no se considere como un TODO que integre
todas las posibles variables el problema va a persistir.
Deficiencia en el mecanismo de rastreabilidad del cdigo (componentes). No fue posible mantener al
da la matriz de rastreabilidad y aunque se hubiera mantenido, por el tamao del proyecto y el nmero
de componentes hubiera sido complicado utilizarlo ya que el formato en si no se presta para el manejo
de tantos componentes.
Al realizar una auditora de la
aplicacin mediante una
herramienta de profiling se
estableci que los tiempos de
respuesta no eran aceptables.
Cdigo no optimizado (e.g. Llamadas redundantes, ciclos sin break points)
Configuracin de Hibernate y naturaleza de hibernate provocan cierto overhead en la aplicacin.
Falta de una solucin para caching a nivel aplicativo.
Problemas con los filtros en la capa web. Se tenan filtros de ms y algunos no eran los ms eficientes.
No se cuenta con una estrategia/herramienta para realizar un profiling de la aplicacin desde una etapa
de pre-produccin en la que se puedan realizar pruebas de estrs que permitan identificar umbrales para
definir la capacidad real de la aplicacin, as como identificar los posibles cuellos de botella y
determinar si pueden ser solventados. Ya en produccin se utiliz una herramienta con una licencia
temporal y en un ambiente en el que la capacidad del hardware disponible limitaba las pruebas a 15
sesiones concurrentes.
Falta de capacitacin, guas o scripts para realizar pruebas de capacidad, se carece de documentacin de
las experiencias de otros equipos en sistemas similares, falta de una base de conocimiento que
concentre las experiencias de todas las aplicaciones que se desarrollan en QS.
Lentitud en el sistema y
cadas frecuentes de uno o
ms nodos de la aplicacin.
Configuracin no optimizada del clster. La cantidad de memoria para la mquina virtual de Java era
menor a la recomendada por los expertos de Oracle.
No existe mucha informacin disponible al pblico sobre las recomendaciones o mejores prcticas para
la configuracin de Weblogic.
No contamos en QS con expertos o partnerships de los servidores de aplicaciones comerciales ms
utilizados (Oracle WL e IBM Websphere).
No hay una base de conocimiento sobre configuraciones y mejores prcticas.
No se cont con un ambiente de pruebas similar al productivo donde poder realizar pruebas de
capacidad y establecer escenarios de estrs con condiciones semejantes a los momentos pico de la
operacin normal.
Liberaciones con errores de
configuracin
Procedimiento de deployment no completamente automatizado.
Dependa de la presencia del experto en deployment, lo que indicaba que el procedimiento requera de
pasos manuales.
Inicialmente requera de modificaciones manuales (direcciones IP) para apuntar a recursos del
ambiente productivo lo cual era propenso a errores.
No existe una cultura organizacional que promueva la automatizacin el deployment de manera que sea
un proceso repetible y auditable.
Carencia de un plan de deployment que contemple todas las partes variables de la aplicacin (no
nicamente el cdigo).
Carencia de set de pruebas para verificar el deployment (smoke tests). Este set de pruebas se enfoca
especficamente en probar que todos los recursos utilizados por la aplicacin estn disponibles, que la
aplicacin responda en todas las instancias existentes, se prueban las conexiones a BD, Ldap, sistemas
externos, balanceadores, etc.
Mecanismos de monitoreo insuficientes o limitados.
Problemas con el equipo de
soporte y administracin de la
infraestructura
Falta del ejercicio de governance de parte del cliente. Al ser dos empresas (QS y HP) contratadas por el
cliente con contratos de servicio especficos cada uno velaba por sus propios intereses y prioridades.
Problemas para regresar a una
versin previa del deploy de
manera rpida y sistemtica
No se tena una estrategia formal para identificar/versionar los releases.
No se generaba un control de releases, no se utilizaban tags para marcar cada release, no se
documentaba cada uno de los releases con informacin de los cambios (fixes, features, etc.) ni se
llevaba un control de etiquetacin (labeling) de cada release.
Como mecanismo de control al hacer un deploy nuevo se tomaba el EAR anterior y se renombraba con
la fecha del da en que se reemplazaba, sin embargo el mecanismo era propenso a errores adems de
que la versin se guardaba compilada y no haba forma de relacionarla con una versin concreta del
cdigo. Tampoco haba garanta de que no fueran borradas por error.
Ineficacia ante errores en el
ambiente productivo.
No se contaba con un ambiente de pruebas con las mismas condiciones (configuraciones, versin del
cdigo) y datos del ambiente productivo que estuviera ejecutndose a la par del ambiente productivo.
Dificultad para levantar ambientes de pruebas. Generalmente no estaban levantados y para replicar los
errores era necesario primero identificar y generar la versin del cdigo que correspondiera a la versin
productiva y luego levantar todo el ambiente para iniciar las pruebas.
No exista un catlogo de usuarios de pruebas para todos los roles para poder ingresar con el rol
correcto y replicar el error.
Dificultad para reproducir el error de manera rpida. Muchas ocasiones la opcin mas rpida y efectiva
para reproducir el error era levantar el ambiente de prueba apuntando a la BD y LDAP productivos, lo
cual no es por mucho una buena prctica. En casos extremos se ingresaba a la aplicacin productiva
para replicar el error (a veces con autorizacin del usuario y a veces sin su autorizacin).
No haba plan de accin, slo reaccin.
Errores o problemas por
accidentes al ejecutar
sentencias de SQL
Al no tener en muchos casos forma de arreglar alguna incidencia mediante la aplicacin, se proceda a
modificar la BD productiva directamente, con todos los riesgos que esto conlleva.
directamente sobre la BD
productiva
Debido a problemas de lentitud muchas veces se proceda a realizar actualizaciones de manera masiva
ya que los usuarios no podan hacerlo desde la aplicacin por lentitud o errores del sistema.
Solicitudes de informacin que no se podan consultar desde la aplicacin porque no fueron requeridas
desde un inicio pero la demanda de los usuarios nos obligaba a realizarlas.
Falta de regulaciones y protocolos para realizar este tipo de operaciones. El cliente pareca
acostumbrado a trabajar de esta manera, sin embargo nos vimos arrastrados por esa inercia y
terminamos cayendo en las mismas prcticas.
Errores y omisiones con la
ejecucin de procesos
masivos (crones)
No eran procesos 100% automatizados, requeran de la ejecucin y en algunos casos de la
configuracin manual.
Deficiencia en la definicin del alcance de los crones. Nos enfocamos en definir y entender el
funcionamiento, pero obviamos detalles importantes acerca de las condiciones de ejecucin y las
variables que pudieran afectar su periodicidad.
Las condiciones de ejecucin podan variar de manera diaria. Algunas de estas condiciones iban ms
all de los requerimientos originales
Algunos procesos no tenan una periodicidad fija sino que simplemente se ejecutaban cuando el cliente
decida que era oportuno de acuerdo a regulaciones internas.
Al ser una operacin manual era frecuente que alguien olvidara ejecutar alguno de ellos o que fueran
ejecutados cuando no era necesario o que fueran ejecutados y posteriormente se recibiera una orden de
omitir una o varias sucursales.
No existan condiciones o regulaciones que permitieran o facilitaran la automatizacin completa de los
procesos nocturnos.
No existan mecanismos
automatizados que
permitieran deshacer los
cambios realizados por un
proceso masivo (cron).
Muchas ocasiones fue
necesario revertir algn
proceso masivo y en todos los
casos se haca mediante
ejecuciones de updates
masivos directamente a la
base de datos en horas de
operacin.
No se contempl la necesidad de revertir la ejecucin de estos procesos. No se identific como un
requerimiento del cliente, sin embargo se convirti en un requerimiento del rea de soporte.
Falta de regulacin en los procedimientos y normatividad para la ejecucin de los procesos masivos
(crones). Muchas veces se omitan por diversas causas y las notificaciones no eran oportunamente
enviadas al equipo de soporte o no se enviaban por un medio formal, en ocasiones era simplemente una
orden verbal.
Con el crecimiento de la base
de datos y el nmero de
sucursales migradas, los
procesos masivos (crones)
comenzaron a extender su
tiempo de ejecucin y a salir
de las ventanas de tiempo
establecidas.
La implementacin de los acumulados no fue la planeada sino una solucin temporal debido a retrasos
en el desarrollo y obligados por la necesidad de contar con la funcionalidad en produccin.
Uso ineficiente del lenguaje de stored procedures de informix (SPL).
Falta de pruebas de estrs de los crones con condiciones similares a las productivas.
Falta de expertise en el lenguaje SPL o de algn experto que validara el uso eficiente del lenguaje
Dificultad para consultar
errores en el log de la
aplicacin
El log se enviaba a archivos de texto plano y por cada nodo del cluster se generaba un archivo. El
primer problema era adivinar en qu archivo se haba registrado el error que se buscaba.
El crecimiento de los archivos de log era muy acelerado. Inicialmente tenamos acceso abierto para
consultarlo directamente en el servidor, sin embargo para abrir el archivo poda tardarse varios minutos
y el procesamiento del archivo repercuta en el uso del procesador del servidor productivo.
Encontrar los errores en archivos tan grandes era una tarea difcil sobre todo si no se sabe qu buscar.
Uso inadecuado de los niveles de logueo a nivel del cdigo. Muchos de los registros del log eran
comentarios a nivel informativo que se usaron para pruebas unitarias o de integracin y que no tenan
cabida en el ambiente productivo.
Mal manejo de excepciones. Mensajes de error incongruentes o poco descriptivos, errores que no
incluan la traza del error original, cdigos que se tragaban la excepcin (no la relanzaban ni la
manejaban).
Configuracin inadecuada de los niveles de logueo. Inicialmente se generaban registros a nivel de
debug y se incluan mensajes de frameworks como hibernate que hacan crecer muy rpido los
archivos.
No se previ una estrategia para unificar el logueo a nivel del cluster o para centralizar el registro en un
repositorio comn.
Inicialmente no se contemplaron otros mecanismos para registrar ciertos tipos de errores a nivel
aplicacin para que fuera ms sencillo consultarlos.
Con el incremento gradual de
usuarios se presentan
problemas espordicos en los
clculos de cobros y pagos.
Deficiencias en la programacin que evidencian un desconocimiento de los ciclos de vida de los
objetos.
No se realizaron pruebas de concurrencia.
No se tiene la prctica de identificar desde el HLD aquellos componentes crticos que requieren de
pruebas especializadas y de un desarrollo cuidadoso.
La asignacin de componentes es resultado ms de un procedimiento de optimizacin de tiempos y
recursos que de un anlisis cuidadoso de la complejidad de cada componente y de la experiencia de
cada ingeniero del equipo.
Este tipo de errores es difcil que se detecten en etapas tempranas ya que las pruebas de unidad e
integracin generalmente se enfocan en la funcionalidad y no en probar el comportamiento de la
aplicacin con carga y accesos concurrentes.
No se cuenta con herramientas institucionales para llevar a cabo este tipo de pruebas.

B. Aciertos Identificados en MidasSistema X


Aciertos Resultados
Se gan la confianza total del sponsor del
proyecto
La comunicacin entre el lder de proyecto (y el resto del equipo) y el sponsor de
proyecto siempre fue clara y transparente.
El sponsor del proyecto se convirti en un aliado del equipo de desarrollo y en
momentos complicados del proyecto soport la presin de su lado para que el equipo
continuara trabajando.
Se tena informacin oportuna y de primera mano de todas las situaciones que pudieran
afectar el desarrollo del proyecto
La confianza y disposicin del sponsor fueron muy importantes para lograr obtener
toda la informacin y recursos necesarios para la continuidad del proyecto
Involucrar a miembros del equipo de
desarrollo en la etapa de transicin a
MidasSistema X como parte del equipo de
soporte en sitio
El equipo tuvo retroalimentacin de primera mano del los usuarios finales de la
aplicacin
se tuvo la oportunidad de ver la aplicacin ejecutndose en el ambiente operativo
Al conocer y ver de cerca la operacin real se obtiene informacin muy valiosa que
muy difcilmente se comprende en su totalidad al leerla en un documento como el SRS
Mayor comprensin de las necesidades y problemas que viven los usuarios da a da
Se identifican ms fcilmente problemas de usabilidad que de no identificarse
posteriormente pueden reportarse por los usuarios de manera inadecuada como
problemas de performance.
Se entiende y se adquiere el sentido de urgencia e importancia que los usuarios tienen
al solicitar ayuda del equipo de soporte
Factorizacin de cdigo. Hubo
componentes que se detectaron con
deficiencias y se tom la decisin de
asignar tiempo para redisearlos en lugar
de simplemente parchar el cdigo
Cdigo ms limpio y legible y por lo tanto ms sencillo de administrar
Mejoras en funcionamiento y/o performance
Divisin del equipo en grupos con
responsabilidades especficas.
Cada grupo se enfoc a resolver los problemas que tena bajo su responsabilidad sin ser
agobiados por los problemas de otro grupo (e.g. el grupo de soporte no se preocupaba
de corregir los defectos que salan y el grupo responsable de la correccin no se
preocupaba si en una sucursal no podan operar por algn problema con el ambiente
productivo)
Con el tiempo cada grupo logr un buen nivel de eficiencia en lo que haca.
Contar con el apoyo de expertos en la
configuracin y puesta a punto del servidor
de aplicaciones (Weblogic)
Aportaron su experiencia y conocimiento para configurar de la mejor manera el
ambiente productivo del cluster del servidor de aplicaciones
Trabajaron de manera muy cercana a un representante del equipo de desarrollo de
manera que el ambiente y la configuracin giraran en torno a las caractersticas de la
aplicacin.
Cambiar la estrategia de deployment de
nuevos releases utilizando una sucursal
piloto.
El impacto de defectos en la nueva versin solo repercuta en una sucursal.
Minimizacin del riesgo de afectar la operacin diaria
Menor presin para los grupos de soporte y correccin de defectos al liberar una nueva
versin
Mayor certeza de la calidad de los releases una vez que se liberaban a produccin
Involucrar al rea de mantenimiento e
infraestructura en los deployments de la
aplicacin
Se les deleg la responsabilidad de realizar las operaciones necesarias para deployar la
aplicacin
Se restringi el acceso al equipo de desarrollo a los servidores, liberndolos de la
responsabilidad de operarlos, monitorearlos o mantenerlos funcionando
Se libr al equipo de desarrollo de cualquier responsabilidad en el caso de cadas de los
servidores o configuraciones que afectaran la aplicacin
Involucrar a todas las reas responsables de
los recursos alrededor de la aplicacin en la
etapa de migracin de sucursales
Los das de migracin deba estar disponible al menos un responsable de cada rea para
atender cualquier incidencia relacionada a su rea
Se tena ms confianza al hacer las migraciones sabiendo que estaba alguien disponible
para apoyar en el momento en que se requiriera
De alguna manera todos se responsabilizaban de las migraciones y no era un proceso
exclusivo del equipo de desarrollo.
Cambio de estrategia en la migracin de
datos utilizando Stored Procedures en lugar
de ETL
Se redujo notablemente el tiempo de migracin/conversin de datos
Permiti la migracin de las sucursales ms grandes que no hubieran sido posibles con
ETL en las ventanas de tiempo disponibles
Permiti la reanudacin de la migracin en el caso de que se presentara algn error, se
correga y se continuaba desde el ltimo registro procesado.
Realizar pruebas de capacidad llevadas a
cabo por un evaluador externo
Se obtuvieron muchas observaciones y puntos de mejora
Al ser un evaluador imparcial y ajeno al proyecto la evaluacin es ms amplia y
detallada ya que no se encuentra restringida por ideas o prejuicios
La entidad externa es especialista en este tipo de evaluaciones y cuenta con las
herramientas apropiadas para llevar a cabo su labor
Al ser ajeno al proyecto evit o aminor los constantes enfrentamientos o tensiones
entre el equipo de desarrollo y el personal de infraestructura/operaciones
Las observaciones dieron pie a muchas correcciones y ajustes a la configuracin y el
cdigo de la aplicacin que mejoraron notablemente el desempeo general de la
aplicacin.
Dio pie para que el equipo de desarrollo comenzara a utilizar una herramienta similar
para estresar la aplicacin y encontrar nuevos cuellos de botella
Se genera mayor confianza hacia el equipo de desarrollo conforme se van solucionando
los problemas encontrados. El hecho de que el evaluador sea externo es algo que
fortalece en mayor medida el grado de confianza hacia la aplicacin.
Involucrar al experto en Informix del lado
del cliente para realizar auditoras de la BD
Se obtuvieron algunas observaciones que ayudaron a mejorar o corregir algunos Stored
procedures
Se obtuvieron algunos puntos de mejora
Se involucr a los responsables de mantenimiento e infraestructura del cliente en el
mantenimiento y mejora del esquema de datos.
Se dio oportunidad al cliente de verificar el diseo y estructura de la BD
Al ver que las observaciones no eran tan graves tambin se genera una mayor confianza
en el equipo de desarrollo
Contar con un contrato de soporte del
servidor de aplicaciones (oracle weblogic)
La atencin de los issues reportados era atendida de manera casi inmediata
Es un recurso importante para el equipo de desarrollo con el que puede contar en caso
de alguna eventualidad
Al cliente le da la confianza de que cualquier problema relacionado con el servidor de
aplicaciones est garantizada su solucin
Incluir a ciertos arquitectos desde etapas
tempranas, tales como requerimientos y
diseo de alto nivel.
Tener un completo contexto de la regla de negocio, as como un claro entendimiento de
las necesidades del cliente, lo cual le dio una gran confianza al cliente.
Proporcionar una mejor ayuda a los ingenieros de desarrollo al explicarles con mayor
claridad la funcionalidad de cada uno de los componentes.


C. Experiencias

Big Design Up Front (BDUF) vs. Diseo Incremental

Algo que fue particularmente difcil durante la fase de HLD de MidasSistema X fue realizar un
diseo completo de la aplicacin en una sola fase/etapa. Cabe mencionar que el diseo original
entregado en el documento de HLD sufri muchos cambios posteriores debido en parte a la
premura de entregar el documento y tambin a aspectos no considerados en un inicio. Por
defecto PSP/TSP se toma como un proceso de desarrollo en cascada y por ello cada fase debe
culminarse en su totalidad antes de iniciar con la siguiente. En sistemas pequeos o medianos
puede resultar adecuado, sin embargo con sistemas de mayores dimensiones el riesgo que se
asume es proporcional al tamao del sistema. Los promotores de metodologas giles consideran
el BDUF un anti-patrn argumentando el alto costo en tiempo y esfuerzo y la poca validez que
puede tener un diseo basado en demasiados supuestos. Nosotros consideramos que eEs
indispensable iniciar el desarrollo con una definicin clara en trminos de diseo de lo que se va
a hacer, pero con estrategia basada en el diseo incremental como se describe en [11] mediante
la identificacin de mdulos funcionales con cierta independencia para tener varias iteraciones
completas de HLD-Code-Test. En la primera iteracin se llevara a cabo un esfuerzo importante
para definir toda la estructura principal de la aplicacin, todos los elementos comunes que
requieran ser definidos de inicio e incluir tambin el diseo del primer mdulo funcional. Con
esto se llevaran a cabo ciclos completos de desarrollo (Design, Code, Test) y al final de cada
ciclo se puede tener un entregable funcional que puede ser implantado en un ambiente
preproductivo para ser probado e incluso evaluado por el cliente sin tener que esperar hasta el
final de todo el proyecto y llevarse la sorpresa de que el sistema no cumple con los requisitos por
los cuales fue concebido.

Integracin Continua

La prctica de la Integracin Continua (CI) no tiene mucho tiempo en QuarksoftLa Empresa y un
problema que hemos detectado es que no se ha transmitido de forma efectiva el propsito de usar
una herramienta de CI. En MidasSistema X utilizamos la herramienta de CI (Bamboo) pero eso
no signific que realmente practicramos la Integracin Continua por lo que el uso de la
herramienta result en ms problemas que beneficios. Inicialmente configuramos Bamboo para
hacer una o dos ejecuciones diarias, al menos una al final del da. Muy pronto comenzaron a
fallar las ejecuciones y comenzamos a recibir las notificaciones de falla. Al principio nos
encargbamos de buscar el error y corregirlo, pero pronto nos dimos cuenta que apenas se suba
la versin corregida, alguien ms suba un nuevo cambio que volva a romper el build. Debido a
esto se tom entonces la decisin de forzar la ejecucin del build en Bamboo cada vez que se
subiera un cambio al repositorio con el propsito de obligar a los ingenieros a hacerse
responsables de sus cambios. En realidad esta prctica debe ser la ideal para practicar CI, sin
embargo es indispensable que el equipo entienda el concepto de CI o el resultado puede ser
contraproducente como lo fue en nuestro caso. Con la nueva configuracin comenzamos a recibir
infinidad de notificaciones de fallas en los builds ya que se seguan subiendo cambios que
rompan el build y aunque se intent seguir corrigiendo los problemas result muy complicado
debido a que se continuaban subiendo cambios sobre la versin defectuosa. Como resultado
dejamos de hacer caso a las notificaciones de Bamboo por un buen tiempo (varias semanas e
incluso meses) y continuamos con el desarrollo. La conclusin a la que podemos llegar ahora es
que la prctica de ejecutar el build con cada nuevo cambio no era mala, el error estuvo en nuestra
actitud y falta de entendimiento de CI. Es evidente tambin que existe otro problema de fondo en
nuestras pruebas unitarias, muchos creemos que las pruebas son solo para cumplir con el proceso
ms que para garantizar la calidad del componente desarrollado, es por ello que no le damos la
suficiente importancia como para garantizar que cada componente desarrollado vaya
acompaado de un conjunto de pruebas efectivas que prueban cada bloque de cdigo y sus
bifurcaciones. Esta experiencia nos indica que de poco sirve tener una herramienta de CI si no
nos preocupamos por entender la importancia de las pruebas y su repercusin directa en la
calidad del producto final.

Control de Versiones

Durante el desarrollo de MidasSistema X intentamos utilizar varias tcnicas con el uso del SVN
para mejorar nuestra productividad aunque con resultados no tan satisfactorios. Inicialmente
todos subamos nuestros cambios al trunk, pero conforme se incrementaban los commits, se
incrementaban tambin los problemas con los builds del trunk. Las ejecuciones de Bamboo
comenzaron a fallar con mucha frecuencia y se tom la decisin de utilizar un branch para el
desarrollo de cada componente (tcnica conocida como branching by feature), as cada ingeniero
poda subir sus cambios sin afectar el cdigo en el trunk. Pronto nos dimos cuenta que est
tcnica conllevaba un problema importante; al momento de terminar el componente, el ingeniero
deba incorporar sus cambios al trunk mediante un merge. El problema con esta tcnica es que si
el branch se mantiene fuera de sincrona con el trunk por mucho tiempo, el procedimiento para
reincorporarlo se vuelve muy complicado ya que requiere de mayor tiempo y esfuerzo del
ingeniero para realizarlo. Con esto no pretendemos decir que hacer un branch no est bien, sino
que hay que analizar bien la situacin para determinar la opcin que otorgue el mayor beneficio a
largo plazo. Otra tcnica que intentamos usar fue la de cerrar el trunk durante ciertos lapsos en
los que se requeran hacer pruebas de sistema. Se avisaba a todos los ingenieros que durante
cierto periodo se prohiban hacer incorporaciones al trunk para que no afectaran las pruebas. La
intencin era buena, sin embargo en este caso si creemos que hay mejores formas de hacerlo
como la creacin de un tag o un branch que en este caso si hubiera podido utilizarse sin la
complicacin del merge.

Automatizacin de Pruebas de Sistema

En MidasSistema X tuvimos la buena intencin de automatizar las pruebas de sistema con una
herramienta para simular las interacciones de un usuario desde el front-end, sin embargo por la
premura que se viva en aquel momento para terminar la aplicacin y liberarla, el equipo
designado para llevar a cabo las pruebas se vio limitado en tiempo y capacidad tcnica para
automatizarlas y se tom la decisin de realizarlas de manera manual. Como resultado de esa
decisin tuvimos que lidiar con las siguientes consecuencias:
Conforme se iban agregando ms funcionalidades, el set completo de pruebas iba
extendiendo su tiempo de ejecucin. Una o dos personas tardaban varias horas en ejecutar
todos los escenarios.
El proceso de pruebas comenz a depender de las personas que se volvieron expertas en
ejecutar las pruebas. Si alguno de los expertos llegaba a ausentarse, la ejecucin de las
pruebas no poda llevarse a cabo.
El proceso manual era propenso a errores u omisiones. En ms de una ocasin se
liberaron versiones con errores que debieron ser detectados en las pruebas de sistema.
Los ingenieros que ejecutaban las pruebas dedicaban prcticamente todo su tiempo a las
pruebas y por ello no podan apoyar en otras actividades.
La recomendacin es que siempre que sea posible automatizar las pruebas de sistema debemos
hacerlo. Cada proyecto es distinto y por eso es tarea conjunta del arquitecto y el lder de
proyecto definir la estrategia de pruebas desde un inicio.

La importancia del ambiente de pruebas

Normalmente en QuarksoftLa Empresa no se le presta demasiada importancia a los ambientes de
pruebas y en muchos casos las pruebas de sistema se llevan a cabo sobre los mismos equipos de
desarrollo. Creemos que el ambiente de ejecucin realmente impacta en los resultados de las
pruebas y que en la medida en que se le de mayor importancia a los ambientes de ejecucin, las
liberaciones van a tener un grado mayor de certidumbre. MidasSistema X es un buen ejemplo de
las consecuencias que se viven cuando no se tiene un cuidado adecuado de los ambientes de
ejecucin. Durante el desarrollo nunca contamos con la disponibilidad de un ambiente de pruebas
de sistema adecuado. Aunque se solicit un ambiente de pruebas con caractersticas especficas,
ste no pudo ser proporcionado por nuestra rea de GSTAC por lo que las pruebas se llevaron a
cabo en un equipo que no contaba con las caractersticas del servidor requerido y que ni siquiera
fue proporcionado por QuarksoftLa Empresa. Cuando lleg el da de instalar MidasSistema X
por primera vez en un ambiente productivo no logramos pasar ms all de la pantalla de login.
No habamos considerado las configuraciones necesarias para establecer una comunicacin
correcta con el directorio de usuarios para realizar el proceso de autenticacin. Tan solo esa
configuracin nos tom un par de das y noches. Ese fue el primero de varios obstculos que
encontramos antes de ver la aplicacin ejecutndose en el ambiente productivo. Basta decir que
desde ese primer intento de implantar la aplicacin en el ambiente productivo hasta el inicio de
las pruebas piloto pasaron varias semanas.

Pruebas de Requerimientos No Funcionales

Este es uno de los puntos que deben ser mayormente reforzados en QuarksoftLa Empresa
mediante una combinacin de guas metodolgicas y herramientas de monitoreo y
automatizacin de pruebas. Con MidasSistema X no se hicieron pruebas de capacidad previas a
su puesta en produccin. Dado que la liberacin ocurri de manera gradual, inicialmente no se
observaban problemas de desempeo con un nmero reducido de usuarios y las que se
observaron se atribuyeron en su momento a problemas con la red de transmisin de datos.
Conforme se fue incrementando el nmero de usuarios se empez a evidenciar algn problema
con el desempeo de la aplicacin y ante nuestra poca capacidad para demostrar
cuantitativamente lo contrario, NMP se decidi involucrar a un auditor externo que se apoy en
una herramienta para medir el desempeo de nuestra aplicacin. Como resultado de la auditora
se identificaron puntualmente varios cuellos de botella que estaban afectando el desempeo de la
aplicacin. Solo despus de esta experiencia comenzamos a utilizar una herramienta similar para
continuar haciendo pruebas por nuestra cuenta y seguir optimizando la aplicacin.

Pruebas de Deployment

Este tipo de pruebas ni siquiera es mencionado o considerado dentro de nuestros procesos, sin
embargo por experiencia sabemos que este set de pruebas es de gran importancia durante el
proceso de liberacin. La intencin principal de estas pruebas es detectar oportunamente
problemas con la versin a liberar antes de que los usuarios puedan accesarla. En MidasSistema
X no tenamos un set automatizado de pruebas de deployment ni un script formal de este tipo de
pruebas, sin embargo por lo general se llevaban a cabo pruebas manuales que consistan en
ingresar mediante el navegador a cada uno de los nodos del cluster y verificar que estaban
respondiendo de manera adecuada. Igualmente se probaba el acceso a travs de la URL que
apuntaba al balanceador de cargas y verificar que responda correctamente. Por ltimo se
ingresaba a la aplicacin con algn usuario en cada uno de los nodos lo cual nos permita
corroborar la correcta interaccin con el directorio LDAP y con la base de datos. Este set de
pruebas, aunque limitado, constitua nuestras pruebas de deployment y en algunas ocasiones nos
permiti detectar problemas con anticipacin suficiente para corregirlas o dar marcha atrs al
deployment. La gran desventaja de no haber tenido un set formal de pruebas de deployment
automatizado era que su ejecucin quedaba a juicio del responsable de desarrollo que validaba el
deployment. Las pruebas eran manuales y por tanto propensas a omisiones y al no formar parte
formal del proceso de deployment no siempre se llevaban a cabo. De ah la importancia que
nosotros vemos en generar un Plan de Liberacin y de automatizar en la medida de lo posible
tanto el deployment como las pruebas.

El factor humano

Un aspecto fundamental para el xito de MidasSistema X fue sin duda obtener la confianza total
del sponsor de la aplicacin desde antes del inicio del proyecto. Gracias a esta confianza se
presentaron condiciones favorables para el desarrollo y posterior implantacin del sistema. Por
ello consideramos que es de vital importancia para el proyecto lograr una identificacin temprana
de todas las personas involucradas de alguna forma con la aplicacin e involucrarlos desde el
inicio para preparar el terreno y lograr una colaboracin adecuada.
En el caso de MidasSistema X no todas las condiciones fueron favorables. Intereses polticos al
interior de NMP y el involucramiento de proveedores externos en la administracin de todos los
servidores y del desarrollo y mantenimiento de aplicaciones complicaron en muchos momentos
el proceso de liberacin. Es normal encontrar resistencia de reas internas que pueden generar
conflictos debido a que cada grupo responde a intereses distintos. No pretendemos dar una
solucin para este problema tan complejo, pero si queremos resaltar la importancia de las
interacciones personales en el xito de la liberacin de un producto de software. Existe un
movimiento dentro de la comunidad de desarrollo de software llamado DevOps que presenta
algunos principios y prcticas para lograr una colaboracin de todos los involucrados en la
liberacin de un producto de software. No pretendemos que QuarksoftLa Empresa adopte estos
principios, pero si destacar que sin duda la colaboracin y la dinmica social son una
preocupacin creciente en la industria del desarrollo de software y por ello consideramos que
debemos comenzar a darle mayor importancia a este tema estableciendo algunas estrategias y
guas que faciliten esta interaccin. La mayora de los que laboramos en QuarksoftLa Empresa
hemos tomado el curso de Semiologa y en mayor o menor medida tenemos la capacidad de
identificar los rasgos principales de cada tipo de persona. Sera interesante documentar los
perfiles de todas las personas del lado del cliente involucradas durante el desarrollo y liberacin
de la aplicacin como una referencia interna para entender a cada persona y estar preparados para
actuar de acuerdo a su personalidad.

La tcnica del Canario en la Mina de Carbn (Un detalle ms completo de la tcnica)

Esta tcnica consiste en liberar una nueva versin a un nmero limitado de usuarios mientras que
el grueso de los usuarios sigue accediendo a la versin estable. El uso de dicha tcnica permite
detectar rpidamente los posibles problemas y minimiza el impacto a un grupo pequeo y
controlado de usuarios. Esta tcnica se aplic con xito para MidasSistema X. La tcnica no se
plane desde un inicio sino que se utiliz como plan de contingencia a partir del crecimiento del
nmero de sucursales/usuarios que usaban la aplicacin. Al incrementar los usuarios se
incrementaba el impacto de liberar nuevas versiones defectuosas. Por ello se decidi tener un
servidor alterno en el que se liberaba la nueva versin y que era accedido solamente por una de
las sucursales mientras el resto de las sucursales continuaba accediendo al servidor principal con
la versin estable. De esta manera la sucursal piloto se convirti en nuestro canario en la mina de
carbn. Idealmente estas y otras tcnicas similares deben planearse desde el inicio del proyecto
con el fin de minimizar los riesgos al liberar nuevas versiones del software.

Estrategia de Capacitacin

La capacitacin es un tema contemplado por nuestros procesos, sin embargo no existen muchas
guas en cuanto a la ejecucin o a las tcnicas que pueden ser usadas para facilitarla. En el caso
de MidasSistema X la capacitacin involucr toda una logstica muy particular ya que la
distribucin geogrfica de los usuarios estaba determinada por la ubicacin de las ms de 200
sucursales de NMP en todo el pas. La estrategia parti de una implantacin gradual en la que la
aplicacin se liberaba en un nmero reducido de sucursales cada semana. La transicin se haca
los fines de semana a partir de los viernes cuando se enviaba personal de soporte a la aplicacin
para preparar y configurar los equipos y dar la capacitacin al personal de la sucursal durante el
fin de semana. A partir del lunes se iniciaba la operacin de esas sucursales en la nueva
aplicacin y el personal de soporte se mantena en sitio durante dos das ms para apoyarlos
durante esta transicin y resolver cualquier problema de manera inmediata. Esta estrategia dio
buenos resultados y adicionalmente permiti a algunos miembros del equipo de desarrollo
participar como capacitadores en sitio durante el proceso de implantacin. Las ventajas que
vemos en involucrar al equipo de desarrollo en esta actividad son:
El equipo tuvo retroalimentacin de primera mano del los usuarios finales sobre la
aplicacin.
Se tuvo la oportunidad de observar el desempeo de la aplicacin ejecutndose en el
ambiente operativo.
Al conocer y ver de cerca la operacin real se obtiene informacin muy valiosa sobre el
negocio y sobre la dinmica de los usuarios en la operacin real.
Mayor comprensin de las necesidades y problemas que viven los usuarios en el da a
da.
Se identifican ms fcilmente problemas de usabilidad que de no identificarse
posteriormente pueden reportarse por los usuarios de manera inadecuada como problemas
de desempeo.
Al involucrarnos en la dinmica del negocio se entiende y se adquiere el sentido de
urgencia e importancia que los usuarios tienen al solicitar ayuda del equipo de soporte.



D. Anlisis de herramientas

Generadores de carga:
Un generador de carga permite simular picos de carga sobre servidores, redes u otros objetos,
permitiendo as encontrar facilmente cuellos de botella en las aplicaciones.

JMeter (Apache):
Carga y ejecucin de pruebas en diferentes tipos de serivdores (Web, SOAP, DB, LDAP,
JMS, MAIL, etc)
Portabilidad, ya que es 100% java
Grabacin de flujos mediante un macro
Construccin de flujos mediante los parmetros del GET / POST
Permite realizar un anlisis de manera grafica del resultado de las pruebas ejecutadas
Silkperfomer (Borland):
Lo mismo que el anterior pero de manera ms amigable
Soporte Web 2.0 (Flash, Flex, Silverlight, Ajax y HTML)
Modelo de pruebas hibridas (ya sea en local o en la nube)
Integra el diagnostico de la causa raz del problema

Profilers
Hoy en da las aplicaciones han ido cambiando, a tal grado de tener aplicaciones distribuidas,
virtualizadas, clusterizadas, etc. Por lo que desarrolladores, reas de calidad y hasta los dueos
del negocio tienen que trabajar de manera conjunta para poder maximizar el valor del negocio.
De lo anterior es difcil liberar una aplicacin, sin problemas de desempeo, consumos mnimos
de anchos de banda, cuellos de botella, optimizacin de algoritmos entre otras cosas. Abajo se
muestran las caractersticas de algunas herramientas que ayudan en la solucin de problemas de
este tipo.

JConsole (Oracle, OpenSource)
JConsole es una herramienta de monitoreo, la cual hace un completo uso de JMX sobre la
Maquina Virtual para extraer informacin de desempeo y consumo de recursos de las
aplicaciones que estn corriendo sobre la plataforma Java.

Principales caractersticas:
Tiempos de procesamiento en CPU
Medicines de memoria en el sistema
En general da una idea de cmo se comporta la mquina virtual (comportamiento de GC,
Threads)
Dynatrace (Comercial)
No intrusivo al cdigo pero si al Application Server. Requiere modificacin de scripts de
arranque
Deteccin y aislamiento de problemas de forma sencilla y rpida
Acta de forma similar a un debugger remoto
Proporciona toda la informacin sobre rbol de invocacin, tiempos de ejecucin de
mtodos, querys ejecutados.
Permite graficar el tiempo que se tarda cada framework (porcentajes)
Vista de threads, comportamiento, consumo de memoria, etc...
Interfaz amigable al usuario final.

JProfiler (Comercial)
Muy parecido a Dynatrace pero menos legible e intuitivo
Excelente soporte para JEE
Tiempos que hay dentro de calls de rbol de invocacin
Monitoreo de CPU y memoria
Es extensible (Permite la creacin de profilers personalizados de acuerdo a las
necesidades)
Mnimo overhead
Permite detectar facilmente cuellos de botella
Mucho mas barata que Dynatrace

Yourkit
Monitoreo de CPU y Memoria
Monitoreo sobre demanda
Libre distribucin en produccin (DLL)
Completo soporte para J2E y .NET
Soporte para Java 5, 6 y 7
Licencias comerciales y open source

Automatizacin de pruebas
TestMaker
Automatizacin de pruebas de integracin
Permite correr pruebas en ambientes grid y en la nube
Soporta Ajax, SOA, RIA, Flex, Flash y REST
Construccin de pruebas de forma sencilla (grabado para aplicaciones web, herramienta
grafica para construccin de pruebas SOA/REST ,soporte para pruebas escritas en Java,
Jython, Ruby y cualquier lenguaje dinamico de scripting)
Integracin con Maven
Open Source (Versin libre y versin Pro de paga)
Monitoreo de CPU, deteccin de Memory leaks
Corre en cualquier plataforma (Linux, Mac, Windows)
Soporte para cualquier navegador comercial (IE, Firefox, Chrome y Opera)