REVISTA LATINOAMERICANA

DE INGENIERIA DE SOFTWARE
OCTUBRE 2013 VOLUMEN 1 NUMERO 5 ISSN 2314-2642

PUBLICADO POR EL GISI-UNLa

EN COOPERACIN POR LOS MIEMBROS DE LA RED DE INGENIERA DE SOFTWARE DE LATINOAMRICA

ARTCULOS TCNICOS

PSPVDC: Una Propuesta que Incorpora el Diseo por Contrato Verificado al Personal 153-166
Software Process
Silvana Moreno, lvaro Tasistro, Diego Vallespir

Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: 167-206

Un Enfoque Prctico
Eduardo Diez

Estudio Comparativo de Plataformas Cloud Computing para Arquitecturas SOA 207-236

Franco Bocchio
 REVISTA LATINAMERICANA
DE INGENIERIA DE SOFTWARE

La Revista Latinoamericana de Ingenieria del Software es una publicacin tecnica auspiciada por la Red de Ingeniera de Software de Latinoamrica (RedISLA). Busca: [a] difundir artculos tcnicos,
empricos y tericos, que resulten crticos en la actualizacin y fortalecimiento de la Ingeniera de Software Latinoamericana como disciplina y profesin; [b] dar a conocer de manera amplia y rpida los
desarrollos cientfico-tecnolgicos en la disciplina de la regin latinoamericana; y [c] contribuir a la promocin de la cooperacin institucional entre universidades y empresas de la Industria del Software. La
lnea editorial, sin ser excluyente, pone nfasis en sistemas no convencionales, entre los que se prevn: sistemas mviles, sistemas, plataformas virtuales de trabajo colaborativo, sistemas de explotacin de
informacin (minera de datos), sistemas basados en conocimiento, entre otros; a travs del intercambio de informacin cientfico y tecnolgica, conocimientos, experiencias y soluciones que contribuyan a
mejorar la cadena de valor del desarrollo en la industria del software.

Comit Editorial
RAUL AGUILAR VERA (Mxico) BELL MANRIQUE LOSADA (Colombia) JOS ANTONIO POW-SANG (Per)
Cuerpo Academico de Ingenieria de Software Programa de Ingeniera de Sistemas Maestra en Informtica
Facultad de Matemticas Facultad de Ingeniera Pontifica Universidad Catlica del Per
Universidad Autonoma de Yucatn Universidad de Medelln
DIEGO VALLESPIR (Uruguay)
PAOLA BRITOS (Argentina) CLAUDIO MENESES VILLEGAS (Chile) Instituto de Computacin
Grupo de Ingeniera de Explotacin de Informacin Departamento de Ingeniera de Sistemas y Computacin Universidad de la Republica
Laboratorio de Informtica Aplicada Facultad de Ingeniera y Ciencias Geolgicas
Universidad Nacional de Ro Negro Universidad Catlica del Norte FABIO ALBERTO VARGAS AGUDELO (Colombia)
Direccin de Investigacin
RAMON GARCA-MARTINEZ (Argentina) JONS MONTILVA C. (Venezuela) Tecnolgico de Antioquia
Grupo de Investigacin en Sistemas de Informacin Facultad de Ingeniera
Licenciatura en Sistemas Escuela de Ingeniera de Sistemas CARLOS MARIO ZAPATA JARAMILLO (Colombia)
Departamento de Desarrollo Productivo y Tecnolgico Universidad de Los Andes Departamento de Ciencias de la Computacin y de la
Universidad Nacional de Lans Decisin
MARA FLORENCIA POLLO-CATTANEO (Argentina) Facultad de Minas
ALEJANDRO HOSSIAN (Argentina) Grupo de Estudio en Metodologas de Ingeniera de Universidad Nacional de Colombia
Grupo de Investigacin de Sistemas Inteligentes en Software
Ingeniera Facultad Regional Buenos Aires
Facultad Regional del Neuqun Universidad Tecnolgica Nacional
Universidad Tecnolgica Nacional

Contacto

Dirigir correspondencia electrnica a: Dirigir correspondencia postal a:

Editor de la Revista Latinoamericana de ngenieria de Software
RAMON GARCIA-MARTINEZ
e-mail: rgarcia@unla.edu.ar
e-mail alternativo: rgm1960@yahoo.com
Pgina Web de la Revista: http://www.unla.edu.ar/sistemas/redisla/ReLAIS/index.htm
Pgina Web Institucional: http://www.unla.edu.ar
Editor de la Revista Latinoamericana de ngenieria de Software
RAMON GARCIA-MARTINEZ
Licenciatura en Sistemas. Departamento de Desarrollo Productivo y Tecnolgico
Universidad Nacional de Lanus
Calle 29 de Septiembre No 3901. (1826) Remedios de Escalada, Lans.
Provincia de Buenos Aires. ARGENTINA.

Normas para Autores

Cesin de Derechos de Autor
Los autores toman conocimiento y aceptan que al enviar una contribucin a la Revista
Latinoamericana de Ingenieria del Software, ceden los derechos de autor para su publicacin
electrnica y difusin via web por la Revista. Los demas derechos quedan en posesin de los
Autores.
Polticas de revisin, evaluacin y formato del envo de manuscritos
La Revista Latinoamericana de Ingenieria del Software recibe artculos inditos, producto del trabajo
de investigacin y reflexin de investigadores en Ingenieria de Software. Los artculos deben
presentarse redactados en el castellano en el formato editorial de la Revista. El incumplimiento del
formato editorial en la presentacin de un artculo es motivo de retiro del mismo del proceso de
evaluacin. Dado que es una publicacin electrnica no se imponen limites sobre la cantidad de
paginas de las contribuciones enviadas. Tambin se pueden enviar comunicaciones cortas que den
cuenta de resultados parciales de investigaciones en progreso.
Las contribuciones recibidas estn sujetas a la evaluacin de pares. Los pares que evaluaran cada
contribucin son seleccionados por el Comit Editorial. El autor que enve la contribucin al contacto
de la Revista ser considerado como el autor remitente y es con quien la revista manejar toda la
correspondencia relativa al proceso de evaluacin y posterior comunicacin.
Del proceso de evaluacin, el articulo enviado puede resultar ser: [a] aceptado, en cuyo caso ser
publicado en el siguiente numero de la revista, [b] aceptado con recomendaciones, en cuyo caso se
enviar al autor remitente la lista de recomendaciones a ser atendidas en la nueva versin del
articulo y su plazo de envio; [c] rechazado, en cuyo caso ser devuelto al autor remitente
fundando el motivo del rechazo.
Temtica de los artculos
La Revista Latinoamericana de Ingeniera del Software busca artculos empricos y tericos que
resulten crticos en la actualizacin y fortalecimiento de la Ingeniera de Software Latinoamericana
como disciplina y profesin.
La lnea editorial pone nfasis en sistemas no convencionales, entre los que se prevn: sistemas
mviles, sistemas multimediales vinculados a la televisin digital, plataformas virtuales de trabajo
colaborativo, sistemas de explotacin de informacin (minera de datos), sistemas basados en
conocimiento, entre otros. Se privilegiarn artculos que contribuyan a mejorar la cadena de valor
del desarrollo en la industria del software.
Poltica de Acceso Abierto
La Revista Latinoamericana de Ingeniera de Software:
Sostiene su compromiso con las polticas de Acceso Abierto a la informacin cientfica, al
considerar que tanto las publicaciones cientficas como las investigaciones financiadas con
fondos pblicos deben circular en Internet en forma libre, gratuita y sin restricciones.
Ratifica el modelo de Acceso Abierto en el que los contenidos de las publicaciones cientficas se
encuentran disponibles a texto completo libre y gratuito en Internet, sin embargos temporales, y
cuyos costos de produccin editorial no son transferidos a los autores.
No retiene los derechos de reproduccin o copia (copyright), por lo que los autores podrn
disponer de las versiones finales de publicacin, para difundirlas en repositorios institucionales,
blogs personales o cualquier otro medio electrnico, con la sola condicin de hacer mencin a la
fuente original de publicacin, en este caso Revista Latinoamericana de Ingeniera de Software.
Lista de Comprobacin de Preparacin de Envos
Como parte del proceso de envo, se les requiere a los autores que indiquen que su envo cumpla con
todos los siguientes elementos, y que acepten que envos que no cumplan con estas indicaciones
pueden ser devueltos al autor:
1. La contribucin respeta el formato editorial de la Revista Latinoamericana de Ingenieria del
Software (ver plantilla).
2. Actualidad/Tipo de referencias: El 45% de las referencias debe hacerse a trabajos de publicados
en los ltimos 5 aos, as como a trabajos empricos, para cualquier tipo de artculo (emprico o
terico).
3. Caractersticas artculos empricos (anlisis cuantitativo de datos): Se privilegian artculos
empricos con metodologas experimentales y cuasi experimentales, con pruebas estadsticas
robustas y explicitacin del cumplimiento de los supuestos de las pruebas estadsticas usadas.
4. Caractersticas artculos empricos (anlisis cualitativo de datos): Se privilegian artculos
empricos con estrategias de triangulacin terica-emprica, definicin explcita de categoras
orientadoras, modelo terico de anlisis, y anlisis de datos asistido por computadora.
5. Caractersticas artculos de revisin: Para el caso de artculos de revisin, se evaluar que los
mismos hayan sido desarrollados bajo el formato de meta anlisis, la cantidad de referencias
deben superar las 50, y deben explicitarse los criterios de bsqueda, bases consultadas y
pertinencia disciplinar del artculo.
6. El artculo (en formato word y pdf) se enviar adjunto a un correo electrnico dirigido al contacto
de la Revista en el que deber constar la siguiente informacin: direccin postal del autor,
direccin de correo electrnico para contacto editorial, nmero de telfono y fax, declaracin de
que el artculo es original, no ha sido previamente publicado ni est siendo evaluado por otra
revista o publicacin. Tambin se debe informar de la existencia de otras publicaciones similares
escritas por el autor y mencionar la versin de la aplicacin de los archivos remitidos (versin del
editor de texto y del conversor a archivo pdf) para la publicacin digital del artculo.
7. Loa Autores aceptan que el no cumplimiento de los puntos anteriores es causal de No Evaluacin
del articulo enviado.
Compromiso de los Autores de Artculos Aceptados
La Revista Latinoamericana de Ingeniera del Software busca ser una revista tcnica de calidad, en
cuyo desarrollo estn involucrados los investigadores y profesionales latinoamericanos de la
disciplina. En este contexto, los Autores de artculos aceptados asumen ante la Revista y la
Comunidad Latinoamericana de Ingeniera del Software el compromiso de desempearse como pares
evaluadores de nuevas contribuciones.
 PSPVDC: Una Propuesta que Incorpora el Diseo por
Contrato Verificado al Personal Software Process
Silvana Moreno
Facultad de Ingeniera Escuela de Ingeniera
Universidad de la Repblica Universidad ORT Uruguay
Montevideo, Uruguay Montevideo, Uruguay
smoreno@fing.edu.uy tasistro@ort.edu.uy
ResumenEl desarrollo de software se ha vuelto una actividad
muy importante en el mundo actual. Existen nmeros procesos
de desarrollo de software que buscan aumentar la calidad de los
productos y disminuir los tiempos de salida al mercado. Sin
embargo, el software contiene defectos y stos causan fallas
potencialmente graves durante su ejecucin. Este trabajo
propone un nuevo proceso de desarrollo de software denominado
PSPVDC que combina el enfoque del Personal Software Process
(PSP) y del Diseo por Contrato Verificado (VDbC) con el
objetivo de mejorar la calidad de los productos con respecto al
PSP. Adems se presenta una revisin sistemtica de la literatura
que busca conocer las adaptaciones al PSP que hayan sido
documentadas, en particular aquellas que incorporan mtodos
formales.
Trminos Clavemtodos formales, diseo por contrato
verificado, personal software process, revisin sistemtica.
I. INTRODUCCION
La construccin de software confiable es uno de los
desafos de la Ingeniera de Software. El tamao, la
complejidad de las aplicaciones de software, las tasas
apresuradas de entregas de proyectos, las caractersticas de los
equipos de desarrollo, entre otros, hacen que los productos de
software contengan defectos. Estos defectos pueden ocasionar
fallas en el software mientras ste se est ejecutando [1]. La
presencia de defectos provoca un alto costo de correccin de
las aplicaciones, as como una prdida de confianza en el
mismo. La bsqueda de desarrollar software cero defectos ha
dado lugar a un gran nmero de procesos y metodologas de
desarrollo.
El Personal Software Process (PSP) es uno de estos
procesos. El PSP aplica disciplina de proceso y gestin
cuantitativa al trabajo individual del ingeniero de software.
Promueve la utilizacin de prcticas especficas durante todas
las etapas del desarrollo con el objetivo de mejorar la calidad
del producto y aumentar la productividad del individuo [2], [3].
Por otro lado, los mtodos formales tambin buscan
construir software cero defectos. Estos mtodos son un
conjunto de tcnicas y herramientas para especificar,
desarrollar y verificar sistemas software mediante el uso de
lenguaje matemtico formalizado. Consisten en demostrar
matemticamente que los programas producidos cumplen sus
especificaciones.
El diseo por contrato (DbC) es una tcnica para el diseo
de los componentes de un sistema de software, mediante su
especificacin en un lenguaje formal, generalmente en la forma
Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
lvaro Tasistro Diego Vallespir
Facultad de Ingeniera
Universidad de la Repblica
Montevideo, Uruguay
dvallesp@fing.edu.uy
de pre- y post-condiciones escritas en Lgica de Primer Orden.
Cuando las tcnicas y herramientas incorporadas permiten
demostrar que se cumplen las especificaciones establecidas,
estamos en presencia de un mtodo formal, generalmente
llamado Verified Design by Contract (VDbC).
En este artculo se presenta una adaptacin del PSP que
incorpora VDbC con el objetivo de mejorar, en comparacin
con el uso del PSP sin VDbC, la calidad de los productos
desarrollados. Se denomina a esta propuesta PSPVDC.
Esperamos de esta forma aportar en la bsqueda de
procesos que ayuden a desarrollar productos de software muy
cercanos a cero defectos.
La estructura del artculo es la siguiente: primero se
presentan las nociones bsicas del diseo por contrato y el PSP
(secciones II y III). Luego en la seccin IV se presenta una
revisin sistemtica de la literatura realizada con el propsito
de conocer las adaptaciones existentes al PSP que incorporan
mtodos formales. En la seccin V se presenta el PSPVDC y la
seccin VI presenta algunas medidas de calidad del PSPVDC.
Finalmente, se indican las conclusiones obtenidas (seccin
VII).
II. DISEO POR CONTRATO
Los mtodos formales son un conjunto de tcnicas para
especificar, desarrollar y verificar sistemas de software
mediante el uso del lenguaje matemtico. Consisten en
demostrar matemticamente que los programas producidos
cumplen sus especificaciones.
El Diseo por Contratos (DBC) es un mtodo propuesto
por Bertrand Meyer, e inspirado en las ternas de Hoare, para
especificar el comportamiento de mdulos de software [4], [5].
La idea principal detrs de DBC es que una clase y sus
clientes tienen un "contrato" entre s. Los clientes deben
garantizar ciertas condiciones antes de llamar a un mtodo
definido por la clase, y en cambio la clase da como garantas a
los clientes ciertas propiedades que se cumplen luego de
finalizada la ejecucin del mtodo invocado.
Ciertas implementaciones del DbC permiten que los
contratos sean verificables en tiempo de ejecucin. Los
contratos son incluidos en el cdigo del programa en una
determinada sintaxis, y se traducen a cdigo ejecutable por el
compilador. Por lo tanto, cualquier violacin del contrato que
se produce mientras se ejecuta el programa puede ser detectado
inmediatamente.
153
 Los contratos de software se especifican mediante la
utilizacin de expresiones lgicas denominadas aserciones.
Existen diferentes tipos de aserciones, entre ellas se encuentran
las precondiciones y las poscondiciones de programas. En lo
que refiere a los contratos en la orientacin a objetos las
precondiciones y poscondiciones normalmente se definen a
nivel de los mtodos de las clases.
Una precondicin establece lo que espera recibir el
proveedor. Visto de otro modo, define las condiciones que
debe garantizar el cliente al momento de pedirle al proveedor
cierto servicio.
Una poscondicin da como garantas al cliente ciertas
propiedades que se cumplen despus de la llamada al mtodo.
En definitiva, especifica lo que se cumple luego de que se
ejecuta el mtodo. Visto desde el lado del proveedor, la
poscondicin es lo que ste debe asegurar que se cumpla,
siempre y cuando la precondicin se respete al momento de
invocar el servicio.
El Java Modeling Language, abreviado JML y en espaol
Lenguaje de Modelado para Java es un lenguaje de
especificacin para programas Java. Las especificaciones JML
describen formalmente el comportamiento de clases y mtodos;
se escriben como comentarios de anotacin Java en el cdigo
fuente, que luego pueden compilarse con
cualquier compilador de Java [6].
Aadir especificaciones JML a un programa ayuda a
comprender qu funcin debe realizar un mtodo o una clase.
Tambin ayuda a encontrar defectos en los programas, puesto
que se puede comprobar si un mtodo cumple con su
especificacin cada vez que se ejecuta.
Existen herramientas que permiten compilar la
especificacin formal para ciertos lenguajes de especificacin.
Para el JML existe el compilador JMLC, este es una extensin
de un compilador Java y compila los programas Java con
especificaciones JML. En el cdigo generado se agregan
instrucciones ejecutables que chequean en tiempo de ejecucin
si los mtodos cumplen con sus especificaciones. En caso de
que una especificacin no se cumpla, se interrumpe la
ejecucin del programa y se notifica cul es la especificacin
no respetada. Esto permite detectar defectos y por ende se
puede utilizar como una forma de probar el programa durante
el desarrollo de software.
El JML dispone de dos clusulas especficas para indicar
las precondiciones y las poscondiciones de un mtodo: requires
y ensures. Estas clusulas deben ir situadas justo antes de la
declaracin del mtodo.
Adems, el JML aade un conjunto de operadores que hace
ms cmodo en muchos casos construir aserciones complejas.
Entre estos operadores se incluyen los cuantificadores ms
comunes (\forall, \exists, \sum, \product, \max, \min, etc) que
hacen del JML un lenguaje similar al lenguaje de predicados de
lgica.
Tambin el JML define dos seudo variables que pueden ser
utilizadas en las poscondiciones de los mtodos; \result: valor
devuelto por el mtodo y \old(E): valor de la expresin E al
comenzar la ejecucin del mtodo.
Presentamos a continuacin una forma de especificar
utilizando JML el mtodo merge. Dicho mtodo recibe como
parmetros dos vectores de enteros ordenados de menor a
mayor. El mtodo retorna otro vector con esos elementos
ordenados de menor a mayor. Adems, los vectores de entrada
154 Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
no deben ser alterados, es decir, sus valores se mantienen
incambiados al salir del mtodo.
La firma del mtodo es la siguiente:
public int[] getMerge(int[] a, int[] b)
Al invocar al mtodo se deben pasar dos vectores
ordenados de menor a mayor, lo que nos indica una
precondicin que se debe cumplir. Para cumplir con dicha
precondicin es necesario que para todos los elementos del
vector se cumpla que el elemento que est en la posicin i del
vector sea menor o igual al elemento que se encuentra en la
posicin i+1.
Una forma de especificar formalmente dicha precondicin
se muestra en las siguientes dos aserciones.
/*@ requires (\forall int i; i >= 0 && i < a.length-1;
a[i] <= a[i+1]); @*/
/*@ requires (\forall int j; j >= 0 && j < b.length-1;
b[j] <= b[j+1]); @*/
El cuantificador \forall sirve para recorrer el vector desde
una posicin y en determinado rango, haciendo cumplir
determinada condicin. En este caso se recorren los vectores y
chequea que para todos elementos el valor de a[i] sea menor o
igual al de a[i+1]. La forma de leer la precondicin es Para
todo i entre cero (inclusive) y el largo del vector menos 1 (sin
incluir ste) se cumple que a[i] es menor o igual a a[i+1].
Al terminar de ejecutarse el mtodo se debe cumplir que los
vectores de entrada no fueron alterados. Esto se especifica
como una poscondicin y una forma de especificarlo es
utilizando la pseudovariable \old(e).
Se recorren los vectores de entrada y verifica que para
todos sus elementos el valor en cada posicin despus de
llamar al mtodo es igual al que tenia previo al llamado (a[i] =
= \old(a[i])).
/*@ ensures (\forall int i; i >= 0 && i <= a.length-1;
a[i] == \old(a[i])); @*/
/*@ ensures (\forall int j; j >= 0 && j <= b.length-1;
b[j] == \old(b[j])); @*/
Cabe aclarar, que en ambos casos se podra haber utilizado
la misma variable cuantificadora (i) ya que es local al \forall.
Hasta aqu hemos tenido en cuenta las precondiciones y
poscondiciones para los vectores de entrada al mtodo.
Veamos ahora las condiciones que se deben cumplir en lo que
respecta al vector esperado como resultado del mtodo.
Como se mencion anteriormente el vector devuelto debe
contener de forma ordenada los mismos elementos que los
vectores pasados por parmetro.
Para referenciar al vector resultado se utiliza la
pseudovariable \result y se recorre el mismo, como ya vimos
anteriormente, para verificar el ordenamiento de los elementos
de menor a mayor.
/*@ ensures (\forall int k; k >= 0 && k < \result.length-1;
\result[k] <= \result[k+1]); @*/
por Contrato Verificado al Personal Software Process
 Una forma de especificar informalmente que el vector
devuelto contenga los mismos elementos de los vectores
pasados por parmetro y no otros es:
Si denominamos |v|x la cantidad de veces que el
elemento x aparece en el vector v, entonces: para cada
elemento x que aparece en el vector resultado r, se
cumple |r|x = |a|x + |b|x.
El largo del vector resultado debe ser igual a la suma
del largo de los vectores a y b.
Especificamos formalmente que el largo del vector
resultado es igual a la suma del largo del vector a y el b de la
siguiente forma:
/*@ ensures \result.length == (a.length + b.length); @*/
Para especificar que cada elemento del vector resultado
aparece en l tantas veces como en los dos vectores de entrada
utilizamos \num_of. Este cuantificador permite contar la
cantidad de elementos de los vectores. Especificamos que para
todos los elementos del vector resultado la cantidad de
elementos repetidos es igual a la suma de los mismos
elementos repetidos en a y en b.
Formalmente especificamos como sigue:
/*@ ensures (\forall int i; i>= 0 && i < \result.length;
(int)(\num_of int j; j>=0 && j<\result.length; \result[j]
== \result[i]) == (int)(\num_of int j; j>=0 &&
j<a.length; a[j] == \result[i]) + (int)(\num_of int j;
j>=0 && j<b.length; b[j] == \result[i]) ); @*/
La especificacin completa para el mtodo getMerge se
muestra de forma ms clara en la figura 2.
La especificacin de contratos ejecutables permite
introducir pruebas en el propio cdigo y son muy efectivas
para encontrar defectos durante el desarrollo de software. Sin
embargo, como se desprende de este ejemplo, las
especificaciones formales no son sencillas y tienen, como
cualquier actividad, un costo asociado. Como con cualquier
otra tcnica se debe estudiar el costo-beneficio previamente a
aplicarla.
III. PERSONAL SOFTWARE PROCESS
El Personal Software Process, conocido por sus siglas como
PSP, es una metodologa de desarrollo de software creada por
el Instituto de Ingeniera del Software (SEI). Est dirigido a los
ingenieros, permitiendo mejorar la forma en la que construyen
software. Considera aspectos como la planificacin, calidad,
estimacin de costos y productividad.
El PSP fue diseado para ayudar a los ingenieros a seguir
un proceso disciplinado de ingeniera del software,
ensendoles a planificar y dar seguimiento al trabajo,
utilizando un proceso bien definido y medido. Se caracteriza
por ser de uso personal y se aplica a programas pequeos de
menos de 10.000 lneas de cdigo. Se centra en la
administracin del tiempo y en la administracin de
la calidad a travs de la eliminacin temprana de defectos [2],
[3].
Los principios del PSP son:
Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
Cada ingeniero es diferente, para ser ms
eficiente, debe planificar su trabajo basndose en su
experiencia personal.
Usar procesos bien definidos y cuantificados.
Los ingenieros deben asumir la responsabilidad
personal de la calidad de sus productos.
Cuanto antes se detecten y corrijan los errores menos
esfuerzo ser necesario.
Es ms efectivo evitar los defectos que detectarlos y
corregirlos.
Trabajar bien es siempre la forma ms rpida y
econmica de trabajar.
El PSP define un conjunto de fases que el ingeniero sigue
durante el proceso desarrollo. Todas las tareas y actividades
realizadas en estas fases estn definidas en un conjunto de
documentos conocidos como scripts. Los scripts permiten
seguir el proceso de forma disciplinada, y ayudan al ingeniero
a identificar sus fortalezas y sus debilidades, y crecer a travs
de un proceso de aprendizaje y mejora.
Las fases son Planning, Design, Design Review, Code,
Code Review, Compile, Unit Test, y Post Mortem. La figura 1
muestra las fases de PSP.
Fig. 1. Fases del PSP
Para cada fase el ingeniero recoge la informacin del
tiempo empleado en la fase y los defectos inyectados y
removidos. La informacin sobre los defectos incluye el tipo de
defecto, el tiempo en detectar y corregir el defecto, la fase en la
que se inyecta y la fase en la que se remueve. El PSP define 10
tipos de defectos a utilizar. La tabla I presenta los tipos de
defectos junto con una breve descripcin de los defectos que
deben registrarse para cada tipo.
El PSP propone una vista de cuatro dimensiones para lograr
un diseo completo. En la vista interna-esttica se especifica la
lgica interna del programa, normalmente el pseudo cdigo. La
vista interna-dinmica corresponde a las posibles maquinas de
estado, es decir, los estados, las transiciones y acciones entre
estados que puede tener el programa.
155
 Fig. 2. Especificacin mtodo getMerge

formas de estimar tiempos y tamao. Los nombres de los

procesos y los elementos que se van incorporando durante el
TABLA I. TIPOS DE DEFECTOS DEL PSP curso se muestran en la figura 3. El nivel 2.1 es el proceso
completo del PSP.
Tipo Nombre Descripcin
10 Documentacin Comentarios o mensajes
20 Sintaxis Ortografa, puntuacin, tipos, formato
de instrucciones
30 Componentes o Administracin de cambios, control de
configuracin versiones, bibliotecas
40 Asignacin Declaracin, nombres duplicados,
alcance, lmites
50 Internas Llamados y referencias a
procedimientos, E/S, formatos de
usuarios
60 Chequeo de tipos Mensajes de error, chequeos
inadecuados
70 Datos Estructura, contenido
80 Funcin o lgicos Defectos por lgica, apuntadores, ciclos,
recursin, clculos, funciones
90 Sistema Configuracin, sincronizacin, memoria
100 Ambiente Problemas de diseo, compilacin,
prueba, u otros con los sistemas de
desarrollo

La vista externa-esttica corresponde a la estructura de

clases y la vista externa-dinmica define las interacciones entre
el sistema y el usuario (diagramas de casos de uso, diagrama de
secuencia del sistema, etc). La informacin recabada en cada
una de estas vistas es definida en cuatro templates como se
Fig. 3. Niveles del PSP
muestra en la tabla II.
TABLA II. TEMPLATES DE DISEO DEL PSP
IV. REVISIN SISTEMTICA
Interna Externa
Esttica Logic Specfication Template Function Specfication
Es de nuestro inters conocer las adaptaciones al PSP que
Template hayan sido documentadas, en particular nos interesa conocer
Dinmica State Machine Template Operational Specification las adaptaciones que incorporan mtodos formales.
Template Presentamos en esta seccin una revisin sistemtica que busca
conocer la literatura existente sobre adaptaciones al PSP.
El PSP se ensea mediante un curso. Durante el mismo, los Una revisin sistemtica de la literatura es un medio de
ingenieros construyen programas de software (ejercicios) identificacin, evaluacin e interpretacin de toda la
mientras aprenden progresivamente a planificar, desarrollar y informacin que se disponga relativa a una pregunta de
seguir las prcticas del PSP. En el primer ejercicio, se investigacin, rea temtica o fenmeno de inters [7].
comienza con un proceso simple (el proceso base, llamado PSP La revisin sistemtica realizada responde a dos preguntas
0); a medida que se avanza en el proceso se agregan nuevas de investigacin:
fases como Design Review y Code Review, as como tambin
156 Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
 (1) Se han realizado adaptaciones al PSP?
(2) Las adaptaciones propuestas al PSP incorporan
mtodos formales? Cmo lo hacen?
Para responder a estas preguntamos definimos un protocolo
que especifica los mtodos que se utilizan para llevar a cabo la
revisin sistemtica. Se define la cadena de bsqueda que
consta de tres partes. La primera parte est relacionada con las
formas de nombrar el Personal Software Process, la segunda
parte con los posibles sinnimos de la palabra adaptar, es
decir las diferentes formas de presentar un cambio al PSP y la
ltima parte se refiere al uso de mtodos formales. Las
bsquedas fueron realizadas en bibliografa en idioma ingls,
por ende la cadena de bsqueda es en ingls:
(personal software process) and ((adapting or extending or
over or incorporating) or (formal methods or design by
contract))
Las bibliotecas digitales utilizadas para la bsqueda de
artculos fueron SCOPUS, Springer, IEEE Xplore y EBSCO.
Estos buscadores abarcan las principales colecciones de
revistas y actas de conferencias de ingeniera de software.
Adems, se realiz una bsqueda de forma manual en A
Bibliography of the Personal Software Process (PSP) and the
Team Software Process (TSP) y en las actas de los Simposios
TSP realizados desde el 2006 al 2012. A Bibliography of the
Personal Software Process (PSP) and the Team Software
Process (TSP) es un documento creado por el Software
Engineers Institute (SEI) que contiene libros, captulos,
secciones y publicaciones en general referentes a PSP y TSP.
Esta bsqueda permite encontrar trabajos realizados con
respecto al tema de inters que posiblemente no hayan sido
indexados en las bibliotecas digitales.
Cada artculo encontrado en la bsqueda es evaluado para
decidir si debe o no incluirse teniendo en cuenta el ttulo, las
palabras claves y el resumen. Aquellos artculos que cumplan
al menos una de las siguientes condiciones sern excluidos:
No se centran en el Personal Software Process
Captulos de libros o libros
Duplicados en diferentes fuentes
No escritos en ingls
No propongan una adaptacin al PSP o no incorporen
mtodos formales al mismo
Debido a que la cantidad de artculos que se espera
encontrar es muy baja optamos por no realizar un control de la
calidad de los artculos.
La sntesis de datos consistir en agrupar a los artculos en
base a las dos preguntas de investigacin planteadas, es decir,
si es un artculo que adapta a PSP mediante la incorporacin de
mtodos formales, si es un artculo que adapta a PSP en
cualquier otro aspecto o si es un artculo que utiliza mtodos
formales con PSP pero sin adaptarlo.
Al aplicar la cadena de bsqueda en la base de IEEE se
obtienen 31 resultados. En esta base se filtra la bsqueda
eliminando los contenidos de tipo Books & eBooks.
Utilizando EBSCO se eliminan los filtros que buscan en las
bases CAB Abstracts 1990-Present, Dentistry & Oral Sciences
Source, MEDLINE y Ovid Journals y se obtienen 34
resultados.
Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
Para SCOPUS se agrega el filtro de excluir los artculos
pertenecientes a las areas Life Sciences y Health Sciences
obteniendo 20 resultados.
Por ltimo en la base de Springer se filtran slo artculos,
de la disciplina Computer Science y en ingls, obteniendo 20
resultados.
En A Bibliography of the Personal Software Process
(PSP) and the Team Software Process (TSP) se encuentra 1
artculo que adapta PSP utilizando mtodos formales. Este
artculo tambin fue encontrado con EBSCO e IEEE.
En los Simposios de TSP se encontr 1 artculo que no fue
encontrado por ninguna otra fuente as como una presentacin
(es decir, copias de diapostitivas). Ambos son del Simposio
2012, el artculo combina mtodos formales con PSP y la
presentacin incorpora al PSP tcnicas basadas en modelos.
Algunos artculos fueron publicados en ms de una
revista/conferencia y/o estn repetidos en ms de un buscador,
por lo que se tienen en cuenta una sola vez a estos artculos
resultando:
EBSCO 34 artculos
Springer 19 artculos
Scopus 18 artculos
IEEE 29 artculos
Simposio TSP 2013 1 artculos
Simposio TSP 2013 1 presentacin.
Finalmente al aplicar los criterios de inclusin/exclusin
para los resultados de cada buscador el resultado es:
Scopus 2 artculos
IEEE 1 artculo
Simposio TSP 2013 1 artculo
Simposio TSP 2013 1 presentacin
Tres de los cinco trabajos encontrados adaptan el PSP para
incorporar mtodos formales.
Babar y Potter proponen un nuevo proceso denominado B-
PSP que incorpora el mtodo formal B al proceso de desarrollo
personal [8]. Suzumori, Kaiya y Kaijiri proponen la
combinacin del mtodo formal VDM y PSP (VDM over PSP)
[9] al igual que la propuesta de Kusakabe, Omori and Araki
(VDM-PSP) [10]. Estos tres trabajos son presentados en las
siguientes secciones.
De los otros dos trabajos encontrados, uno modifica al PSP
para llevar adelante un proceso de desarrollo de software de a
pares (pair-programming) [11] y el otro propone una
adaptacin el PSP incorporando tcnicas basadas en modelos.
La propuesta de adaptacin del PSP para el desarrollo de
software de a pares, denominada Collaborative Software
Process (CSP) describe los cambios necesarios para distinguir
las tareas que debe seguir cada rol durante el desarrollo. Los
autores explican cmo los scripts, templates y formularios del
PSP son ajustados, describiendo en particular los cambios
necesarios para distinguir las tareas que debe el rol
desarrollador, el rol observador y los momentos en los que se
debe realizar el intercambio de roles. Otro cambio propuesto es
la utilizacin de dos checklists de diseo y dos checklists de
cdigo, uno para cada rol.
157
 La presentacin del Simposio TSP propone una adaptacin
al PSP incorporando tcnicas de integracin basadas en
modelos. El proceso propuesto modifica la fase de diseo para
desarrollar un modelo de diseo que describa la estructura
externa del sistema y el comportamiento y luego refina este
modelo para describir la estructura interna del sistema y el
comportamiento. La fase de revisin de diseo incorpora la
comprobacin del modelo mediante una herramienta de
anlisis esttico. Por ltimo las fases de cdigo y Unit Test
incorporan la generacin de cdigo parcial y la generacin de
los test en base a los modelos respectivamente.
Estas dos ltimas adaptaciones no sern explicadas en
mayor profundidad ya que no hacen uso de los mtodos
formales.
A. Propuesta B-PSP [8]
Los autores de la propuesta B-PSP combinan los enfoques
de mtodos formales y PSP con el objetivo de construir
software fiable y de alta calidad dentro de los plazos y
presupuesto esperado.
B-PSP incorpora al PSP las fases Specification, Auto
Prover, Animation y Auto Proof. Durante la fase de
Specification se especifican las B-machines utilizando el
lenguaje formal B. Posteriormente las fases de Auto Prover y
Animation se realizan con la ayuda del B toolkit, controlando la
sintaxis bsica y la dependencia entre machines, generando las
obligaciones de pruebas y brindando animacin. Durante la
fase de Auto Proof se realiza una demostracin interactiva de la
prueba mediante el B toolkit.
B-PSP propone adems la generacin de cdigo
automticamente, aunque no explica durante que fase se
realiza. La propuesta elimina las fases de design, design
review, code, code review, code compile y Unit Test, pero no
aclara si las actividades realizadas durante estas se realizan en
alguna de las nuevas fases.
La propuesta B-PSP mantiene la idea de PSP de fomentar a
los desarrolladores individuales a medir y evaluar, reconocer
las causas de la introduccin de defectos y evitarlas en el
futuro. Al igual que PSP se recogen los datos de tiempo y
esfuerzo; en esta propuesta se registran adems las lneas de
especificacin formal (LOS) y la cantidad de pruebas (# Proof).
B. Propuesta VDM over PSP [9]
La propuesta VDM over PSP propone combinar el mtodo
formal VDM y PSP con el objetivo de mejorar la gestin de la
calidad. Esta gestin considera dos aspectos: la prevencin de
defectos y la eliminacin de defectos. Para la prevencin de
defectos en VDM over PSP se utilizan checklist y guidelines de
revisin al igual que en PSP, mientras que la estrategia para
eliminar defectos es agregar actividades que permitan logar una
mayor calidad en el diseo. Estas actividades se proponen en
las nuevas fases VDM-SL syntax review, syntax check, type
check y validation. .
Planning
Specification
Auto prover
Animation
Auto Proof
Postmortem
Fig. 4. Fases de B-PSP
158 Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
VDM over PSP agrega y modifica varias fases al PSP,
especficamente modifica la fase de diseo para incorporar la
especificacin formal en el lenguaje VDM-SL. Luego de la
especificacin formal se realiza la revisin de diseo de PSP y
a posterior agrega las nuevas fases VDM-SL syntax review,
syntax check, type check y validation.
Durante VDM-SL syntax review el usuario chequea las
especificaciones en bsqueda de defectos de sintaxis. Las fases
syntax review, type check and validation son ejecutadas por el
Toolbox comprobando la sintaxis, el chequeo de tipos e
invariantes y precondiciones de forma dinmica. En esta ltima
fase no aplican tcnicas de verificacin formal ya que la
propuesta VDM-PSP es utilizada por estudiantes principiantes.
Los autores proponen introducir VDM over PSP en 4
niveles, de forma de introducir las tcnicas de VDM poco a
poco.
VDM over PSP0: corresponde al proceso base de PSP
a utilizar, es decir PSP 2.1
VDM over PSP1: se introducen las especificaciones
funcionales en VDM-SL. Adems de VDM over PSP0,
el usuario utiliza VDM-SL para especificar tipos de
datos, pre-condiciones, descripciones de funciones
implcitas e invariantes de cada tipo de datos.
VDM over PSP2: se introducen las especificaciones
lgicas en VDM-SL. Adems de VDM over PSP1, el
usuario especifica la especificacin interna de cada
funcin.
VDM over PSP3: se introduce la Toolbox para validar
las especificaciones escritas en VDM-SL. Este nivel
corresponde al proceso completo VDM over PSP.
Planning
Design
Design review
VDM-SL syntax
review
Syntax check
Type check
Validation
Code
Code review
Compile
Unit Test
Postmortem
Fig. 5. Fases de VDM over PSP
C. Propuesta VDM-PSP [10]
La propuesta VDM-PSP combina VDM y PSP basndose
en la importancia de producir software de alta calidad
siguiendo un proceso de desarrollo eficaz y eficiente. Los
autores creen que a pesar de que PSP proporciona cuatro
plantillas de diseo para aumentar la confianza en el diseo, el
uso de los mtodos formales con sus lenguajes de
especificacin formal y sus herramientas sern eficaces en la
reduccin de los defectos.
VDM-PSP incorpora el mtodo formal VDM que dispone
de varios lenguajes de especificacin formal y la VDM toolkit
que permite el chequeo de sintaxis, chequeo de tipos, la
por Contrato Verificado al Personal Software Process
utilizacin del intrprete y la generacin de obligaciones de La figura 7 muestra el agregado de estas dos nuevas fases.
pruebas. La propuesta planteada mantiene la mismas fases que
PSP, modificando la fase de diseo para incorporar la
especificacin formal utilizando alguno de los lenguajes que
provee VDM (por ejemplo, VDM ++) y la fase de revisin de
diseo para incorporar la herramienta VDM toolkit. No queda
clara en la propuesta en qu fase se realiza la generacin de las
obligaciones de la prueba.

Planning
Design
Design review
Code
Code review
Compile
Fig. 7. Incorporando las fases de Formal Specification y Proof
Unit Test
Postmortem El PSP propone revisiones personales como mecanismo
Fig. 6. Fases de VDM-PSP efectivo y rpido de remocin de defectos. Especficamente,
propone la revisin del diseo y la revisin del cdigo. Durante
La revisin sistemtica realizada permite conocer la estas revisiones el ingeniero revisa el trabajo realizado
existencia de las adaptaciones realizadas al PSP que incorporan siguiendo una check list en busca de defectos.
mtodos formales. Los trabajos encontrados presentan En PSPVDC la nueva fase de Formal Specification puede
diferentes formas de incorporar mtodos formales al PSP, incurrir a la inyeccin de defectos. Siguiendo la misma idea de
agregando nuevas fases, modificando fases o simplemente PSP de intentar remover la mayor cantidad de defectos de
introduciendo actividades al PSP (manteniendo sus fases). forma temprana se propone una fase de revisin de la
Sin embargo, ninguno de los trabajos encontrados especificacin formal. La fase Formal Specification Review se
incorpora el enfoque de Diseo por Contrato (DbC). Este realiza a continuacin de la especificacin formal y su objetivo
mtodo formal tiene sus caractersticas propias que difieren es revisar, con la ayuda de una check list, la especificacin
tanto de B como de VDM. Por esto, es necesaria una recientemente construida.
adaptacin particular al PSP de forma de poder usar el DbC en Luego de construida y revisada la especificacin formal se
conjunto con el PSP. propone una fase de compilacin de la especificacin formal.
Durante esta fase se compila la especificacin formal
V. EL PSPVDC utilizando herramientas permitiendo generar cdigo ejecutable
El PSPVDC es una adaptacin al PSP que incorpora el adems de remover defectos. En la figura 8 se presenta el
enfoque de diseo por contrato verificado. El objetivo de esta agregado de estas fases.
adaptacin es mejorar la calidad (defectos/kloc) del producto
de software desarrollado, en comparacin con el PSP.
A. Incorporando VDbC al PSP
Para incorporar VDbC se deben realizar las actividades de
Especificar Formalmente y Demostrar Formalmente la
correctitud del cdigo con respecto a dicha Especificacin.
Incorporar estas actividades al proceso puede realizarse de
diversas formas; proponiendo fases nuevas, proponiendo
nuevos pasos a fases ya existentes en PSP o combinando
ambas. En PSPVDC incorporamos dos nuevas fases para dar
soporte a este enfoque, la fase de Formal Specification y la fase
de Proof.
La fase de Formal Specification se propone luego de
finalizado el diseo y realizada la revisin del mismo. Durante
esta fase se especifican los mtodos de las clases anteriormente
diseados y revisados. Llevar a cabo la especificacin en una
Fig. 8. Incorporando las fases de Formal Specification review y compile
nueva fase permite conocer el esfuerzo (tiempo) dedicado
exclusivamente a especificar y conocer los defectos que se
inyectan y remueven al realizar esta actividad. B. Desde Diseo a Codificacin
La fase de Proof es propuesta luego de la compilacin de Un proceso de desarrollo de software consiste de un
cdigo. Durante esta fase se realiza la demostracin de la conjunto ordenado de pasos a seguir para lograr un producto de
correctitud del cdigo con respecto a la especificacin formal. software que resuelva un problema especfico. El PSP define a
Al igual que en la fase de Formal Specification el travs de las fases de Design, Design Review, Code, Code
proponer una nueva fase para la verificacin permite conocer Review, Compile, Unit Testing y Postmortem un proceso
los tiempos y defectos especficamente asociados a la disciplinado donde las salidas de una fase son la entrada directa
verificacin formal. a la fase inmediatamente posterior.
Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo 159
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
 En el PSP, una de las actividades a realizar durante la fase
de Design es el pseudo cdigo. El pseudo cdigo brinda una
descripcin en alto nivel del programa. En el contexto del
PSPVDC consideramos que la especificacin formal de los
mtodos de las clases debe realizarse antes que el pseudo
cdigo, por lo que eliminamos la actividad de pseudo cdigo
de la fase de diseo e incorporamos una fase nueva de pseudo
cdigo a posteriori de la revisin de la especificacin formal.
De esta forma mantenemos la idea de un proceso de
desarrollo de software bien definido donde la especificacin
formal realizada es tomada como entrada para realizar el
pseudo cdigo y luego ste pseudo cdigo es entrada para la
codificacin.
Luego de la nueva fase de pseudo codigo en PSPVDC se
propone una fase de revisin del pseudo cdigo manteniendo
los lineamientos de PSP en lo que refiere a la deteccin
temprana de defectos. El agregado de estas nuevas fases se
presenta en la figura 9.
Fig. 9. Incorporando las fases de Pseudo Code y Pseudo Code Review
C. Construccin de los Casos de Prueba
En el PSP la actividad de construccin de los casos de
prueba no est claramente definida en los scripts. Durante los
cursos del PSP algunos instructores optan por realizar la
construccin de los casos de prueba durante la fase de Design,
mientras que otros instruyen realizarlos durante la fase de Unit
Testing. Esto no permite conocer claramente el tiempo
dedicado a disear y ejecutar las pruebas, pudiendo estar
contenido como tiempo parcial de Diseo ms tiempo de Unit
Test o exclusivamente como tiempo de Unit Test. En el
PSPVDC nos interesa tener claramente diferenciado el tiempo
dedicado a la construccin de los casos de pruebas ya que
ayudar a conocer y mejorar el proceso. Por lo tanto, decidimos
agregar al PSPVDC una nueva fase dedicada a la construccin de
los casos de prueba. Esta fase se realiza inmediatamente
despus de la fase de Design Review. Los casos de prueba
buscan probar la especificacin informal del programa a
construir utilizando el diseo para poder construir las pruebas.
La figura 10 muestra el agregado de la fase de Test Case
Construct al PSPVDC.
Luego de analizar los resultados experimentales de aplicar
PSPVDC se podra mostrar (o no) que la inclusin de VDbC
reduce significativamente los defectos que llegan a UT, con lo
160 Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
cual podramos pensar (analizar costo-beneficio) en eliminar
las fases de Test Case Construct y Unit Test del PSPVDC.
Fig. 10. Incorporando la fase de Test Case Construct
D. Las Fases del PSPVDC
El PSPVDC incorpora nuevas fases y modifica otras como
fuimos describiendo en las secciones anteriores. La figura 11
ilustra todas las fases del PSPVDC; las cuales se describen a
continuacin.
Planning
Las actividades a realizar en esta fase son las mismas que
en PSP; obtener los requerimientos, estimar el tamao del
producto, estimar el esfuerzo y estimar los defectos.
Design
Durante el diseo se define la estructura del programa, as
como las clases, mtodos, interfaces, componentes e
interacciones entre ellos.
El PSP propone cuatro vistas y templates para mantener la
informacin de un buen diseo. Una de estas cuatro vistas es
la interna-esttica en la cual se define el pseudo cdigo del
programa. En PSPVDC el pseudo cdigo se pospone a una fase
posterior, por lo que se elimina de la fase de diseo la
utilizacin del Logic Template utilizado en PSP para el
pseudo cdigo.
Adems, durante el diseo en PSP se incluye el diseo de
los casos de prueba. En PSPVDC se propone realizar esta
actividad en una fase posterior dedicada especficamente a
generar los casos de prueba. El motivo de esta separacin es
nuestro inters por disponer del tiempo dedicado
exclusivamente a disear y el tiempo dedicado exclusivamente
a construir los casos de prueba.
Design Review
La revisin de diseo se mantiene incambiada con respecto
a PSP, siendo su objetivo detectar defectos inyectados de forma
temprana.
Test Case Construct
Se lleva a cabo luego de la revisin de diseo. Durante esta
fase se construye el conjunto de casos de prueba a utilizar para
probar el programa. Disponer de la informacin del tiempo
por Contrato Verificado al Personal Software Process
dedicado a construir los casos de prueba y a realizar las Postmortem
pruebas unitarias nos permitir evaluar el beneficio de Por ltimo, durante Postmortem el ingeniero analiza su
mantener estas fases en el proceso o eliminarlas. proceso, prestando atencin a los errores o dificultades en la
aplicacin del proceso para mejorar a futuro.
Formal Specification
Durante esta fase se especifican formalmente los contratos
(Design by Contract). Las pre- y post- condiciones de los
mtodos y el invariante de la clase son especificados en un
lenguaje formal.

Formal Specification Review

La revisin de la especificacin formal tiene el propsito de
detectar lo defectos inyectados durante la especificacin
formal. Se propone la utilizacin de una checklist para que el
ingeniero revise manualmente la especificacin formal en
busca de posibles defectos.

Formal Specification Compile

La compilacin consiste en el chequeo automtico
(utilizando una herramienta) de la sintaxis de la especificacin
formal.

Pseudo Code
Durante esta fase se escribe el pseudo cdigo de los mtodos
de las clases. Se decide realizar esta fase en este momento para
lograr un proceso definido en un orden natural de desarrollo de
software. Proponemos realizar el pseudo cdigo utilizando
como entrada a esta fase la salida de las fases anteriores (la
especificacin formal revisada y compilada correctamente).
Pseudo Code Review
En esta fase se revisa el pseudo cdigo anteriormente
producido en busca de defectos. Es una actividad manual,
donde el ingeniero es guiado por una checklist.
Code/Code Review/Compile
Estas tres fases se mantienen con respecto al PSP. Durante
las mismas se codifica el diseo construido utilizando un
lenguaje de programacin, luego se realiza una revisin manual
y por ltimo se compila el cdigo utilizando una herramienta.
Proof
La idea general de esta fase es complementar el cdigo con
una prueba formal. El objetivo es que la prueba provea
evidencia de la correccin del cdigo con respecto a las
especificaciones formales (Diseo por Contrato Verificado).
Esta prueba debe ser llevada a cabo con la ayuda de una
herramienta.
Unit Test
Durante esta fase se ejecutan los casos de prueba
construidos en busca de defectos con respecto a los
requerimientos.
En el PSPVDC optamos por mantener la fase de Unit Test
aunque se realice una demostracin formal. La demostracin
formal nos brinda evidencia de la correctitud del cdigo con
respecto a la especificacin formal, pero nada garantiza que la
especificacin formal no contenga defectos. Al ejecutar los
casos de prueba podemos detectar justamente si el
comportamiento del programa es correcto con respecto a los
requerimientos.
Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
Fig. 11. Fases de PSPVDC
PSPVDC es guiado por un conjunto de scripts que permiten
seguir el proceso de forma disciplinada y facilitan la
recoleccin de datos. En la figura 12 se presenta el Process
Script y en la figura 13 el Development Script de PSPVDC.
VI. CALIDAD EN PSPVDC
La calidad en PSP incluye:
estimar el nmero total de defectos inyectados y
removidos
estimar el nmero de defectos inyectados y removidos
por fase
estimar el tiempo requerido por fase
Se presenta en esta seccin las modificaciones al PSP para
planificar la calidad en PSPVDC.
Para estimar el nmero total de defectos inyectados, PSP
utiliza la estimacin del tamao del programa y datos
histricos a cerca de los defectos inyectados por KLOC. Para la
estimacin del nmero de defectos inyectados y removidos por
fase, PSP realiza una distribucin del total estimado basndose
en datos histricos.
En PSPVDC se deben de tener en cuenta las nuevas fases
para las estimaciones de tiempo requerido por fase y el nmero
de defectos. Inicialmente en PSPVDC no se disponen de datos
histricos, por lo que la estimacin inicial se realiza aplicando
juicio de expertos. Despus de realizar varios estudios, los
datos acumulados estarn disponibles para el empleo en las
estimaciones deseadas.
La calidad del producto es un aspecto esencial en el PSP.
Los desarrolladores deben eliminar los defectos, determinar las
causas de su inyeccin, y aprender a evitar que ocurran
nuevamente. El PSP propone revisiones como un mtodo
161
recomendado para la eliminacin de defectos, ya que es an
ms eficaz que las pruebas unitarias [12], [13], [14]. Para llevar
a cabo revisiones eficientes es necesario hacer mediciones [15].
PSP define varias formas de medir la calidad y control de
procesos, incluyendo las siguientes:
yield
defect removal efficiency
defect removal leverage
El yield para una fase es definido como el porcentaje de
defectos encontrados en la fase en relacin al nmero total de
defectos que llegan a la fase. Es una medida usualmente
utilizada para conocer la efectividad de las revisiones de diseo
y cdigo as como la compilacin y el testing.
En PSPVDC puede utilizarse para medir la efectividad de
las nuevas fases de formal specification review (FSR), pseudo
code review (PCR), formal specification, compile, y proof.
El yield del proceso es calculado como el porcentaje de
defectos inyectados y removidos antes de la primera
compilacin. En PSPVDC ajustamos el clculo teniendo en
cuenta las nuevas fases que preceden a la fase de compilacin.
En PSP, el Defect removal efficiency es un indicador del
numero de defectos removidos por hora en las fases de Design
Review, Code Review, Compile, y Test. En PSPVDC es
importante conocer el nmero de defectos removidos por hora
en las fases de Formal Specification Review, Pseudo Code
Review, Formal Specification Compile (FSC), y Proof (PRF).
El Defect removal efficiency para estos casos se define:
El indicador Defect removal leverage es el numero de
defectos removidos por hora en una fase con respecto a una
fase base. Normalmente la fase base es Unit Test (UT). En
PSPVDC proponemos incorporar los indicadores DRL
(FSR/UT), DRL (PCR/UT), DRL (FSC/UT), y DRL
(PRF/UT), que corresponde al nmero de defectos removidos
por hora en las fases de FSR, PCR, FSC, y PRF
respectivamente, con respecto a la fase UT.
El Cost of quality (COQ) es una medida de la calidad del
proceso. Los componentes del COQ son los costos por fallo,
evaluacin y prevencin. El costo por fallo (failure cost) es el
tiempo dedicado a reparar y el re-trabajo, que se corresponde
en PSP a las fases de Compile y Testing. El costo de
evaluacin (appraisal cost) es el tiempo empleado en
inspeccionar, que en PSP se corresponde con las fases de
Design Review y Code Review. Por ltimo, el costo de
prevencin (prevention cost) es el tiempo dedicado a la
identificacin y resolucin de las causas de los defectos.
Siguiendo la misma idea, en el PSPVDC el costo por fallo
corresponde al tiempo dedicado a las fases de Code, Compile,
162 Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
Formal Specification Compile, Proof, y Testing. El costo de
evaluacin, por otro lado, es el tiempo empleado en las fases de
Design Review, Code Review, Formal Specification Review y
Pseudo Code Review.
El indicador Appraisal Cost of Quality (% Appraisal
COQ) es definido en PSP como el porcentaje del tiempo
empleado en las fases de Design Review y Code Review
respecto al tiempo total de desarrollo. Altos valores de este
indicador estn asociados a una baja cantidad de defectos en
testing y por lo tanto una alta calidad del producto.
En PSPVDC, modificamos el indicador incorporando el
tiempo empleado en la fase de Formal Specification Review y
Pseudo Code Review. La forma de calcularlo es:
Design Review Time +
Code Review Time +
FSR Time +
PCR Time
% Appraisal COQ = 100
Total Developmen t Time
El indicador Percent Failure COQ (% Failure COQ) es
definido en PSP como el porcentaje de tiempo empleado en las
fases de Compile y Testing respecto al tiempo total de
desarrollo.
En PSPVDC modificamos el indicador con el propsito de
incorporar el tiempo dedicado en las fases de Formal
Specification Compile (FSC) y el tiempo empleado en la fase
de Proof. El nuevo clculo es:
Code Compile Time +
Test Time +
FS C Time +
Proof Time
% Failure COQ = 100
Total Development Time
Una medida til del COQ es la tasa entre los costos de
evaluacin y fallo (A/FR). Dicho indicador es modificado de
forma implcita en PSP VDC debido a los cambios A y FR.
En PSP, un valor de A/FR superior a 2 es considerado de
alta performance. Este valor de benchmark deber ser ajustado
en PSPVDC luego de realizar estudios empricos debido al
posible impacto de las nuevas fases.
VII. CONCLUSIONES Y TRABAJOS A FUTURO
El desarrollo de software es una actividad creativa e
intelectual realizada por seres humanos. Es comn que durante
un proyecto el equipo de desarrollo cometa errores. Esto se
debe tanto a la complejidad actual del software como a la
propia naturaleza humana. Normalmente estos errores terminan
en defectos en el producto de software y cuando el software se
est ejecutando estos pueden causar fallos.
La bsqueda de formas de desarrollar software con bajo
nmero de defectos ha dado lugar al desarrollo de un variado
nmero de procesos y mtodos. El cometido de dichos
procesos es construir software de calidad, en el plazo
estipulado y dentro de los costos previstos.
En este artculo presentamos un nuevo proceso de
desarrollo de software que combina los enfoques del proceso
de desarrollo personal (PSP) y la tcnica de diseo por contrato
verificado (VDbC).
por Contrato Verificado al Personal Software Process
 Purpose To guide the development of module-level programs
Entry Criteria - Problem description
- PSP Project Plan Summary form
- Size Estimating template
- Historical size and time data (estimated and actual)
- Time and Defect Recording logs
- Defect Type, Coding, and Size Counting standards
- Stopwatch (optional)

Step Activities Description

1 Planning
2 Development
3 Postmortem
- Produce or obtain a requirements statement.
- Use the PROBE method to estimate the added and
modified size and the size prediction interval of this
program.
- Complete the Size Estimating template.
- Use the PROBE method to estimate the required
development time and the time prediction interval.
- Complete a Task Planning template.
- Complete a Schedule Planning template.
- Enter the plan data in the Project Plan Summary form.
- Complete the Time Recording log.
- Design the program.
- Document the design in the design templates.
- Review the design and fix and log all defects found.
- Design Test cases.
- Formally specify the methods of every class introduced at
design.
- Review the formal specification and fix and log all
defects found.
- Compile the formal specification and fix and log all
defects found.
- Write down the pseudo code, using the Logic Template.
- Review the pseudo code and fix and log all defects found.
- Implement the design.
- Review the code and fix and log all defects found.
- Compile the program and fix and log all defects found.
- Construct a formal proof of correctness of the code with
respect to its formal specification.
- Test the program and fix and log all defects found.
- Complete the Time Recording log.
Complete the Project Plan Summary form with actual time,
defect, and size data.

Exit Criteria - A thoroughly tested program

- Completed Project Plan Summary form with estimated
and actual data
- Completed Size Estimating and Task and Schedule
Planning templates
- Completed Design templates and Formal Specification
Templates
- Completed Design Review, Formal Specification Review,
Pseudo Code Review, and Code Review checklists
- Completed Test Report template

- Completed PIP forms

- Completed Time and Defect Recording logs
Fig. 12. Process Script

Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo 163
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
 Purpose To guide the development of small programs
Entry Criteria - Requirements statement
- Project Plan Summary form with estimated program size
and development time
- For projects lasting several days or more, completed Task
Planning and Schedule Planning templates
- Time and Defect Recording logs
- Defect Type standard and Coding standard

Step Activities Description

1 Design
2 Design
Review
3 Test Case
Construct
4 Formal
Specification
5 Formal
Specification
Review
6 Formal
Specification
Compile
7 Pseudo Code
8 Pseudo Code
Review
9 Code
- Review the requirements and produce an external
specification to meet them.
- Complete Functional and Operational Specification
templates to record this specification.
- Produce a design to meet this specification.
- Record the design in Functional, Operational, and State
templates.
- Record in the Defect Recording log any requirements
defects found.
- Record time in the Time Recording log.
- Follow the Design Review script and checklist and review
the design.
- Fix all defects found.
- Record defects in the Defect Recording log.
- Record time in the Time Recording log.
- Design test cases and record them in the TestReport.
- Record time in the Time Recording log.
- Implement the design following the Formal Specification
standard.
- Record in the Defect Recording log any requirements or
design defects found.
- Record time in the Time Recording log.
- Follow the Formal Specification Review script and
checklist and review the specification.
- Fix all defects found.
- Record defects in the Defect Recording log.
- Record time in the Time Recording log.
- Compile the formal specification until there are no
compile errors.
- Record in the Defect Recording log any defects found.
- Record time in the Time Recording log.
- Produce a Pseudo Code to meet the design.
- Record the design Logic Specification templates.
- Record in the Defect Recording log any defects found.
- Record time in the Time Recording log.
- Follow the Pseudo Code Review script and checklist and
review the specification.
- Fix all defects found.
- Record defects in the Defect Recording log.
- Record time in the Time Recording log.
- Implement the design following the Coding standard.
- Record in the Defect Recording log any requirements or
design defects found.
- Record time in the Time Recording log.

10 Code - Follow the Code Review script and checklist and review
Review the code.
- Fix all defects found.
- Record defects in the Defect Recording log.
164 Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
 11 Compile - Compile the program until there are no compile errors.
- Fix all defects found.
- Record defects in the Defect Recording log.
- Record time in the Time Recording log.
12 Proof - Construct a formal proof of correctness of the program
with respect to the formal specification.
- Fix all defects found.
- Record defects in the Defect Recording log.
- Record time in the Time Recording log.
13 Test - Test until all tests run without error.
- Fix all defects found.
- Record defects in the Defect Recording log.
- Record time in the Time Recording log.
- Complete a Test Report template on the tests conducted
and the results obtained.

Exit Criteria - A thoroughly tested program that conforms to the Coding

standard
- A formal specification conforming to the Formal
Specification Standard
- Completed Design and Formal Specification templates
- Completed Design Review, Pseudo Code Review, Formal
Specification Review and Code Review checklists
- Completed Test Report template
- Completed Time and Defect Recording logs
Fig. 13. Development Script

En el PSPVDC se proponen fases nuevas para dar soporte al
VDbC. El objetivo es que el uso de este nuevo proceso logre
productos de mejor calidad que los desarrollados con el PSP.
Adems, se presenta una revisin sistemtica de la literatura
que resume la informacin existente sobre adaptaciones
realizadas al PSP y particularmente aquellas que incorporan
mtodos formales.
Conocer las diferentes adaptaciones realizadas al PSP que
incorporar mtodos formales brinda conocimiento acerca de las
formas posibles de combinar el enfoque de PSP y mtodos
formales.
Nuestro trabajo a futuro consiste en realizar experimentos
controlados que nos permitan comparar la calidad y
productividad del PSP y del PSPVDC. Se deber realizar una
buena planificacin teniendo en cuenta el armado de los cursos
de PSP, PSPVDC, mtodos formales y de tcnicas de verificacin
de programas, adems se deber capacitar a los sujetos en la
aplicacin de los procesos y herramientas de soporte. El anlisis
de resultados de los experimentos nos permitir conocer cmo
funciona el PSPVDC en la prctica y as poder mejorarlo.
REFERENCES
[1] Ian Sommerville. Ingeniera del Software 7a edicin. University
of Lancaster. ISBN 8478290745, 2005
[2] Watts S. Humphrey. PSP: A Self-Improvement Process for
Software Engineers. Addison-Wesley Professional; March. 2005.
[3] Watts S. Humphrey. Tsp (sm) Coach Dvlp Teams. Pearson
Education, 2006
[4] Meyer, Bertrand. Applying Design by Contract, IEEE
Computer 25, 10 (October 1992): 40-51.
[5] Hoare, C.A.R. An Axiomatic Basis for Computer
Programming, Communications of the ACM 12, 10 (1969):
576-580.
[6] Gary T. Leavens and Yoonsik Cheon, Design by Contract with
JML, 2006
[7] Kitchenham, Guidelines for performing Systematic Literature
Reviews in Software Engineering, Version 2.3, EBSE Technical
Report EBSE-2007-01
[8] Abdul Babar, John Potter. Adapting the Personal Software
Process (PSP) to Formal Methods. Australian Software
Engineering Conference (ASWEC'05), 2005, pp.192-201.
[9] Hisayuki Suzumori, Haruhiko Kaiya, Kenji Kaijiri, VDM over
PSP: A Pilot Course for VDM Beginners to Confirm its
Suitability for Their Development, 27th Annual Inter-national
Computer Software and Applications Conference, 2003
[10] Kusakabe, S., Omori, Y. and Araki K, A Combination of a
Formal Method and PSP for Improving Software Process: An
Initial Report. TSP Symposium 2012, St. Petersburg, FL.
[11] Williams, L. Integrating pair programming into a software
development process. Software Engineering Education
Conference, Proceedings Jan 1, 2001, p27-36, 10p
[12] Hayes, William; & Over, James. Personal Software Process
(PSP): An Empirical Study of the Impact of PSP on Individual
Engineers (CMU/SEI-97-TR-001). Soft-ware Engineering
Institute, Carnegie Mellon University, 1997.
http://www.sei.cmu.edu/library/abstracts/reports/97tr001.cfm
[13] Vallespir, Diego and Nichols, William. Analysis of Design
Defects Injection and Removal in PSP, 19-25. Proceedings of
the TSP Symposium 2011: A Dedication to Excellence. Atlanta,
GA, Sept. 2011.
[14] Vallespir, Diego and Nichols, William. An Analysis of Code
Defect Injection and Removal in PSP, 3-20. TSP Symposium
2012 Proceedings (CMU/SEI-2012-SR- 48 015). Software
Engineering Institute, Carnegie Mellon University, 2012.
http://www.sei.cmu.edu/library/abstracts/reports/12sr0 15. cfm
[15] Gilb, Tom and Graham, Dorothy. Software Inspection. Addison-
Wesley, 1994 (ISBN 978-0201-631814).

Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo 165
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
 Silvana Moreno. Es Magister en Informtica por la
Universidad de la Repblica, Facultad de Ingeniera. Es
Profesora Asistente del rea de Ingeniera de Software en
la Universidad de la Repblica. Sus intereses en
investigacin son los procesos de desarrollo de software y
su combinacin con los mtodos formales y cmo se
pueden combinar estos enfoques para aumentar la calidad
de los productos.
lvaro Tasistro. Es Doctor en Ciencia de la
Computacin por la Universidad de Gotemburgo.
Actualmente dirige la Ctedra de Teora de la
Computacin y el grupo de investigacin en Computacin
Terica de la Escuela de Ingeniera de la Universidad
ORT Uruguay. Sus reas de inters son la Lgica y la
Teora de la Programacin.
Diego Vallespir. Es Profesor Adjunto de la Facultad de
Ingeniera de la Universidad de la Repblica (UdelaR),
Uruguay, es Director del Centro de Posgrados y
Actualizacin Profesional en Informtica de la UdelaR, es
Director del Grupo de Investigacin en Ingeniera de
Software de la UdelaR. Es Ingeniero en Computacin,
Magister en Informtica y Doctor en Informtica por la
Facultad de Ingeniera, UdelaR. Tiene varios artculos publicados en
conferencias internacionales. Sus reas de inters en investigacin son
ingeniera de software emprica, procesos de desarrollo de software y pruebas
de software. Su hobby es divertirse.

166 Silvana Moreno, Alvaro Tasistro, Diego Vallespir. 2013. PSPVDC: Una propuesta que incorpora el Diseo
por Contrato Verificado al Personal Software Process
Revista Latinoamericana de Ingeniera de Software, 1(5): 153-166, ISSN 2314-2642
 Aseguramiento de la Calidad en la Construccin de
Sistemas Basados en el Conocimiento: Un Enfoque
Prctico

Eduardo Diez
Laboratorio de Investigacin y Desarrollo en Aseguramiento de Calidad de Software
Grupo Investigacin en Sistemas de Informacin
Departamento Desarrollo Productivo y Tecnolgico. Universidad Nacional de Lans.
Remedios de Escalada, Buenos Aires, Argentina.
ediez@unla.edu.ar

ResumenLa funcin de aseguramiento de la calidad del
software (SQA) se debe basar en un planificado y sistemtico
diseo de acciones y mtodos, requeridos para garantizar la
calidad del mismo. En el presente trabajo, se presenta un diseo
de acciones y mtodos que constituyen un enfoque prctico para
el desempeo de la funcin de SQA en una organizacin,
adaptado especialmente a la metodologa IDEAL para el
desarrollo de sistemas basados en el conocimiento. Este enfoque
no pretende ser exclusivo y en ningn caso limita o inhibe la
aplicacin de otras acciones, mtodos o modelos, sino que podr
ser su complemento, adaptndolo convenientemente. El enfoque
o modelo de aseguramiento de la calidad del software que tiene
las siguientes caractersticas: el modelo de aseguramiento de
calidad de software sugerido es una interfaz a una metodologa,
ideal en este caso, de desarrollo de software, el modelo que aqu
se presenta no es una metodologa en s misma, sino que debe
acoplarse a una metodologa de desarrollo para poder
implementarse, esta interfaz est compuesta por mdulos
independientes, donde cada uno de ellos se asocia a ciertos
procesos de la metodologa ideal.
Palabras ClavesAseguramiento de la calidad del software,
sistemas basados en el conocimiento, metodologa ideal.
I. INTRODUCCION
La calidad es una cualidad esencial de cualquier producto,
generado por una organizacin, que va a ser usado por otros.
Antes del siglo veinte, las actividades relacionadas con el
aseguramiento de la calidad era responsabilidad nica de la
persona que construa el producto. La primera funcin de
control y de aseguramiento de la calidad formal fue introducida
por los laboratorios Bell en 1916 y se extendi rpidamente por
todo el mundo de las manufacturas. Hoy en da, cada empresa
tiene un mecanismo que asegura la calidad de sus productos, de
hecho, durante la pasada dcada se ha usado ampliamente
como tctica de mercado, la declaracin explcita de mensajes
que ponan de manifiesto la calidad ofrecida por las empresas.
La evolucin del aseguramiento de la calidad en el
desarrollo de software ha sido paralela a la evolucin de la
calidad en la fabricacin de hardware. Durante los primeros
aos de la informtica (los aos 50 y 60), la calidad era
responsabilidad nicamente del programador. Durante los aos
70 se introdujeron estndares de aseguramiento de la calidad
para el software en los contratos militares de desarrollo de
software y se extendieron rpidamente en los desarrollos de
software del mundo comercial.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
La funcin de aseguramiento de la calidad del software
(SQA) se debe basar en un planificado y sistemtico diseo de
acciones y mtodos, requeridos para garantizar la calidad del
mismo. El alcance de la responsabilidad del aseguramiento de
la calidad, en el desarrollo de software, abarca a muchos
constituyentes de una organizacin, tales como ingenieros de
software, lderes de proyecto, clientes, comerciales y personas
que trabajan dentro del equipo de SQA (una conformacin del
mismo se presentar en captulos sucesivos).
El equipo de SQA debe analizar el software desde diversos
puntos de vista, respondiendo a algunas de estas preguntas:
Satisface el software, de forma adecuada los principales
factores de calidad?
Se ha realizado el desarrollo del software de acuerdo con
estndares preestablecidos?
Se han aplicado las tcnicas y mtodos apropiados para el
desarrollo del software?
Para responder a stas y otras cuestiones, en el presente
trabajo, se presenta un diseo de acciones y mtodos que
constituyen un enfoque prctico para el desempeo de la
funcin de SQA en una organizacin, adaptado especialmente
a la metodologa IDEAL para el desarrollo de sistemas basados
en el conocimiento. Este enfoque no pretende ser exclusivo y
en ningn caso limita o inhibe la aplicacin de otras acciones,
mtodos o modelos, sino que podr ser su complemento,
adaptndolo convenientemente.
En la seccin II se establecen los Conceptos Bsicos,
describiendo brevemente los conceptos de calidad, control y
aseguramiento de la misma y presentando el alcance de la
funcin de SQA en una organizacin. En la seccin III se
esboza el Modelo General, es decir, el diseo de acciones y
mtodos que constituyen un enfoque prctico para el
desempeo de la funcin de SQA en una organizacin.
Tambin de presenta el modelo de mejora continua del mismo.
En la seccin IV se describen los Mdulos del Modelo, se
presentan para cada uno de ellos las acciones a desempear, su
objetivo, sus entradas, salidas, lista de verificacin, mtricas y
participantes involucrados. En la seccin V se describe las
principales Tcnicas y Herramientas, a utilizar en los mdulos
del modelo descrito. En la seccin VI se describe el Nivel de
Servicio Esperado, a travs de un acuerdo de nivel de servicio
recomendado. En la seccin VII se detalla el Equipo de SQA
sugerido, indicando su estructura y responsabilidades. En la
seccin VIII se establecen las Conclusiones del presente
167
trabajo, sealando los beneficios y problemas esperados en la
aplicacin de la funcin de SQA en una organizacin. Tambin
se establecen las bases para un anlisis costo-beneficio. Por
ltimo se detalla la Bibliografa utilizada para la confeccin del
presente trabajo, ya sea referenciada o consultada.
II. CONCEPTOS BSICOS
En la presente seccin se establecen los Conceptos Bsicos,
describiendo brevemente los conceptos de calidad, control y
aseguramiento de la misma y presentando el alcance de la
funcin de SQA en una organizacin.
A. Paradigma de la calidad
El paradigma de la calidad es aplicable a todas las
actividades que se llevan a cabo en una organizacin. Se puede
definir en trminos generales a la calidad como:
La calidad es la suma de todos aquellos aspectos o
caractersticas de un producto o servicio, que influyen en su
capacidad para satisfacer las necesidades de los usuarios.
Por otro lado, con respecto a la satisfaccin del usuario, se
puede decir que:
La satisfaccin del usuario est determinada por la
diferencia entre la calidad percibida y la calidad esperada,
cuando ste hace uso de un producto o servicio.
Los principales elementos del paradigma de la calidad son
los siguientes:
La naturaleza de la calidad: Orientacin a los aspectos o
caractersticas de un producto o servicio que influyan en su
capacidad para satisfacer necesidades dadas, ms que a la
adecuacin a estndares o a especificaciones preestablecidas.
La perspectiva del proceso: Focalizacin en el proceso ms
que en el producto.
Orientado a datos: Basado en la recoleccin, anlisis y
comparacin de datos.
Focalizacin en el cliente o usuario: La obtencin de la
satisfaccin del cliente o usuario es el objetivo final de todo
proceso.
Eliminacin de defectos: Priorizacin de tcnicas de
prevencin de defectos sobre tcnicas de deteccin y
correccin.
Gestin para la calidad: La adopcin del paradigma requiere
del compromiso de la alta direccin.
En primer trmino, se debe diferenciar entre la calidad del
producto y la calidad del proceso que lo genera.
Las primeras aproximaciones a la calidad estaban basadas
solamente en el control de la calidad del producto terminado,
es decir en actividades que slo desataban acciones correctivas
para eliminar los defectos del producto. A estas actividades se
las suele catalogar como correctivas, tardas y relacionadas con
el producto.
Con el tiempo y tal cual se establece en uno de los
principios del paradigma de la calidad, las aproximaciones de
calidad se fueron trasladando al aseguramiento de la misma
sobre el proceso que genera el producto, es decir en actividades
preventivas, antes que el producto est terminado, y que
desatan acciones para evitar que el producto terminado tenga
defectos. A estas actividades se las suele catalogar como
preventivas, tempranas y relacionadas con el proceso.
Ahora bien, la realidad muestra que toda aproximacin
eficaz a la calidad, contiene una combinacin de actividades de
168 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
aseguramiento de la calidad y de actividades de control de la
misma y que estas se complementan fcilmente.
B. Calidad del Software
Particularmente, en el caso del software, existen muchas
definiciones distintas en la bibliografa, sin embargo, en lo que
a este trabajo respecta, tomaremos la definicin de R. Pressman
[1]:
La calidad del software se define como la concordancia con
los requisitos funcionales y de rendimiento explcitamente
establecidos, con los estndares y procesos de desarrollo
explcitamente documentados y con las caractersticas
implcitas que se espera de todo software desarrollado
profesionalmente.
No hay duda de que la anterior definicin puede ser
modificada o ampliada. De hecho, no tendra fin una discusin
sobre una definicin definitiva de la calidad del software. Para
los propsitos de este enfoque, la anterior definicin sirve para
hacer hincapi en tres puntos importantes:
1) Los requisitos del software son la base de las medidas de la
calidad. La falta de concordancia con los requisitos es una
falta de calidad.
2) Los estndares especificados definen un conjunto de
criterios de desarrollo que guan la forma en que se aplica
la ingeniera del software o del conocimiento. En caso de
no seguirse esos criterios, casi siempre habr falta de
calidad.
3) Existe un conjunto de requisitos implcitos que a menudo
no se mencionan (por ejemplo la necesidad de una interfaz
intuitiva). Si el software se ajusta a sus requisitos explcitos
pero falla en alcanzar los requisitos implcitos, la calidad
del software se debilita.
Queda claro a partir de la definicin de calidad del
software, que sta es siempre relativa a los requisitos o
necesidades que se desea satisfacer. Por eso la evaluacin de la
calidad del software siempre va a implicar la comparacin
entre los requisitos y el producto generado.
B.1. Puntos de vista de la calidad del software
En la ingeniera del software o del conocimiento, la visin
de la calidad no es nica, dependiendo del punto de vista desde
el cual se la analice, ver figura 1.
Punto de vista del
usuario
Punto de vista del Punto de vista del
ingeniero gerente de proyecto
Fig. 1. Puntos de vista de la calidad del software
Dependiendo del punto de vista, se priorizarn distintos
factores del software:
Punto de vista del usuario: El punto de vista del usuario, con
respecto a la calidad, estar basado en los factores externos
del producto, tales como funcionalidad y facilidad de
operacin.
 Punto de vista del ingeniero de software: El punto de vista
del ingeniero del software, con respecto a la calidad, estar
basado en los factores internos del producto, tales como
modularidad y reusabilidad.
Punto de vista del gerente del proyecto: El punto de vista del
gerente del proyecto, con respecto a la calidad, estar basado
en los factores relacionados con la gestin del proyecto, tales
como costos y cronogramas acorde a lo planificado.
B.2. Factores que determinan la calidad del software
Existen muchos factores que afectan a la calidad del
software y se pueden clasificar de distintas formas (uno de
ellos es el punto de vista del apartado anterior). En este trabajo
se presentarn slo a modo descriptivo, algunos factores de
calidad que se han propuesto.
McCall y sus colegas [2] han propuesto los siguientes:
Correccin. El grado en que un programa satisface sus
especificaciones y consigue los objetivos de la misin
encomendada por el cliente. Responde a la pregunta: Hace
lo que quiero?
Fiabilidad. El grado en que se puede esperar que un programa
lleve a cabo sus funciones esperadas con la precisin
requerida (Hay que decir que se han propuesto otras
definiciones de fiabilidad ms completas). Responde a la
pregunta: Lo hace en forma fiable todo el tiempo?
Eficiencia. La cantidad de recursos de computadora y de
cdigo requeridos por un programa para llevar a cabo sus
funciones. Responde a la pregunta: Se ejecutar en mi
hardware lo mejor que se pueda?
Integridad. El grado en que puede controlarse el acceso al
software o a los datos, por personal no autorizado. Responde
a la pregunta: Es seguro?
Facilidad de uso. El esfuerzo requerido para aprender un
programa, trabajar con l, preparar su entrada e interpretar su
salida. Responde a la pregunta: Est diseado para ser
usado?
Facilidad de mantenimiento. El esfuerzo requerido para
localizar y arreglar un error en un programa (Se trata de una
definicin muy limitada). Responde a la pregunta: Permite
ser corregirlo con relativa facilidad?
Flexibilidad. El esfuerzo requerido para modificar un
programa operativo. Responde a la pregunta: Permite ser
cambiado con relativa facilidad?
Facilidad de prueba. El esfuerzo requerido para probar un
programa de forma que se asegure que realiza su funcin
requerida. Responde a la pregunta: Permite ser probado con
relativa facilidad?
Portabilidad. El esfuerzo requerido para transferir el
programa desde un hardware y/o un entorno de sistemas de
software a otro. Responde a la pregunta: Podr usarlo en
otra computadora?
Reusabilidad. El grado en que un programa (o partes de un
programa) se puede reusar en otras aplicaciones. Esto va
relacionado con el empaquetamiento y el alcance de las
funciones que realiza el programa. Responde a la pregunta:
Podr reusar alguna parte del software?
Facilidad de nter-operacin. El esfuerzo requerido para
acoplar un sistema a otro. Responde a la pregunta: Podr
hacerlo interactuar con otros sistemas?
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Es difcil, y en algunos casos imposible, desarrollar
medidas directas de los anteriores factores de calidad. Por
tanto, cada factor se descompone en atributos o criterios, ms
fcilmente medibles. Cabe aclarar que cada uno de estos
atributos puede corresponder a ms de un factor de calidad.
Facilidad de auditora. La facilidad con que se puede
comprobar la conformidad con los estndares.
Exactitud. La precisin de los clculos y del control.
Normalizacin de las comunicaciones. El grado en que se
usan el ancho de banda, los protocolos y las interfaces
estndar.
Completitud. El grado en que se ha conseguido la total
implementacin de las funciones requeridas.
Concisin. Lo compacto que es el programa en trminos de
lneas de cdigo.
Consistencia. El uso de un diseo uniforme y de tcnicas de
documentacin a lo largo del proyecto de desarrollo del
software.
Estandarizacin en los datos. El uso de estructuras de datos y
de tipos estndar a lo largo de todo el programa.
Tolerancia de errores. El dao que se produce cuando el
programa encuentra un error.
Eficiencia en la ejecucin. El rendimiento en tiempo de
ejecucin de un programa.
Facilidad de expansin. El grado en que se puede ampliar el
diseo arquitectnico, de datos o procedimental.
Generalidad. La amplitud de aplicacin potencial de los
componentes del programa.
Independencia del hardware. El grado en que el software es
independiente del hardware sobre el que opera.
Instrumentacin. El grado en que el programa muestra su
propio funcionamiento e identifica errores que aparecen.
Modularidad. La independencia funcional de los
componentes del programa.
Facilidad de operacin. La facilidad de operacin de un
programa.
Seguridad. La disponibilidad de mecanismos que controlen o
protejan los programas o los datos.
Autodocumentacin. El grado en que el cdigo fuente
proporciona documentacin significativa.
Simplicidad. El grado en que un programa puede ser
entendido sin dificultad.
Independencia del sistema de software. El grado en que el
programa es independiente de caractersticas no estndar del
lenguaje de programacin, de las caractersticas del sistema
operativo y de otras restricciones del entorno.
Facilidad de traza. La posibilidad de seguir la pista a la
representacin del diseo o de los componentes reales del
programa hacia atrs, hacia los requisitos.
Formacin. El grado en que el software ayuda para permitir
que nuevos usuarios apliquen el sistema.
Otra lista de factores de calidad es la desarrollada por
Grady y sus colegas [3]. Los factores y sus atributos
correspondientes son los siguientes:
La funcionalidad se obtiene mediante la evaluacin del
conjunto de caractersticas y de posibilidades del programa,
la generalidad de las funciones que se entregan y la seguridad
de todo el sistema.
169
 La facilidad de uso se calcula considerando los factores
humanos, la esttica global, la consistencia y la
documentacin.
La fiabilidad se calcula midiendo la frecuencia de fallos y su
importancia, la eficacia de los resultados de salida, el tiempo
medio entre fallos (MTBF), la posibilidad de recuperarse a
los fallos y la previsibilidad del programa.
El rendimiento se mide mediante la evaluacin de la
velocidad de proceso, el tiempo de respuesta, el consumo de
recursos, el rendimiento total de procesamiento y la
eficiencia.
La capacidad de soporte combina la posibilidad de ampliar el
programa (extensibilidad), la adaptabilidad y la utilidad
(estos tres atributos representan un trmino ms comn
facilidad de mantenimiento), adems de la facilidad de
prueba, la compatibilidad, la posibilidad de configuracin
(posibilidad de organizar y controlar elementos de la
configuracin & software)], la facilidad con la que se puede
instalar un sistema y la facilidad con la que se pueden
localizar los problemas.
Tanto el modelo de McCall como el de Grady, presentan
adems frmulas, matrices, pesos ponderados que permiten
cuantificar cada uno de los factores presentados. Ms all de
eso, los siguientes puntos deben quedar claros.
1) Los modelos aqu presentados son slo una muestra de los
disponibles, hay varios ms y se actualizan frecuentemente.
2) Al planificar la calidad de un producto de software se debe
seleccionar cuales de los factores de calidad van a ser
considerados requisitos, a su vez. Para realizar esta
seleccin, se debe tener en cuenta lo siguiente:
Las caractersticas particulares de la aplicacin a
desarrollar o de su entorno. As por ejemplo si la
aplicacin se desarrolla para un entorno en el que el
hardware evoluciona rpidamente, el factor portabilidad
es importante; si se espera que las especificaciones del
sistema cambien frecuentemente, la flexibilidad ser
esencial.
El costo de los factores de calidad frente al beneficio que
proporcionan. Es decir realizar un anlisis costo-
beneficio.
Las interrelaciones entre factores: Algunos factores
pueden ser conflictivos entre s. La eficiencia, por
ejemplo, est en conflicto con otros factores de calidad.
3) Es necesario medir cada uno de los factores y atributos
seleccionados. Algunos pueden ser medidos directamente y
otros slo pueden ser medidos indirectamente. En
cualquiera de los dos casos la cuantificacin es obligatoria.
Respondiendo a otro de los principio del paradigma de la
calidad (orientacin a datos), las comparaciones se deben
basar sobre datos y mediciones concretas y objetivas, no
sobre opiniones o subjetividades.
C. Alcance de la funcin de SQA
La calidad del software no es algo en lo que se empieza a
pensar una vez que se ha generado el cdigo. Segn R
Pressman [1] el aseguramiento de la calidad del software
(SQA) es una actividad de proteccin que se aplica a lo largo
de todo el proceso de ingeniera software y engloba:
1) Un enfoque de gestin de la calidad.
2) Tecnologa de ingeniera del software o del conocimiento
efectiva (mtodos y herramientas).
170 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
3) Revisiones tcnicas formales que se aplican durante cada
paso de la ingeniera del software o del conocimiento.
4) Una estrategia de prueba en mltiples niveles.
5) El control de la documentacin del software y de los
cambios realizados.
6) Un procedimiento que asegure un ajuste a los estndares de
desarrollo del software (cuando sea posible).
7) Mecanismos de medicin y de informacin.
Las anteriores involucran tanto a los ingenieros de software
como al equipo de SQA. Los ingenieros de software deben
aplicar mtodos tcnicos y mediciones slidas, conducir
revisiones tcnicas formales y ejecutar pruebas de software
bien planificadas. Por otro lado, de acuerdo al Software
Engineering Institute (SEI) [4], el equipo de SQA tiene como
propsito proveer a la gerencia la visibilidad apropiada del
proceso que est siendo usado y de los productos siendo
desarrollados. El propsito involucra:
Revisar y auditar los productos de software y actividades
para asegurar que obedecen a los procedimientos y estndares
aplicables.
Proveer al gerente del proyecto de software y a otras
gerencias, segn corresponda, los resultados de las revisiones
y auditorias. Las discrepancias son primero planteadas dentro
del proyecto de software y resueltas all, si es posible. Si no
se pueden resolver, se debe escalar a niveles superiores para
su resolucin.
Las actividades del equipo de SQA, acorde al SEI [4],
comprenden:
Preparar un plan de SQA para el proyecto: El plan es
desarrollado durante la planificacin del proyecto y es revisado
por todas las partes interesadas. Las actividades de
aseguramiento de la calidad a desempear por el equipo de
ingenieros de software y el equipo de SQA son regidas por este
plan. El plan identifica:
Evaluaciones a realizar.
Auditoras y revisiones a realizar.
Estndares aplicables al proyecto.
Procedimientos para reporte y seguimiento de errores.
Documentos a ser producidos por el equipo de SQA.
Retro-alimentacin a proveer al equipo del proyecto de
software.
Participar en el desarrollo de la descripcin del proceso de
software del proyecto: El equipo de software selecciona un
proceso de software para el proyecto, el equipo de SQA
revisa la descripcin del proceso, verificando que cumpla con
las polticas de la organizacin, estndares de software
internos y estndares impuestos externamente, entre otros.
Revisar las actividades de ingeniera del software o de
conocimiento para verificar que cumplan con el proceso de
software definido: El equipo de SQA identifica, documenta y
hace el seguimiento de cualquier desviacin del proceso y
verifica las correcciones realizadas.
Auditar productos de trabajo de software designados, para
verificar que cumplan con aquellos definidos como parte del
proceso de software: El equipo de SQA revisa productos
seleccionados; identifica, documenta y hace el seguimiento
de las desviaciones; verifica las correcciones realizadas y
peridicamente informa los resultados de su trabajo al
gerente del proyecto.
 Asegurar que las desviaciones detectadas sean documentadas mismas. En la figura 2 se muestra la relacin entre el modelo
y manejadas de acuerdo a procedimientos documentados: Las general de aseguramiento de la calidad del software y la
desviaciones pueden encontrase en el plan de proyecto, metodologa IDEAL.
descripciones del proceso, estndares aplicables o productos
de trabajo tcnico. Metodologa de Desarrollo
Interfaz de Aseguramiento de
Registrar cualquier incumplimiento y reportarlo a la alta del Software de la
la Calidad del Software
gerencia: A los incumplimientos se les debe hacer Organizacin
seguimiento hasta que sean resueltos.
El equipo de SQA participa tambin en la tarea de Identifica-
cin de la
Planificacin

recolectar y analizar mtricas de software como as tambin en tarea

establecer y revisar procedimientos, planes y estndares.

III. MODELO GENERAL Desarrollo de
Requerimientos

los
En la presente seccin se esboza el Modelo General, es prototipos

decir, el diseo de acciones y mtodos que constituyen un

enfoque prctico para el desempeo de la funcin de SQA en Ejecucin
Anlisis

una organizacin. Tambin se presenta el modelo de mejora de la

construccin
continua del mismo. del sistema
integrado

A. Modelo de aseguramiento de calidad sugerido Diseo Metodologa,

Una metodologa de desarrollo de software (ya sea para Actuacin

para
Estndares y
conseguir el
software convencional o para sistemas basados en el mantenimien- Normas de la
to perfectivo
conocimiento) establece una forma consistente de ejecutar las Codificacin Organizacin
actividades relacionadas con el software dentro de una
organizacin. Toda metodologa describe: Lograr una
adecuada
Elementos: Cubren un conjunto de actividades bien transferencia
Verificacin
del Sistema
tecnolgica
definidas, relacionadas y agrupadas.
Arquitectura: Establece el orden, las interfaces, las
interdependencias y otras relaciones entre los elementos. Validacin
del Sistema

Adicionalmente, la metodologa podra describir estndares,

mtodos y herramientas.
La metodologa de desarrollo es la que provee continuidad Instalacin

en el proceso de software de una organizacin y es una

referencia para mtricas y mejoras de dicho proceso.
Sobre la base del concepto de metodologa y de los
conceptos bsicos ya definidos en el captulo anterior, se
propone un enfoque o modelo de aseguramiento de la calidad
del software que tiene las siguientes caractersticas:
El modelo de aseguramiento de calidad de software sugerido
es una interfaz a una metodologa de desarrollo de software.
En particular, para el presente trabajo, se utilizar la
metodologa IDEAL.
El modelo que aqu se presenta no es una metodologa en s
misma, sino que debe acoplarse a una metodologa de
desarrollo para poder implementarse.
Esta interfaz est compuesta por mdulos independientes,
donde cada uno de ellos se asocia a ciertos procesos de la
metodologa IDEAL.
La interfaz cuenta tambin con un mdulo de ejecucin
recurrente, en donde, para todas y cada uno de las entradas a
cada uno de los otros mdulos, se verifica la conformidad de
las mismas con la metodologa, estndares y normas aplicables
que estn vigentes en la organizacin.
El modelo de aseguramiento de la calidad del software
sugerido no es dependiente de la metodologa de desarrollo
utilizada en una organizacin, sino que se adapta a ella. Sobre
la base de los procesos de la metodologa de desarrollo, sus
precedencias, sus ciclos de ejecucin, y por supuesto de las
caractersticas del proyecto en curso, se seleccionan aquellas
porciones de la interfaz que resulten necesarias para obtener los
niveles de calidad deseados y el orden de ejecucin de las
Fig. 2. Relacin entre el modelo general y la metodologa de desarrollo
B. Aplicacin del Modelo
El modelo aqu presentado, es un modelo genrico cuya
flexibilidad permite su adaptacin a cada proyecto en
particular. De esta forma, se podrn seleccionar los segmentos
del mismo que cubran las necesidades de cada proyecto,
evitando la realizacin de actividades innecesarias.
El modelo general de aseguramiento de la calidad, se
documenta en un plan general de aseguramiento de la calidad.
La flexibilidad, que permite la adaptacin del modelo genrico
o plan general de aseguramiento de la calidad del software, a
todo tipo de proyectos, se formaliza a travs de los planes
especficos de aseguramiento de la calidad del software para
cada proyecto.
El plan especfico de aseguramiento de la calidad, para un
proyecto en particular, ser entonces, la adaptacin del plan
general a las caractersticas particulares de ese proyecto. En la
figura 3 se muestra la relacin entre el plan general de
aseguramiento de la calidad del software y cada uno de los
planes especficos.
C. Mdulos del modelo
En el captulo siguiente se describir cada uno de los
mdulos del modelo general de aseguramiento de la calidad
propuesto, indicando para cada uno de ellos los siguientes:

Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico. 171
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
 Objetivo: Descripcin del propsito del mdulo, para usar
como una regla contra la que medir el progreso del mismo.
permanentes mejoras y actualizaciones de acuerdo a la
experiencia y a las necesidades que surjan como consecuencia
de la aplicacin del mismo.
En la figura 4 se muestra el modelo de actualizacin y
mejora continua del plan general de aseguramiento de la
calidad del software y de los planes especficos de
aseguramiento de la calidad del software de cada proyecto, as
como la adaptacin del plan general, y la ejecucin y
verificacin de los planes especficos.

Plan General de
Aseguramiento de la
Calidad del Software

Fig. 3. Relacin entre el plan general y los planes especficos

Entrada: Documentos y/o informacin necesaria para

Paso 1
completar el mdulo. El nombre de los documentos es Paso 4
Adaptacin del Plan
genrico, sin embargo este nombre debe ser adaptado al Actualizacin del Plan
General a cada Proyecto
General
nombre del producto resultante, del proceso lgico particular
correspondiente, en la metodologa utilizada.
Proceso: Descripcin de las tareas y acciones que debe
ejecutar el integrante del equipo de SQA para dar por
cumplido el mdulo.
Plan Especfico de
Salida: Productos que deben ser generados al final del Aseguramiento de la
mdulo. Calidad del Software

Lista de verificacin: Checklist que utilizan los integrantes

del equipo de SQA para verificar que ha cumplido el mdulo
correctamente. Las lista de verificacin se definen en tablas,
los campos de esas tablas se explican en la tabla I.
Paso 3 Paso 2
TABLA I. EXPLICACIN DE LOS CAMPOS QUE FORMAN PARTE DE LAS Actualizacin del Plan Ejecucin del Plan
TABLAS QUE DEFINEN LAS LISTAS DE VERIFICACIN Especfico Especfico

CAMPOS EXPLICACIN
Nmero Un nmero que identifica secuencialmente
los tems de control de calidad, el resultado
positivo indicara que ese paso ha sido
Productos resultantes de la
realizado correctamente.
Ejecucin
tem tem especfico de control de calidad que es
usado para medir la efectividad de ejecucin
de este paso. Fig. 4. Modelo de actualizacin y mejora continua
Respuesta El analista de calidad deber indicar en esta
columna si ha realizado el tem referenciado. D.2. Detalle del modelo de mejora continua del plan
La respuesta puede ser: SI, NO o N/A si la A continuacin se detalla el modelo de mejora continua del
misma no es aplicable al proyecto en plan general de aseguramiento de la calidad como as tambin
cuestin.
de los planes especficos correspondientes a cada proyecto
Comentarios Esta columna es utilizada para clarificar la particular.
respuesta de SI, NO o N/A para los tems
indicados. Adicionalmente, y slo para contextualizar los pasos
Generalmente la columna de comentarios correspondientes a la mejora continua, se detallan brevemente
slo se completa en las respuestas por NO; los pasos correspondientes a la adaptacin del plan general, y
las respuestas por NO debern ser la ejecucin y verificacin de los planes especficos:
investigadas y se deber tomar una Paso 1:
determinacin respecto a si este tem deber
ser completado antes de considerar este Entrada: Plan general de aseguramiento de la calidad de
paso completo. software.
Accin: Adaptacin del plan general de aseguramiento
D. Actualizacin del plan de la calidad de software a cada proyecto particular.
D.1. Modelo de mejora continua del plan Salida: Plan especfico de aseguramiento de la calidad
de software para un proyecto particular
El modelo o plan general de aseguramiento de la calidad
del software aqu presentado no mantiene un estado Paso 2:
estacionario o esttico, sino que es dinmico y sujeto a
172 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
 Entrada: Plan especfico de aseguramiento de la calidad
de software, para un proyecto particular.
Accin: Ejecucin del plan especfico de aseguramiento
de la calidad de software.
Salida: Productos resultantes de la ejecucin del plan
especfico de aseguramiento de la calidad de software.
Paso 3:
Entrada: Productos resultantes de la ejecucin del plan
especfico de aseguramiento de la calidad de software.
Accin: Anlisis de la calidad de los productos
resultantes de la ejecucin del plan especfico.
Generacin de recomendaciones y acciones a realizar,
con su correspondiente justificacin, para mejorar el
plan especfico de aseguramiento de la calidad de
software.
Salida: Plan especfico de aseguramiento de la calidad
de software, para un proyecto particular, actualizado.
Paso 4:
Entrada: Actualizaciones realizadas al plan especfico
de aseguramiento de la calidad de software, para un
proyecto particular.
Accin: Anlisis de las actualizaciones realizadas al
plan especfico de aseguramiento de la calidad del
software, con sus correspondientes justificaciones.
Actualizacin del plan general de aseguramiento de la
calidad del software.
Salida: Plan general de aseguramiento de la calidad del
software actualizado.
IV. MDULOS DEL MODELO
En el presente captulo se describen los Mdulos del
Modelo, se presentan para cada uno de ellos las acciones a
desempear, su objetivo, sus entradas, salidas, lista de
verificacin, mtricas y participantes involucrados.
A. Planificacin
A.1. Objetivo
Determinar qu recursos estarn disponibles para producir y
mantener el software asociado al proyecto.
Determinar cundo y cmo se incurrir en costos de personal,
tiempo de procesamiento, etc.
Medir el avance del desarrollo del proyecto.
A.2. Entrada
Plan de desarrollo (de software) del proyecto.
Estimacin del proyecto y mtodo utilizado para realizarla.
Descripcin del proceso de desarrollo a utilizar en el
proyecto.
A.3. Proceso
En la figura 5 se detalla grficamente, el proceso a
desarrollar durante este mdulo:
A.3.1.Verificacin de la Estimacin del Proyecto
Muchos proyectos de software son esencialmente
innovadores, pero una ineficaz estimacin del sistema, puede
llevar a un exceso de costos. Estimar costos de software es un
proceso complicado porque el desarrollo del proyecto es
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
influenciado por un largo nmero de variables, muchas de ellas
son subjetivas, no cuantificables e interrelacionadas en forma
compleja.
Fig. 5. Proceso del mdulo de planificacin
Una estimacin inapropiada de costos puede daar ms a la
calidad del proyecto de software que a cualquier otro factor.
Si la estimacin es incorrecta, el equipo de proyecto har lo
imposible para coincidir con la estimacin. Todo esto provoca
un aumento de costos de mantenimiento, insatisfaccin del
cliente, esfuerzo adicional en el rea del cliente para compensar
la debilidad del sistema, y desanimar al personal del proyecto.
La verificacin puede aumentar la validez de la estimacin. La
estimacin del software es un proceso de tres partes como se
describe a continuacin:
Validar la sensatez del modelo de estimacin.
Validar que el modelo incluya todos los factores necesarios.
Verificar la efectividad del modelo estimado de costo.
El detalle de cada uno de estos puntos, se encuentra en el
captulo de Tcnicas y Herramientas.
A.3.2. Verificacin del Estado del Proyecto
Para conocer el estado del proyecto se sugiere un sistema
simple de acumulacin de puntos para medir el progreso.
Luego este sistema puede compararse con el reporte gerencial
del proyecto. Si hay una diferencia significativa entre ambos
sistemas de medicin del progreso, el analista de calidad puede
cuestionar la validez de los resultados producidos por la
gerencia de proyecto y/ o sistema de conteo.
El sistema de puntos para realizar la medicin durante el
desarrollo del software, provee un mtodo objetivo, preciso y
eficiente de recoleccin y reporte del rendimiento de la
informacin en el campo de la ingeniera que a menudo carece
de visibilidad. El mtodo utiliza informacin basada en tems
de entregables de software y es obtenida como parte del
proceso de desarrollo. Los resultados son fciles de interpretar
y pueden presentarse en una variedad de formatos. El esquema
es flexible y puede modificarse para proyectos grandes y
chicos. El detalle del mismo, se encuentra en el captulo de
Tcnicas y Herramientas.
173
A.4. Salidas B. Requerimientos
Informe de estimacin del proyecto
B.1. Objetivo
Informe de estado del proyecto
Determinar si los requerimientos expresan las necesidades
A.5. Lista de Verificacin (Checklist) del usuario.
En la tabla I se presenta la lista de verificacin: Verificar la separacin de los requerimientos entre
obligatorios y opcionales.
TABLA II. LISTA DE VERIFICACIN DEL MDULO DE PLANIFICACIN
Verificar que cada requerimiento:
Est debidamente documentado, reflejando las necesidades

Comentarios
Respuesta
del usuario.
tem
#

Se encuentre dentro del alcance definido del sistema en

cuestin.

N/A
NO
Se encuentre dentro de los lmites del presupuesto para el

SI
La gerencia del proyecto, esta de acuerdo en tener un equipo sistema en cuestin.
1 de aseguramiento de la calidad y evaluacin de la estimacin y
estado del plan de desarrollo? Se encuentre bien definido (en forma completa), de manera
2
El equipo de aseguramiento de la calidad conoce la de evitar cambios posteriores.
estimacin del progreso utilizada para el proyecto?
3
El equipo de aseguramiento de la calidad conoce el mtodo Determinar que los requerimientos documentados puedan ser
para realizar los informes de estado del proyecto?
El equipo de aseguramiento de la calidad entiende el mtodo
implementables (pasibles de ser analizados, diseados,
4
utilizado para estimar y calcular? codificados) y verificables (pasibles de ser verificados y
El equipo de aseguramiento de la calidad ha realizado una
5 buena verificacin para determinar la validez de las
validados) en fases posteriores.
estimaciones realizadas?
Si el equipo de aseguramiento de la calidad est en B.2. Entradas
desacuerdo con la validez de las estimaciones realizadas.
6
Existe un procedimiento razonable para manejar tales Minutas de reunin con el usuario.
diferencias?
El equipo del proyecto posee un sistema de reportes Documento de especificacin de requerimientos del usuario.
7
razonable para informar el estado del mismo?
El equipo de aseguramiento de la calidad ha establecido que B.3. Proceso
8 pueden utilizarse los informes de estado de proyecto como
gua para la toma de decisiones? En la figura 6 se detalla grficamente, el proceso a
Existe algn procedimiento a seguir, si los informes de estado
9 indican que el proyecto est por encima o por debajo de las desarrollar durante este mdulo.
estimaciones?
El equipo de aseguramiento de la calidad ha tenido en cuenta HACER VERIFICAR
10 los factores ms importantes en la evaluacin de la estimacin
realizada (Ejemplo: tamao del software, etc.)?
El equipo de proyecto ha recibido una copia del estado del
11 REHACER
mismo?
El equipo de aseguramiento de la calidad tiene conocimiento
12
de cmo se efecta la planificacin? 1 Paso
El equipo de aseguramiento de la calidad tiene conocimiento
13
de cmo se efecta la estimacin del proyecto? Minutas de Reunin con el
Preparar la Matriz de
El equipo del proyecto tiene conocimiento del proceso de Usuario
Riesgo
14 desarrollo utilizado para construir el software especificado por
el proyecto? NO
15 El plan de proyecto est completo?
16 La estimacin del proyecto est totalmente documentada? 2 Paso
17 El proceso de desarrollo est totalmente documentado? SI
Requerimiento Reportes de la
El mtodo de estimacin utilizado para el proyecto, es
18 Realizar un Anlisis de preciso y completo Verificacin
razonable respecto de las caractersticas del mismo?
Factores a Verificar
La estimacin efectuada es razonable como para completar el
19
proyecto segn lo especificado en el plan?
El equipo del proyecto tiene un mtodo definido para Definicin de los
20 requerimientos del
determinar e informar el estado del mismo
Proyecto 3 Paso
El equipo de aseguramiento de la calidad, est de acuerdo
21 con que el estado informado coincide con el estado actual del
proyecto? Conducir un
"Walkthrough"

A.6. Mtricas
Eficacia de la estimacin Duracin actual del proyecto
de la duracin: Duracin estimada del Fig. 6. Proceso del mdulo de requerimientos
proyecto
Eficacia de la estimacin Esfuerzo actual del proyecto
B.3.1. Preparar la Matriz de Riesgo
del esfuerzo Esfuerzo estimado del
proyecto La Matriz de Riesgo es una herramienta diseada para
evaluar el control en los sistemas de informacin.
A.7. Involucrados Uno de los mayores beneficios de la matriz de riesgo es, no
slo la identificacin de los mismos, sino tambin qu es lo que
A.7.1. Equipo de Ingeniera el sistema debe hacer para con cada uno de ellos. En
Gerente de proyecto. principio, la matriz de riesgo es una herramienta de diseo,
pero puede ser usada como herramienta de verificacin.
A.7.2. Equipo de Aseguramiento de la Calidad del Software
En forma ideal la matriz de riesgo comienza en la fase de
Lder de aseguramiento de la calidad del software. requerimientos, se desarrolla en la fase de anlisis y se termina

174 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
en la fase de diseo. La ejecucin de la matriz de riesgo es un
proceso de cinco pasos, los cuales se encuentran detallados en
el captulo de Tcnicas y Herramientas.
B.3.2. Realizar un Anlisis de Factores a Verificar
Debe llevarse a cabo un proceso para estimar las
incumbencias (concerns) asociadas a la fase de
requerimientos del desarrollo del sistema. Debe incluirse un
programa de verificacin para cada factor a considerar (son
15), cubriendo cada fase del proceso de desarrollo. Para cada
factor hay un programa de verificacin que tiene en cuenta
ciertas consideraciones las cuales se encuentran detalladas en el
captulo de Tcnicas y Herramientas.
El programa de verificacin enumera aquellos criterios, que
aseguran al equipo de aseguramiento de la calidad, que la
magnitud de esa preocupacin es mnima. A estos criterios
debe responder el equipo de aseguramiento de la calidad.
Tambin se debe realizar una verificacin suficiente para
evaluar si el equipo de proyecto ha manejado adecuadamente
cada criterio de verificacin.
Los factores a verificar en la etapa de requerimientos son:
Requerimientos compatibles con la metodologa (Factor de
prueba: Metodologa)
Este mtodo se implementa como un proceso de cinco
pasos ejecutados en secuencia, los cuales se encuentran
detallados en el captulo de Tcnicas y Herramientas, que son:
Establecer reglas bsicas
Seleccionar el equipo / Notificar a los participantes
Presentacin del proyecto
Preguntas / recomendaciones
Reporte final
El tiempo destinado a cada paso depender del tamao de
la aplicacin que se est revisando y el grado de asistencia
deseado del equipo de walkthrough.
B.4. Salidas
Matriz de riesgo
Anlisis de factores de verificacin.
Informe de la inspeccin (walkthrough) confeccionado.
Resumen de la inspeccin (walkthrough) confeccionado.
B.5. Lista de Verificacin (Checklist)
En la tabla III se presenta la lista de verificacin.
TABLA III. LISTA DE VERIFICACIN DEL MDULO DE REQUERIMIENTOS

Funcionalidad de las especificaciones definidas (Factor de Respuesta

# tem Comentarios
prueba: Precisin)
SI NO N/A
Usabilidad de las especificaciones (Factor de prueba: 1
Los requerimientos definidos son
verificables?
Facilidad de uso) El usuario est de acuerdo con el
2
Mantenimiento de las especificaciones (Factor de prueba: requerimiento definido?
Los desarrolladores entienden los
3
Mantenibilidad) requerimientos?
El requerimiento definido coincide con los
Necesidades de portabilidad (Factor de prueba: Portabilidad) 4
objetivos del proyecto?
5 Se identificaron los riesgos del proyecto?
Interfaces del sistema (Factor de prueba: Acoplamiento) Se sigui un proceso razonable en la
6
definicin del requerimiento?
Criterios de performance (Factor de prueba: Performance) El proceso de control de requerimientos, es
7 adecuado para minimizar los riesgos del
Necesidades operativas (Factor de prueba: Facilidad de proyecto?
operacin) Durante el proceso de control de
8 requerimientos, se ha llevado a cabo un
Tolerancia (Factor de prueba: Fiabilidad) walktrough?

Reglas de autorizacin (Factor de prueba: Autorizacin) B.6. Mtricas

Requerimientos de integridad de archivos (Factor de prueba: Estabilidad de los Cantidad de requerimientos
Integridad de archivos) requerimientos: iniciales
Recuperacin ante fallas en los requerimientos (Factor de Cantidad total de
prueba: Auditora) requerimientos
Impacto de fallas (Factor de prueba: Continuidad de
procesamiento)
Completitud de los Cantidad de nuevos
Nivel de servicio deseado (Factor de prueba: Nivel de requerimientos: requerimientos agregados
Servicio)
Cantidad total de
Permisos y accesos (Factor de prueba: Seguridad)
requerimientos
B.3.3. Conducir un Walkthrough de Requerimientos
De los procesos de revisin, la inspeccin o recorrido Tasa de efectividad de la Cantidad de tems cubiertos
(walkthrough) de requerimientos es el menos estructurado y el verificacin: Cantidad total de tems
ms propenso a la creatividad. Por lo tanto ste se convierte en
un proceso de revisin que complementa los objetivos de la B.7. Involucrados
fase de requerimientos. El objeto de este proceso de revisin es
crear una situacin en la cual un grupo de gente con las B.7.1. Equipo de Ingeniera
habilidades adecuadas pueda ayudar al equipo en el desarrollo Gerente de proyecto.
de las soluciones del proyecto. El walkthrough intenta usar la Grupo de anlisis de requerimientos.
experiencia y juicio del equipo de revisin como un soporte en
el proceso de desarrollo. B.7.2. Equipo de Aseguramiento de la Calidad del Software
Lder de aseguramiento de la calidad del software.

Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico. 175
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
 Analistas de aseguramiento de la calidad del software Senior sistema como es percibido por los usuarios de esa
y/o Semi-senior. comunidad.
Reconocer que una especificacin tendr varios niveles de
C. Anlisis
detalle.
C.1. Objetivo Se verificar que la especificacin funcional cumpla, con
Describir la funcionalidad del producto que va a ser al menos, los siguientes lineamientos:
entregado. El formato de la representacin y contenido debera ser
Definir el ambiente en el que va a operar. relevante para el problema. Debe llevarse a cabo, un
desarrollo general para los contenidos de las especificaciones.
Definir la confiabilidad y el compromiso de mantenimiento.
La informacin contenida en la especificacin debe ir de lo
Identificar las necesidades de soporte u operacin, como general a lo particular (estar anidada). Las representaciones
hardware, software, etc. deberan revelar capas de informacin a fin de permitir al
Definir para cada requerimiento, qu prueba se va a ejecutar lector que pueda moverse al nivel de detalle que sea
para asegurar que se cumpla con el mismo. requerido. Se deben indicar esquemas de numeracin dentro
de los diagramas utilizados, indicando el nivel de detalle que
C.2. Entradas
se presenta. Es importante presentar la misma informacin a
Documento de especificacin de requerimientos revisado diferentes niveles de abstraccin para ayudar a su
Documento de especificacin funcional. entendimiento.
C.3. Proceso Los formatos diferentes de diagramas a utilizar y otras
formas de notacin, debern ser restringidas al mnimo en
En la figura C se detalla grficamente, el proceso a nmero y consistentes en su uso. La informacin confusa e
desarrollar durante este mdulo. inconsistente, sea tanto simblica o grfica, perjudica el
entendimiento y propicia errores.
La especificacin funcional, debe ser verificable.
Se verificar que la especificacin funcional cumpla, con al
menos, el siguiente contenido:
I. Introduccin
a. Resumen del Sistema
b. Descripcin del producto
c. Entregables
II. Ambiente
a. Usuarios
b. Servicios
c. Fsico
d. Seguridad
III. Descripcin de la informacin
a. Representacin del contenido de la informacin
b. Representacin del flujo de la informacin
i. Flujo de datos
ii. Flujo de control
IV. Descripcin funcional
a. Particin funcional
Fig. 7. Proceso del mdulo de anlisis
b. Descripcin funcional
i. Narrativa de proceso general
C.3.1. Analizar la Especificacin Funcional ii. Restricciones / Limitaciones
La especificacin funcional, debe ser vista como un iii. Requerimientos de rendimiento
proceso de representacin, a fin de poder llegar a una exitosa iv. Restricciones de diseo
implementacin de software. Algunos principios para v. Diagramas de soporte
especificar, podran ser: c. Descripcin de control
Separar requerimientos funcionales de implementacin. i. Especificacin de control
ii. Restricciones de para el diseo
Desarrollar un modelo del comportamiento deseado del V. Descripcin de situacin
sistema, que comprenda datos y la respuesta funcional del a. Estado del sistema
sistema a los estmulos del ambiente. b. Eventos y acciones
Establecer un contexto en el cual el software opera VI. Validacin y criterios
especificando la forma en la cual otros componentes del a. Lmites y restricciones
sistema interactan con el software. b. Clases de pruebas requeridas
Desarrollar un ambiente en el cual el sistema opere y c. Respuesta esperada del software
reaccione a los estmulos del mismo. d. Consideraciones especiales
Crear un modelo cognitivo en lugar de un diseo o un VII. Cronograma
modelo de implementacin. El modelo cognitivo describe el VIII. Apndices

176 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
C.3.2. Conducir una Inspeccin Formal
La revisin de una especificacin funcional es conducida Correctitud de la Cantidad de funciones
por el desarrollador y el cliente. Dado que las especificaciones funcionalidad: corregidas
forman el punto fundamental y a partir del cual se realizar el Cantidad total de funciones
diseo y subsecuentemente las actividades de la ingeniera del establecidas
software o de conocimiento, se debern extremar los cuidados
para conducir esta revisin. Completitud de la Cantidad de nuevas funciones
La revisin en una primera instancia es conducida en un funcionalidad: agregadas
nivel macro. En este nivel, los inspectores intentan garantizar Cantidad total de funciones
que la especificacin est completa, consistente y exacta. establecidas
Se tendrn en cuenta los siguientes lineamientos para una
revisin detallada: Eficiencia en la Cantidad de defectos detectados
deteccin de defectos: hasta anlisis
Detectar y remplazar trminos vagos.
Cantidad total de defectos
En el caso de listas de elementos, asegurar que hayan sido
incluidos todos.
Eficiencia en la Cantidad de defectos removidos
Cuando se especifiquen rangos (numricos, etc.) asegurarse remocin de defectos: hasta anlisis
que no contengan valores asumidos sin ser definidos
Cantidad total de defectos
expresamente
Estar alerta de verbos y pronombres ambiguos. Tasa de efectividad de Cantidad de tems cubiertos
Identificar afirmaciones que no incluyan certeza. la verificacin: Cantidad total de tems
Cuando una estructura es descripta en palabras, asegurar que
se realice un diagrama para ayudar a comprenderla.
Cuando sea necesario realizar un clculo especificado, TABLA IV. LISTA DE VERIFICACIN DEL MDULO DE ANLISIS

asegurar que se presente al menos dos ejemplos del mismo.

tem Respuesta
# Comentarios
Con respecto a los cambios en los requerimientos, una vez
SI NO N/A
que los mismos han sido finalizados, el usuario deber notar Los objetivos y metas del sistema se mantienen
que cada uno de ellos es una ampliacin del alcance del 1 consistentes con las polticas de software de la
organizacin?
software y por ende, un cambio en la especificacin funcional. La estructura y el flujo de la informacin, est
2 adecuadamente definida por el rea a la cual
Esto incrementar el costo del proyecto y/ o extender el compete el problema?
tiempo establecido para su finalizacin. Son claros los diagramas? Pueden ser
3 explcitos sin necesidad de ser descriptos o
An cuando se realicen las mejores revisiones, cierto narrados?
Las funciones principales del sistema, estn
nmero de problemas en la especificacin persiste. La 4 dentro del alcance? Cada una de ellas ha sido
especificacin es difcil de verificar, por ende las adecuadamente definida?
Es consistente el comportamiento del sistema
inconsistencias u omisiones pueden pasar desapercibidas. 5 con la informacin que debe procesar y las
funciones que debe desarrollar?
Durante la revisin, pueden ser recomendados ms cambios en 6 Las limitaciones del sistema son realistas?
la especificacin funcional. Puede ser extremadamente difcil 7
Ha sido considerado el riesgo tecnolgico del
desarrollo?
estimar el impacto global del cambio, esto es, cmo un cambio 8
Se han considerado requerimientos alternativos
de software?
en una funcin afecta a los requerimientos en otra funcin. Ha sido detallado el criterio de verificacin y
Esto ltimo deber ser tenido muy en cuenta a la hora de 9 validacin? Los mismos, son adecuados para
determinar el xito del sistema?
impactar dicho cambio. Existen inconsistencias, omisiones o
10 redundancias en el modelo de informacin del
sistema?
C.4. Salidas 11 El usuario final ha estado involucrado?
El usuario revis el prototipo y/o manual del
Informe de la Inspeccin 12
usuario?
Resumen de la Inspeccin 13
Han sido debidamente planificadas las
estimaciones de esfuerzo?

C.5. Lista de Verificacin (Checklist) C.7. Involucrados

En la tabla IV se presenta la lista de verificacin.
C.7.1 .Equipo de Ingeniera
Gerente de proyecto.
C.6. Mtricas Grupo de anlisis de requerimientos.
Estabilidad de los Cantidad de requerimientos Grupo de anlisis funcional.
requerimientos: modificados C.7.2. Equipo de Aseguramiento de la Calidad del Software
Cantidad total de requerimientos Lder de aseguramiento de la calidad del software.
establecidos
Analistas de aseguramiento de la calidad del software Senior
y/o Semi-senior.
Estabilidad de la Cantidad de funciones
funcionalidad: modificadas
Cantidad total de funciones
establecidas

Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico. 177
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
D. Diseo
D.1. Objetivo
Establecer los factores que conducen a un diseo correcto y
preciso
Conducir revisiones de diseo.
Conducir inspecciones de los entregables del diseo
D.2. Entradas
Comprensin del diseo por parte del equipo de
aseguramiento de la calidad
Entregables derivados del diseo:
Especificaciones de entrada
Especificaciones de procesamiento
Especificaciones de archivos
Especificaciones de salida
Especificaciones de control
Diagramas de flujo del sistema
Requerimientos de software y hardware.
Especificacin de los procedimientos de operacin manual.
Poltica de resguardo de la informacin.
Documento de diseo de alto nivel (Lgico)
Documento de diseo de detalle (Fsico y lgico)
D.3. Proceso
En la figura 8 se detalla grficamente, el proceso a
desarrollar durante este mdulo:
Fig. 8. Proceso del mdulo de diseo
D.3.1. Ranking de Factores de xito
El ranking (scoring) es una herramienta predictiva que
utiliza experiencias en proyectos anteriores. Los proyectos en
curso son analizados para determinar los atributos de los
mismos y su correlacin con el xito o el fracaso de proyectos
o sistemas en particular. Una vez que los atributos
correlacionados al xito o al fracaso pueden ser identificados,
tambin pueden ser usados para predecir el comportamiento
del sistema que est en desarrollo.
El concepto es el mismo que el usado para predecir el
resultado de las elecciones. La gente que hace las predicciones
procura identificar distritos electorales que muestran una
correlacin histrica alta en los resultados de elecciones
anteriores. El conocimiento del registro de votos de un distrito
en especial y los resultados de elecciones previas, nos provee la
base para hacer futuras predicciones. Esos distritos con un
registro de grandes ganadores pueden servir de muestra, para
luego basados en esas muestras, predecir el resultado de una
eleccin antes que los votos sean contados.
Estos tipos de predicciones en sistemas de computacin son
bien conocidos, pero no han sido bien utilizados hasta que el
concepto de ranking fue desarrollado. Por ejemplo, sabemos
que hay una correlacin positiva entre la participacin del
usuario y el sistema de computacin: cuanto ms involucrado
este el usuario, mayor probabilidad de que el sistema sea
exitoso. Tambin sabemos que habr problemas con el sistema
de computacin que empuja las actuales corrientes de
tecnologa. Por ejemplo, el primer sistema en usar la nueva
tecnologa puede ser identificada como un sistema de alto
riesgo, porque la mayora de los inconvenientes ocurrir
durante la implementacin.
Los criterios que se utilizan bajo el concepto de ranking, se
describen en el captulo de Tcnicas y Herramientas
Al concluir el ranking, el resultado puede ser usado en
cualquiera de las siguientes formas:
Estimar la extensin de la verificacin: A mayor riesgo, la
gerencia del proyecto puede requerir ms verificaciones.
Sabiendo que la aplicacin es de alto riesgo, se alertar al los
gerente del proyecto respecto de la necesidad de tomar las
medidas correspondientes para reducir el riesgo a un nivel
aceptable.
Identificar mdulos a verificar: Dependiendo de la
sofisticacin del instrumento con el que se obtuvo el ranking,
puede identificarse mdulos especficos para la verificacin.
Por ejemplo, si la lgica computacional se sabe que es de alto
riesgo, la verificacin debera evaluar exhaustivamente la
exactitud de este proceso.
Identificar la composicin del equipo de verificacin: Los
tipos de riesgos asociados con el sistema ayudan a determinar
la composicin del equipo de test. Por ejemplo, si los riesgos
tratan ms con la tecnologa que con la lgica, el equipo de
test debera incluir individuos con conocimientos profundos
en esa tecnologa.
Al ranking de riesgo se llega a travs de un desarrollo
matemtico, como se muestra en el captulo de Tcnicas y
Herramientas.
D.3.2. Anlisis de Factores
El encargado de dirigir la verificacin podr seleccionar
los factores de inters apropiados, para ajustar la verificacin,
teniendo en cuenta los siguientes objetivos generales para la
fase de diseo:
Desarrollar una solucin al problema de negocio planteado.
Determinar el rol de la tecnologa para resolver el problema.
Desarrollar especificaciones para los segmentos manuales y
automatizados del sistema.
Cumplir con el plan de accin, procedimientos, estndares y
regulaciones.
Definir los controles que reducirn riesgos de la aplicacin,
llevndolos a un nivel aceptable.

178 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
 Completar el proyecto dentro de las restricciones del Una o ms revisiones pueden llevarse a cabo durante la fase
presupuesto, personal y cronograma establecidos. de diseo. La cantidad de revisiones depender de la
Los factores que deben analizarse durante la fase de diseo importancia del proyecto y del lapso de tiempo en la fase de
se describen a continuacin, y puede encontrarse ms detalle en diseo. As podrn llevarse a cabo revisiones del diseo de alto
el captulo de Tcnicas y Herramientas: Los factores a verificar nivel y del diseo detallado. Cada defecto descubierto durante
en la Fase de Diseo son: la revisin del diseo de alto nivel debe documentarse. Se
Controles de integridad de datos. confeccionar un reporte de defectos. Los defectos deben
documentarse, categorizarse, registrarse, presentarse al equipo
Reglas de autorizacin.
de proyecto para corregir, y referenciarlo al documento
Controles de integridad de archivos. especfico en el cual el defecto fue notado. Un ejemplo del
Pistas de auditoria. formulario para registrar estos defectos, puede encontrarse en
Plan de contingencia. el captulo de Tcnicas y Herramientas.
Mtodo para alcanzar el nivel de servicio requerido.
D.3.4. Conduccin de la Inspeccin de los Entregables de
Procedimientos de acceso. Diseo
Diseo acorde con la metodologa establecida. La Inspeccin es un proceso por el cual los productos
Diseo acorde con los requerimientos establecidos. completos pero no verificados, son evaluados para saber si los
Facilidad de uso. cambios especificados fueron implementados correctamente.
Mantenibilidad del diseo. Para lograr esto, los inspectores examinan los productos
Portabilidad del diseo. antes del cambio, las especificaciones de cambio, y los
Interfaces de diseo. productos luego del cambio para determinar los resultados.
Buscan tres tipos de defectos: Incorrectos (el cambio no se ha
Diseo acorde con criterios establecidos.
hecho correctamente), faltantes (algo que debera haberse
Necesidades de operacin. cambiado, no se cambi), y adicionales (algo fue cambiado o
D.3.3. Conduccin de la Revisin del Diseo agregado sin la intencin de hacerlo).
La revisin de diseo ser estructurada usando la misma D.4. Salidas
informacin bsica que la utilizada para llevar a cabo el Informe de la inspeccin.
ranking. El objetivo es identificar de antemano aquellos
Resumen de la inspeccin.
atributos del diseo que se correlacionan con los problemas del
sistema. Entonces durante la revisin del diseo, se D.5. Lista de Verificacin (Checklist)
investigarn dichos atributos para determinar si el equipo de
En la tabla 4.4 se presenta la lista de verificacin.
proyecto los ha tratado apropiadamente.
La revisin del diseo deber ser conducida por un grupo D.6. Mtricas
de individuos con conocimientos en el proceso de diseo. El Cantidad de defectos detectados
grupo tendr la responsabilidad de revisar la integridad y Eficiencia en la hasta diseo
racionabilidad de la aplicacin. No es necesario que el grupo deteccin de defectos: Cantidad total de defectos hasta
conozca la aplicacin especficamente pero s debe conocer la diseo
metodologa de la organizacin.
La revisin de diseo normalmente es formal y altamente Cantidad de defectos removidos
estructurada. Los miembros del equipo intentan determinar si Eficiencia en la hasta diseo
todas las tareas se han realizado apropiadamente. Al final de la remocin de defectos: Cantidad total de defectos hasta
revisin de diseo, el equipo emite un reporte indicando sus
diseo
hallazgos y recomendaciones acerca del proyecto. El equipo de
revisin de diseo comprende los siguientes miembros:
Tasa de efectividad de Cantidad de tems cubiertos
Personal del proyecto. la verificacin: Cantidad total de tems
Equipo de revisin independiente.
La siguiente es la lista con los pasos de una revisin de Cantidad de cambios introducidas
diseo, la descripcin detallada est en el captulo de Tcnicas en el diseo
y Herramientas: Estabilidad del diseo:
Cantidad total de cambios en el
Seleccionar el equipo de revisin. proyecto
Entrenar los miembros del equipo de revisin.
Notificar al equipo de proyecto. D.7. Involucrados
Asignar tiempos adecuados.
Documentar los datos de la revisin. D.7.1. Equipo de Ingeniera
Revisar los datos con el equipo de proyecto. Gerente de proyecto.
Desarrollar recomendaciones de revisin. Grupo de diseo de alto nivel (o lgico).
Revisar recomendaciones con el equipo de proyecto. Grupo de diseo de detalle (o fsico).
Preparar un reporte final. Grupo de administracin de base de datos.
Grupo de analistas desarrolladores.

Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico. 179
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
D.7.2. Equipo de Aseguramiento de la Calidad del Software Respuesta Comenta
# tem
Lder de Aseguramiento de la Calidad del Software SI NO N/A
rios

Analistas de aseguramiento de la calidad del software Senior 25

Han preparado los inspectores una lista de
defectos?
y/o Semi-senior. Se ha programado la inspeccin
26 convenientemente para todos los
inspectores?
E. Codificacin Han concurrido todos los inspectores a la
27
reunin de inspeccin?
E.1. Objetivo 28
Estuvieron de acuerdo todos los inspectores
con la lista de defectos?
Fueron identificados los defectos durante la
El principal objetivo de esta prueba es asegurar que las 29 reunin de revisin registrados y entregados
especificaciones de diseo hayan sido correctamente al autor?
El autor estuvo de acuerdo acerca de
implementadas. 30
realizar las correcciones necesarias?
Se ha desarrollado un proceso razonable
31 para determinar si esos defectos han sido
E.2. Entradas corregidos satisfactoriamente?
La certificacin del moderador ha sido
Los entregables que funcionan como entrada al proceso de 32 tomada en cuenta para el producto /
verificacin de codificacin son los siguientes: entregable inspeccionado?

TABLA V. LISTA DE VERIFICACIN DEL MDULO DE DISEO

Especificaciones de programas.
Respuesta Comenta Documentacin de programas.
# tem
rios
SI NO N/A
Listado de cdigo.
1
El equipo de aseguramiento de la calidad
tiene buenos conocimientos acerca del
Programas ejecutables.
proceso de diseo? Diagramas de flujo de los programas.
Si se han utilizado herramientas
2
automatizadas en la creacin del diseo, las Instrucciones para el operador.
conocen los miembros del equipo de
aseguramiento de la calidad?
Han recibido los miembros del equipo de E.3. Proceso
aseguramiento de la calidad todos los
3
entregables de la fase necesarios para llevar En la figura 9 se detalla grficamente, el proceso a
a cabo las verificaciones correspondientes?
Los usuarios estn de acuerdo con que el desarrollar durante este mdulo:
4
diseo representa la realidad?
El equipo de proyecto cree que el diseo
5
representa la realidad?
Han identificado los miembros del equipo de
aseguramiento de la calidad los factores de
6
xito, tanto positivos como negativos, que
pudieran afectar el xito del diseo?
Han utilizado los miembros del equipo de
aseguramiento de la calidad, tales factores
7
en la puntuacin de las probabilidades de
xito?
Entienden los miembros del equipo de
8 aseguramiento de la calidad los factores
relacionados con el diseo?
Han analizado los miembros del equipo de
aseguramiento de la calidad los factores de
9
test del diseo para evaluar el potencial
impacto sobre el xito del mismo?
Ha sido instruido el equipo de Revisin
10 acerca de lo que representa el xito del
Diseo?
La Gerencia apoya el uso del proceso de
11
revisin del diseo?
El proceso de revisin del diseo fue
12
conducido en un momento apropiado?
Son razonables los tems identificados en el
13
proceso de revisin del diseo?
Estn de acuerdo los miembros del equipo
14 de aseguramiento de la calidad que los tems
identificados necesitan ser verificados?
La Gerencia apoya la ejecucin de
15
inspecciones en el proyecto?
Se ha provisto del tiempo suficiente en el
16 cronograma del proyecto para realizar
Fig. 9. Proceso del mdulo de codificacin
inspecciones?
Han sido instruidos los responsables del
17 proyecto acerca de la importancia de la
participacin en las inspecciones?
E.3.1. Depuracin de Programas
La Gerencia ve las inspecciones como una
parte integral del proceso, en lugar de
Se utilizan tres metodologas para la deteccin y
18
tomarlo como una auditora al desempeo de eliminacin de los errores en la codificacin:
los participantes?
19
Han sido planificados los procesos de Depuracin de errores sintcticos.
Inspeccin?
20
Han sido identificados los inspectores y Depuracin de errores estructurales.
asignado sus roles especficos?
21
Han sido entrenados los inspectores para Depuracin de errores funcionales.
cumplir con su rol?
Se les ha dado a los inspectores los El detalle de cada una de ellas est en el captulo de
22 materiales necesarios para cumplir con la
inspeccin?
Tcnicas y Herramientas.
Se les ha dado a los inspectores tiempo
adecuado para realizar las tareas habituales
23
que le permitirn cumplir con la preparacin
y la reunin para el proceso de inspeccin?
Se han preparado adecuadamente los
24
inspectores para la inspeccin?

180 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
E.3.2. Anlisis de Factores de Codificacin Cantidad de defectos
Eficiencia en la removidos
A continuacin, se detallan los factores a analizar. El remocin de defectos:
detalle de cada uno de ellos est en el captulo de Tcnicas y Cantidad total de defectos
Herramientas:
Implementacin del control de integridad de informacin. Tasa de efectividad de Cantidad de tems cubiertos
Implementacin de reglas de autorizacin. la verificacin: Cantidad total de tems
Implementacin de control de integridad de archivos.
Implementacin de auditoras de rastreo. E.7. Involucrados
Plan de contingencia escrito.
E.7.1. Equipo de Ingeniera
Consecucin del nivel de servicio deseado para el sistema.
Gerente de proyecto.
Implementacin de procedimientos de seguridad.
Grupo de programacin.
Cumplimiento del programa con la metodologa a adoptar.
Programa acorde al diseo (Correctitud). E.7.2 Equipo de Aseguramiento de la Calidad del Software
Programa acorde al diseo (Facilidad de uso). Lder de Aseguramiento de la Calidad del Software
Mantenimiento del programa. Analistas de aseguramiento de la calidad del software Senior
Programa acorde al diseo (Portabilidad). y/o Semi-senior.
Programa acorde al diseo (Acoplamiento).
Desarrollo de procedimientos operativos.
F. Verificacin del Sistema
Criterio de ejecucin del programa (Performance).
F.1. Objetivo
E.3.3. Conduccin de Revisiones de Pares
El objetivo es determinar si el software funcionar
Se utiliza la revisin por pares, para evaluar la estructura y correctamente cuando se ejecute. Para ello:
funcionalidad del programa. La revisin por pares detecta
Se verificar que se haya probado la ejecucin del software
errores sintcticos, ms por observacin personal que por el
en un ambiente separado (test), siendo aproximadamente el
resultado directo del Walktrough.
mismo entorno operacional en que ser ejecutado luego
E.4. Salidas (produccin).
Dos son las salidas de este proceso Las pruebas sern verificadas, una vez terminada su
La eliminacin de todos los errores de codificacin utilizando ejecucin y aprobacin interna.
pruebas estticas. Cualquier desviacin de los resultados esperados ser
Listado de errores encontrados. reportada.
Dependiendo de la severidad y naturaleza de dichos
E.5. Lista de Verificacin (Checklist) problemas, podran llegar a realizarse solicitudes de cambios al
En la tabla VI se presenta la lista de verificacin: sistema antes de su puesta en produccin.

TABLA VI. LISTA DE VERIFICACIN DEL MDULO DE CODIFICACIN F.2. Entradas

Planes de pruebas:
Respuesta Comen
# tem
tarios Pruebas en lnea (On-Line)
SI NO N/A
Es considerada una responsabilidad del programador la
Pruebas por lotes (Batch)
1
verificacin y la validacin de los programas?
El programador entiende la diferencia entre testing esttico y
Pruebas de interfaces.
2
dinmico?
El programa podra ser sometido a testing esttico como
Pruebas de regresin.
3
medio primario para remover defectos? Pruebas de integracin.
El programador entiende el proceso que generar el cdigo
4
del programa? Pruebas de stress.
5 El programador entiende y usa la tcnica de debugging?
6
El programador entiende los conceptos implicados, y los Datos de prueba.
tendr presentes en la verificacin de la programacin?
7
El programador es verificado usando revisin por pares o Resultados de las pruebas.
inspeccin de cdigo?
El programa ser sometido a un test completo antes de
8
ingresar a un nivel superior de test? F.3. Proceso
Todos los defectos no cubiertos estn registrados en
9
detalle? En la figura 10 se detalla grficamente, el proceso a
10
Todos los defectos no cubiertos fueron corregidos antes de desarrollar durante este mdulo:
ingresar al siguiente nivel de verificacin?

E.6. Mtricas
Densidad de defectos Cantidad de defectos
por componente: Tamao del componente

Cantidad de defectos
Eficiencia en la detectados
deteccin de defectos:
Cantidad total de defectos

Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico. 181
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642

Fig. 10. Proceso del mdulo de verificacin
F.3.1. Verificar la Construccin de Datos / Scripts de
Prueba
El concepto de construccin de datos de prueba es,
simplemente, la creacin de un proceso representativo de la
realidad usando transacciones ficticias. De dichos datos, se
tomar una muestra representativa para llevar a cabo una
verificacin de los mismos. La correcta seleccin de dicha
muestra es la clave para el xito de esta tarea. Dentro de esta
tarea debe abarcarse la verificacin de los siguientes:
Diseo de archivos de prueba
Estos archivos deben involucrar transacciones normales,
transacciones con datos invlidos, y transacciones que
puedan hacer incurrir al sistema en alguna situacin de
excepcin.
Ingreso de los datos de prueba
Despus que las transacciones de prueba estn definidas, se
deben introducir en el sistema todos los datos necesarios
para que las mismas puedan ser procesadas.
Anlisis de los resultados esperados
Antes de procesar alguna transaccin, el equipo de proyecto
debe establecer el resultado esperado para cada transaccin
a probar para poder compararla con el obtenido luego de
realizada la misma.
Prueba de transacciones
Para la prueba mencionada se recomiendan los siguientes 9
pasos:
Identificar los recursos de prueba.
Identificar las condiciones de prueba.
Priorizar las condiciones.
Seleccionar las condiciones.
Determinar los resultados esperados.
Crear transacciones de prueba.
Documentar las condiciones de prueba.
Ejecutar la prueba
182 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Verificar y corregir.
Prueba de volumen
El objetivo de dicha prueba es verificar que el sistema
pueda realizar adecuadamente las transacciones cuando sus
programas internos o sus lmites se vean excedidos. Estas
pruebas suelen involucrar grandes volmenes de datos. Los
pasos que se recomiendan para esta prueba son:
Identificar las entradas del sistema.
Identificar las salidas del sistema.
Llevar cada dato a su mxima expresin tratando de
sobrepasar sus lmites.
Documentar las limitaciones.
Realizar la prueba de volumen.
Creacin de casos de prueba
Determinar el nivel de la prueba: Unitaria,
concurrencia, integracin, regresin o stress.
Desarrollar los casos de prueba: Un caso de prueba,
son todos los pasos que deben seguirse en el sistema
para probar dicho caso.
Ejecutar los casos de prueba: Usar el sistema con los
casos desarrollados en el punto anterior.
Analizar los resultados.
Mantener los casos de prueba.
F.3.2. Verificar la Ejecucin de la Prueba
Para lograr una prueba efectiva, se debe usar un plan de
pruebas creado previamente. Esta etapa es la culminacin de un
trabajo previo preparado para esta fase. Si esto no ocurre, la
prueba podra resultar poco efectiva y antieconmica.
Durante esta fase, el equipo de aseguramiento de la calidad,
llevar a cabo tanto la verificacin de los planes de prueba,
como la verificacin de la ejecucin de los mismos. Todo esto
se realizar, tomando muestras representativas de los planes y
sus respectivas ejecuciones.
Se verificar tambin, que los siguientes tipos de prueba
hayan sido llevados a cabo por el equipo de proyecto durante
esta fase:
Prueba manual, de regresin y funcional
La prueba manual asegura que las personas que interacten
con el sistema van a poder realizar las operaciones
propuestas; la prueba de regresin es la verificacin de que
lo que se est instalando no afecta a lo que ya estaba
instalado; y la prueba funcional apunta a que los
requerimientos del sistema puedan ser ejecutados
correctamente en diversas circunstancias.
Prueba de autorizacin
En esta prueba deben verificarse las reglas de
autorizaciones (permisos) para ejecutar las distintas
transacciones de la aplicacin.
Prueba de integridad
Debe ser verificada durante la prueba, los controles sobre la
integridad de los archivos de datos.
Prueba de pistas de auditoria
La funcin de pistas de auditoria, debe ser probada para
asegurarse que para cualquier transaccin, pueda
realizrsele un seguimiento desde su inicio hasta su fin,
para lograr una correcta reconstruccin de la misma cuando
sea necesario.
Prueba de recuperacin
Si el procesamiento debe continuar aunque el sistema no
est operativo, puede llegar a tener que provocarse fallas
intencionales en el sistema, para poder realizarse la prueba
de continuidad, la cual implica lo antedicho.
Prueba de stress
Es la prueba que asegura y cuantifica el nivel de servicio
del sistema ante grandes volmenes de datos.
Prueba de seguridad
En esta prueba lo que se intenta es violar todos los aspectos
de seguridad del sistema queriendo obtener como resultado
que ninguno de estos falle.
Prueba acorde a la metodologa
Todo tipo de prueba, deber ser llevado a cabo de acuerdo a
las polticas, estndares y procedimientos establecidos en la
metodologa de la organizacin. Esta ltima debera
especificar el plan de prueba requerido para cada tipo de
prueba, las tcnicas y herramientas de prueba
recomendadas, as como el tipo de documentacin
requerida a lo largo de la prueba misma. La metodologa
debera especificar el modo de determinar cundo una
prueba fue exitosa o no.
Prueba funcional
Esta prueba verifica el correcto cumplimiento de los
requerimientos del usuario.
Prueba de operacin
El xito de esta etapa depender fuertemente de la habilidad
de las personas que utilicen el sistema, adems es
importante que esta prueba se haga en un ambiente lo ms
parecido posible al de produccin.
Inspecciones
En esta prueba lo que se hace es evaluar el cdigo del
sistema para verificar ciertas reglas que lo harn fcil de
mantener ante supuestas modificaciones. Dichas reglas,
debern estar explicadas dentro de los estndares de la
organizacin.
Prueba de desastre
En esta prueba lo que se hace es provocar problemas en el
ambiente real de la aplicacin ya que es la nica manera de
ver realmente cmo se comporta el sistema ante situaciones
inesperadas.
Prueba funcional y de regresin
Esta fase de la prueba debe verificar la comunicacin con
los sistemas relacionados. Donde, la prueba funcional
verifica la interconexin de la nueva funcionalidad, y la
prueba de regresin verifica la continuidad del
funcionamiento del resto de los subsistemas asociados
preexistentes.
Prueba de performance
Los criterios de performance son establecidos durante la
fase de requerimientos e intentan ser medidos en la fase de
verificacin. De no poder realizarse porque el ambiente
necesario para llevarla a cabo sera muy costoso, se dejar
para ser medido en produccin.
Prueba de facilidad de operacin
Esta prueba generalmente es realizada por el equipo de
Operaciones que tratar normalmente con el sistema y se
intenta que el personal del grupo de proyecto no provea
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
ningn tipo de instrucciones a los usuarios, para que pueda
reproducirse el normal desarrollo de las transacciones, tal
como sera en el ambiente de produccin.
F.3.3. Verificar el Registro de los Resultados de la Prueba
Ya que documentar un problema, es el primer paso para la
correccin del mismo, es necesario llevar adelante una
verificacin del registro de los resultados de la prueba. Esto se
llevar a cabo, tomando muestras representativas de tales
resultados, para su anlisis posterior.
Se verificar que estn descriptos al menos, los siguientes
aspectos, para todos los problemas encontrados en las pruebas:
Declaracin del problema: Establecer cul es el problema.
Criterio: Establecer cmo debera comportarse el sistema.
Efecto: Es la diferencia entre el problema y el
comportamiento esperado.
Causa: Qu puede haber causado el problema?.
Para lograr una buena documentacin de los problemas, es
aconsejable seguir estos tres pasos:
Documentar el desvo: Esencialmente el usuario compara lo
que es con lo que debera ser, y cuando es identificada una
desviacin en este sentido, corresponde comenzar a
desarrollar la declaracin del problema.
Documentar el/ los efecto/s: Aqu debe evaluarse lo que el
problema significa para el sistema. La atencin que se le dar
al mismo, estar directamente relacionada con lo declarado
en el/ los efecto/s.
Documentar la o las causas: La o las causas son la o las
razones subyacentes para la condicin. En algunos casos la
causa puede ser obvia a travs de los hechos. Pero en otros,
puede ser necesaria una investigacin para encontrarla.
F.4. Salidas
Muestra de planes de prueba verificados.
Muestra de transacciones de prueba verificadas.
Muestra de resultados de la ejecucin de dichas transacciones
verificados.
Desvo de los resultados esperados documentados.
F.5. Lista de Verificacin (Checklist)
En la tabla VII se presenta la lista de verificacin:
TABLA VII. LISTA DE VERIFICACIN DEL MDULO DE VERIFICACIN
Respuesta Comentarios
# tem
SI NO N/A
Todos los pasos fueron realizados como se
1
especificaron?
Si los pasos no fueron realizados como se especificaron.
2 Se afectaron recursos adicionales para resolver
defectos durante la etapa de ejecucin?
Se estableci un ambiente de prueba apropiado para
3
realizar la prueba del software?
Se entren analistas de calidad en las herramientas de
4
verificacin que sern utilizadas durante esta etapa?
5 Se fij un tiempo adecuado para esta etapa?
6 Se fijaron los recursos adecuados para esta etapa?
7
Los mtodos para crear datos de prueba son
apropiados para el sistema?
8
Fueron creados los datos de prueba necesarios para
probar adecuadamente el software?
Fueron programadas todas las tcnicas de verificacin
9 indicadas en el plan de prueba para ser ejecutadas
durante este paso? (Ej. Prueba de regresin)
10
Fueron determinados los resultados esperados de las
pruebas?
11
Se ha establecido el proceso por el cual se determina
el desvo entre los resultados esperados y los actuales?
Se han documentado los resultados esperados y los
12
actuales cuando existe una diferencia entre ellos?
183
 Respuesta
# tem
SI NO
13
Se determin el potencial impacto de una desviacin?
(Ej. Problema en la verificacin)
14
Se ha establecido un procedimiento para asegurar las
acciones / resolucin apropiada de los defectos?
F.6. Mtricas
Eficiencia en la Cantidad de defectos detectados
deteccin de defectos: hasta verificacin
Cantidad total de defectos hasta
verificacin
Eficiencia en la Cantidad de defectos removidos
remocin de defectos: hasta verificacin
Cantidad total de defectos hasta
verificacin
Tasa de efectividad de Cantidad de tems
la verificacin: cubiertos
Cantidad total de tems
Antigedad media de Total de antigedad de defectos
defectos pendientes: pendientes al fin de un perodo
Cantidad total de defectos
pendientes al fin de un perodo
Antigedad media de Total de antigedad de defectos
defectos cerrados: cerrados al fin de un perodo
Cantidad total de defectos
cerrados al fin de un perodo
F.7. Involucrados
Comentarios
G.2. Entradas
N/A
Las entradas dependen del alcance asignado a la validacin
del sistema (prueba de aceptacin). Estas suelen ser:
Software probado: Una vez realizada la verificacin de las
piezas de software se comienza con la prueba de aceptacin.
Plan de Prueba de Aceptacin:
Pruebas en Lnea (On-Line).
Pruebas por Lotes (Batch).
Pruebas de Interfaces.
Pruebas de Integracin.
Pruebas de stress.
Pruebas de conectividad.
Pruebas de servidores.
Lista de defectos no resueltos: Quizs no sea prudente
esperar hasta que todos los defectos reportados sean
corregidos antes de empezar las pruebas de aceptacin. En
este caso, los encargados de efectuar las pruebas de
aceptacin reciben una lista no resuelta de defectos, la cual
les permitir conocer los procesos incorrectos y as enfocar la
atencin en los criterios principales de aceptacin antes de la
prueba.
G.3. Proceso
En la figura 11 se detalla grficamente, el proceso a
desarrollar durante este mdulo.
G.3.1. Verificar los Criterios de Aceptacin Definidos
El usuario deber definir el o los criterios que el software
deber cumplir para ser aceptado.

F.7.1. Equipo de Ingeniera

Gerente de proyecto.
Representante del grupo de anlisis de requerimientos.
Representante del grupo de anlisis funcional.
Representante del grupo de diseo.
Representante del grupo de analistas desarrolladores.
Grupo de testeo.
F.7.2. Equipo de Aseguramiento de la Calidad del Software
Lder de Aseguramiento de la Calidad del Software
Analistas de aseguramiento de la calidad del software Senior
y/o Semi-senior.
G. Validacin del Sistema

G.1. Objetivo
Describir los procedimientos para identificar los criterios de
aceptacin para el ciclo de vida de los productos y para
validarlos. La aceptacin final no solo tiene en cuenta que el
producto de software resuelva adecuadamente los
requerimientos de los usuarios, sino tambin, reconocer que el
proceso de desarrollo fue adecuado. Como parte del proceso de Fig. 11. Proceso del mdulo de validacin
ciclo de vida, la aceptacin del software permite:
Los requerimientos de aceptacin que el sistema debe
Deteccin temprana de los problemas del software. cumplir, pueden ser divididos en las siguientes cuatro
Preparacin apropiada de los medios para realizar la prueba. categoras:
Consideracin temprana de las necesidades del usuario Requerimientos Funcionales: Referido a las reglas de negocio
durante el desarrollo del software. que el sistema debe ejecutar.

184 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
 Requerimientos de Performance: Referido a los tiempos y Contenido Descripcin
recursos de operacin.
Uso normal esperado.
Requerimientos de Interfaz: Referido a la relacin humano /
Potenciales usos indebidos.
mquina, mquina / mdulo. Riesgos.
Requerimientos globales de Calidad del Software: Referidos Restricciones.
a la obtencin de los lmites para los factores o los atributos Estndares y Normas.
tales como la fiabilidad, comprobabilidad, exactitud, y Responsabilidades Organizacin y responsabilidades para las actividades de
usabilidad. del usuario aceptacin del sistema.
Estos criterios deberan estar enunciados y documentados Recursos y cronograma de requerimientos.
Requerimientos del recurso.
durante la fase de requerimientos, para ser refinados y
Requerimientos para soporte automatizado, datos
detallados en las fases siguientes. Se proceder a solicitar la especiales, y entrenamiento.
recopilacin de estos requerimientos, luego el equipo de Normas, estndares y convenciones.
aseguramiento de la calidad, proceder a verificarlos. Actualizacin y revisin de los planes de aceptacin.
Se debera determinar con el usuario, el grado de criticidad Procedimientos Informes de anomalas.
de los requerimientos para los tems cuyas categoras se administrativos Control de cambios.
presentan en la tabla VIII. Resguardo de informacin.
Descripcin de Objetivos para el proyecto.
G.3.2. Verificar el Desarrollo del Plan de Aceptacin aceptacin Resumen de criterios de aceptacin.
El primer paso para completar la aceptacin del software es Principales actividades de aceptacin y revisiones.
el desarrollo simultneo de un plan de aceptacin, un plan de Requerimientos de informacin.
Tipos de decisiones de aceptacin.
proyecto y de los requerimientos del software que aseguran que Responsabilidad de las decisiones de aceptacin.
las necesidades del usuario estn representadas correcta y
completamente. Este desarrollo simultneo proveer una visin G.3.3. Verificar la Ejecucin del Plan de Aceptacin
general que asegurar que todo los recursos necesarios, estarn El objetivo de este paso es, verificar el cumplimiento de los
incluidos en el plan de proyecto. criterios de aceptacin, en el producto entregado. Esto se puede
En la tabla IX se detallan los puntos a verificar dentro de un llevar a cabo a travs de revisiones, que involucran verificar
plan de aceptacin tpico. productos provisorios y entregables desarrollados parcialmente,
a lo largo del proceso de desarrollo.
TABLA VIII. TEMS DE REQUERIMIENTOS PARA DETERMINAR SU
CRITICIDAD El criterio de aceptacin del sistema, debera estar
especificado formalmente en el plan del proyecto. El plan
Categora tems identifica los productos a ser verificados, el criterio especfico
Funcionalidad Consistencia interna de documentos, cdigo, y entre de aprobacin/rechazo, las revisiones, y los tipos de
las fases. verificacin que se harn durante el ciclo de vida completo.
Trazabilidad (posibilidad de seguimiento) de la Las decisiones de aceptacin necesitan una estructura sobre
funcionalidad.
la cual operar, algunos componentes son: contratos, criterios de
Verificacin adecuada de la lgica.
aceptacin y mecanismos formales. La aceptacin del software
Preservacin de funcionalidad en el ambiente
productivo. deber referirse a un criterio especfico que los productos
Performance Anlisis de factibilidad de requerimientos de deben tener para ser aceptados. El principal medio para
performance. alcanzar la aceptacin en el desarrollo de los sistemas de
Herramientas de simulacin. software, es mantener una revisin peridica de la
Anlisis de desempeo en el ambiente productivo. documentacin y productos de software.
Interfaz Documentacin de la interfaz. Cuando la decisin de aceptacin requiere cambios, se hace
Complejidad de la interfaz. necesaria otra revisin para asegurarse de que los cambios
Planes de prueba e integracin de la interfaz.
solicitados hayan sido configurados e implementados en forma
Ergonoma de la interfaz.
Prueba de la interfaz en el ambiente productivo. correcta, y que el efecto en cualquier otra parte sea aceptable.
Calidad global del Cuantificacin de medidas de calidad. Las actividades de aceptacin, pueden incluir la
software Criterios para la aceptacin de los productos de verificacin de las piezas de software. La verificacin de
software. aceptacin del software, se vuelve formal, cuando durante el
Suficiencia de documentacin y normas de desarrollo ciclo de vida del desarrollo, el usuario acepta o rechaza el
de sistemas.
mismo. Esto es como un requerimiento contractual entre el
Criterios de Calidad para la Prueba Operacional.
usuario y el equipo del proyecto. El rechazo, generalmente,
TABLA IX. PUNTOS A VERIFICAR DENTRO DE UN PLAN DE ACEPTACIN significa que se deber realizar un trabajo adicional en el
TPICO sistema a fin de hacerlo aceptable para el usuario. La prueba de
aceptacin final, es la ltima oportunidad que tiene el usuario
Contenido Descripcin
para examinar la funcionalidad, interfaz, performance y
Descripcin del Tipo de sistema. aspectos de calidad antes de la revisin final de aceptacin. En
proyecto Ciclo de vida definido por la metodologa de la ese momento, el sistema deber incluir el software a entregar,
organizacin. toda la documentacin de usuario y las versiones finales de
Usuarios del sistema. otros entregables del sistema.
Principales tareas que debe satisfacer el sistema.
Principales interfaces externas del sistema.

Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico. 185
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
G.3.4. Revisar la Decisin de Aceptacin G.6. Mtricas
La aceptacin de un sistema generalmente significa que el Cantidad de defectos detectados
proyecto se ha completado, con la excepcin de alguna hasta validacin
Eficiencia en la
contingencia. Cantidad total de defectos hasta
deteccin de defectos:
Las decisiones de aceptacin pueden involucrar alguna de validacin
las siguientes situaciones:
Los cambios solicitados son aceptados antes de pasar a Eficiencia en la Cantidad de defectos removidos
desarrollar la prxima actividad. remocin de defectos: hasta validacin
Algunos cambios, deben ser aceptados y llevados a cabo Cantidad total de defectos hasta
antes de continuar con el desarrollo del producto, y otros, validacin
pueden ser postergados hasta la prxima revisin del
producto. Tasa de efectividad de Cantidad de tems cubiertos
la verificacin: Cantidad total de tems
El desarrollo puede continuar y los cambios podrn ser
aceptados en la prxima revisin.
Estabilidad de las Cantidad de criterios iniciales
No hay cambios solicitados y el desarrollo puede continuar.
criterios de aceptacin: Cantidad total de criterios
Cada una de estas situaciones, ser verificada por el equipo
de aseguramiento de la calidad, teniendo en cuenta los defectos
Estabilidad de la Cantidad de cambios durante la
no resueltos, el cronograma del proyecto, el estado actual del
aceptacin: aceptacin
mismo, los recursos involucrados, etc.
Cantidad total de cambios
G.4. Salidas G.7. Involucrados
Informe de la decisin de Aceptacin.
G.7.1. Equipo de Ingeniera
G.5. Lista de Verificacin (Checklist)
Gerente de proyecto.
En la tabla X se presenta la lista de verificacin. Representante del grupo de anlisis de requerimientos.
Representante del grupo de anlisis funcional.
TABLA X. LISTA DE VERIFICACIN DEL MDULO DE VALIDACIN Representante del grupo de diseo.
Representante del grupo de analistas desarrolladores.
Respuesta
# tem Comentarios Grupo de testeo.
Se incorpor la prueba de aceptacin al plan general de
SI NO N/A
Usuario final.
1
pruebas?
La prueba de aceptacin est enfocada como un G.7.2. Equipo de Aseguramiento de la Calidad del Software
2 proceso del proyecto en lugar de un paso aislado al final
del testing? Lder de Aseguramiento de la Calidad del Software
Fueron seleccionados los usuarios correctos para
3 determinar los criterios de aceptacin para el software y/o Analistas de aseguramiento de la calidad del software Senior
componentes de hardware?
El grupo que define los criterios de aceptacin, es y/o Semi-senior.
4
representativo de los usos del sistema a ser probado?
Esos individuos aceptan la responsabilidad de identificar
5
los criterios de aceptacin?
H. Instalacin
Los criterios de aceptacin fueron identificados
6 tempranamente como para lograr influir en el planteo e
implementacin de la solucin?
H.1. Objetivo
7 Se ha desarrollado y escrito el plan de aceptacin?
El plan de aceptacin es consistente con los criterios de
Realizar una verificacin completa de la fase de instalacin
8
aceptacin? para nuevos sistemas y/o cambio de versiones. La verificacin,
Se estn verificando los productos intermedios por parte
9 de los testeadores, antes de ser utilizados para la incluye, para cada criterio de instalacin identificado, una
siguiente tarea de implementacin? evaluacin recomendada y las tcnicas y herramientas
Se han seleccionado las tcnicas de prueba apropiadas
10
para el test de aceptacin? sugeridas para llevarla a cabo.
Los testeadores tienen el nivel de conocimiento
11
necesario para realizar dicha tarea?
Se afectaron los recursos necesarios para la realizacin H.2. Entradas
12
de la prueba de aceptacin?
Se destin el tiempo necesario para la realizacin de la Plan de instalacin.
13
prueba de aceptacin?
Se han publicado las opiniones internas de la prueba de
Diagrama de flujo de la Instalacin.
14
aceptacin?
Fue buena la reaccin del equipo del proyecto en lo que
Documentos y listados de instalacin (slo si es requerida
15
concierne a los testeadores en la prueba de aceptacin? una instalacin especial).
Se ha tomado la decisin final de aceptacin del
16
sistema? Resultados de la verificacin de instalaciones especiales.
17 Se han identificado los criterios de aceptacin crticos?
Los requerimientos fueron escritos con el detalle Documentacin de pasaje del sistema a produccin.
18 suficiente, de forma tal de poder obtener a partir de ellos
las interfaces? Instrucciones para los nuevos operadores.
Estn los responsables de cada interfaz, descritos en el
19
diagrama? Instrucciones y procedimientos para los nuevos usuarios.
Se ha definido un caso de prueba para cada uno de los
20
lmites que posee el sistema?
Resultado del proceso de instalacin.
Los usuarios del sistema estn de acuerdo con los
21
casos definidos? Los consideran completos? H.3. Proceso
Se definieron tanto las condiciones normales como las
22
fallidas a probar? En la figura 12 se detalla grficamente, el proceso a
Los usuarios estn de acuerdo con que los casos de
23
prueba cubren todos los probables escenarios? desarrollar durante este mdulo:

186 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642

Fig. 12. Proceso del mdulo de instalacin
H.3.1. Verificacin de la Instalacin de Nuevo Software
La fase de instalacin posee dos dificultades para el
equipo de aseguramiento de la calidad. La primera es que la
instalacin es un proceso separado del resto del desarrollo de la
aplicacin. Estas funciones no estn relacionadas con las
necesidades del usuario, pero s con las de instalar en
produccin una aplicacin completa y verificada. La segunda
dificultad es que la instalacin ocurre en un lapso de tiempo
muy corto. Es comn que la instalacin dure unas horas. Por lo
tanto la verificacin debe ser bien planeada y ejecutada.
Es importante que los resultados de la verificacin estn
disponibles antes de la instalacin completa del sistema. El
objetivo de la verificacin es determinar si la instalacin fue
exitosa, por lo tanto los resultados deben estar disponibles lo
antes posible. Esto significa que los resultados a obtener de la
verificacin deben estar explicitados antes de que la
verificacin comience. Los 15 factores a tener en cuenta en la
verificacin de la instalacin son:
Integridad y exactitud de la instalacin.
Prohibicin de modificacin de datos durante la instalacin.
Integridad de archivos de produccin.
Registro de pistas de auditora de instalacin.
Integridad del sistema/versin anterior asegurado
(continuidad de procesamiento).
Recuperacin ante fallas de la instalacin.
Control de acceso durante la instalacin.
Instalacin acorde a la metodologa.
Instalacin en produccin de los programas indicados en la
fecha asignada.
Puesta a disposicin de instrucciones de instalacin.
Documentacin completa (Mantenibilidad).
Documentacin completa (Portabilidad).
Interfaces.
Monitoreo de la performance.
Procedimientos operativos.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
H.3.2. Verificacin de la Instalacin de Cambios de Software
El objetivo principal es instalar el cambio requerido en el
tiempo adecuado. A continuacin se detallan los objetivos
especficos de la instalacin de cambios:
Poner a la aplicacin modificada en produccin.
Evaluar la eficiencia de los cambios.
Monitorear la exactitud de los cambios.
Mantener actualizadas con las ltimas versiones disponibles,
los ambientes de prueba y produccin.
Son tres las sub-tareas a verificar en la instalacin de
cambios de software.
a) Verificar si es adecuado el plan de recuperacin ante fallas
Existen varios aspectos de los cambios que impactan en el
proceso de recuperacin ante fallas:
Agregado de una nueva funcin.
Cambio en un JCL (Job Control Language).
Uso adicional de programas utilitarios.
Cambios en perodos de resguardo.
Cambios en los programas.
Introduccin de un formulario nuevo o revisado.
Los analistas de calidad deben evaluar el impacto en el
plan de recuperacin, cambio por cambio. Si determinan que el
cambio afecta a la recuperacin, se debe actualizar el plan.
b) Verificar que el cambio correcto, fue puesto en produccin
El pasaje de la modificacin, desde del ambiente de
prueba a produccin lo debe hacer el dueo del software,
previa aprobacin del usuario.
El ambiente de produccin debera ser capaz de controlar
los programas de acuerdo con la fecha de puesta en
produccin. Cada versin del programa en produccin debera
ser identificada (etiquetada) de acuerdo a si entra o sale de
produccin. Debe estar disponible para cada programa un
historial de los cambios, y as poder proveer pistas de auditora.
Para verificar que se introdujo el cambio correcto en
produccin se verificar lo siguiente:
Que los cambios en los programas hayan sido documentados:
El objetivo es contar con un historial, para proveer pistas de
auditora que indiquen cundo se ha realizado un cambio y
por otro impedir cambios no autorizados.
Que se cuente con un procedimiento para pasajes de
versiones del ambiente de prueba al ambiente de produccin.
El dueo del software decide cundo una versin va a ser
pasada a produccin. Esta aprobacin da la orden a
operaciones para dar aviso que el cambio va a ser instalado.
Que el procedimiento citado en el punto anterior se cumpla
c) Verificar que las versiones innecesarias hayan sido
eliminadas
Los programas con versiones innecesarias (viejas) deben
ser borrados. Esto solo puede hacerse con el debido nivel de
autorizacin. Se debe elaborar un formulario que autorice la
eliminacin de las versiones antiguas. Este formulario lo debe
completar el Gerente del proyecto de mantenimiento de
software y enviarlo al departamento de operaciones.
El departamento de Operaciones debe tener un proceso
para eliminar versiones innecesarias, despus de recibir la
debida autorizacin.
187
H.3.3. Seguimiento en Produccin Grupo de operaciones.
Los sistemas aplicativos son propensos a tener problemas H.7.2. Equipo de Aseguramiento de la Calidad del Software
inmediatamente despus de introducir una nueva versin. Por
eso es necesario monitorear las salidas del aplicativo, una vez Lder de Aseguramiento de la Calidad del Software
instalada la nueva versin en produccin.
El personal asignado al mantenimiento de software y el TABLA XI. LISTA DE VERIFICACIN DEL MDULO DE INSTALACIN
usuario debern proveer pistas, acerca de dnde ellos creen que
Respuesta
podran ocurrir problemas. El tipo de indicios incluye: # tem Comentarios

Investigacin de transacciones. SI NO N/A

Cada cambio es revisado para cada impacto sobre el plan de
Clientes. 1 reinicio/recuperacin?
Si el cambio impacta a la recuperacin, es calculado nuevamente el
Reportes. 2 tiempo de no servicio?
Archivos. 3
Si el cambio impacta a la recuperacin, es estimado nuevamente el
riesgo del tiempo de no servicio?
Performance. Los cambios necesarios para el proceso de recuperacin son
4 documentados?
Estos indicios deben ser documentados mediante el uso de La notificacin de los cambios de la versin de produccin fueron
5 documentados?
un formulario.
Los cambios de los sistemas de aplicacin de control de cambio de
6 aplicacin son controlados por una numeracin?
H.3.4. Documentar los Problemas Existen procedimientos para eliminar versiones antiguas de las
7 bibliotecas de objetos?
Los problemas detectados durante el monitoreo de los Existen solicitudes de eliminacin para que produccin sea autorizado
cambios, deben ser documentados. Adems se debe evaluar el 8 para eliminar programas?
Estn establecidos procedimientos para asegurar que la versin de los
riesgo asociado a ese problema. 9 programas sea pasada al ambiente de produccin en la fecha correcta?
El reporte de un problema causado por un cambio en el 10
Si esto afecta a procedimientos de operacin, Estn notificados los
operadores del da en que la nueva versin se pase a produccin?
sistema, permite asociar tal problema a lo especfico del Estn establecidos los procedimientos para monitorear los cambios de
11 los sistemas de aplicacin?
cambio. Este reporte debe ser enviado al analista de Las personas que monitorean reciben notificacin de que el sistema de
mantenimiento de software para su anlisis y posterior 12 aplicacin fue cambiado?
correccin. 13
Las personas que monitorean los cambios reciben indicios de las reas
consideradas impactadas por el probable problema?
Las personas que monitorean el cambio del sistema de aplicacin
H.4. Salidas 14 reciben una gua de que acciones tomar si el problema ocurre?
Los problemas detectados, inmediatamente despus de que el cambio
Reporte de recuperacin ante fallas. del sistema ocurri, son documentados en un formulario especial para
15 poder vincularlos a un cambio en particular?
Reporte de historia de cambios al software. Se solicita, a las personas que documentan problemas, que documenten
16 el impacto a nivel organizacional que puede implicar el problema?
Reporte de puestas en produccin. La informacin acerca de la instalacin de cambios de software es
Reporte de autorizacin de eliminacin de versiones 17 recopilada y documentada?
El servicio de la direccin realiza revisiones y utiliza la retroalimentacin
innecesarias. 18 de los datos?

Reporte de notificacin de monitoreo de cambios de 19

El servicio de la direccin peridicamente revisa la efectividad de la
instalacin de cambios de software?
software.
Reporte de problemas causados por cambios de Software.
Analistas de aseguramiento de la calidad del software Senior
H.5. Lista de Verificacin (Checklist) y/o Semi-senior.
En la tabla XI se presenta la lista de verificacin. I. Metodologa, Estndares y Procedimientos
H.6. Mtricas I.1. Objetivo
Cantidad de defectos detectados La verificacin de productos, deber ajustarse a la
hasta instalacin organizacin. Esto incluye ajustar el vocabulario y los trminos
Eficiencia en la
Cantidad total de defectos hasta utilizados en la verificacin para que sean los mismos que los
deteccin de defectos:
instalacin utilizados en la organizacin para describir los componentes
del sistema, documentos y productos.
Eficiencia en la Cantidad de defectos removidos
remocin de defectos: hasta instalacin I.2 Entradas
Cantidad total de defectos hasta Metodologa de desarrollo de la organizacin.
instalacin Estndares de la organizacin.
Procedimientos de la organizacin.
Tasa de efectividad de Cantidad de tems cubiertos
la verificacin: Productos que ingresan a cada una de las fases definidas en el
Cantidad total de tems
presente modelo.

H.7. Involucrados I.3 Proceso

En la figura 14 se detalla grficamente, el proceso a
H.7.1. Equipo de Ingeniera desarrollar durante este mdulo.
Gerente de proyecto.
Grupo de mantenimiento de software.
Grupo de instalacin de software.

188 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
I.3.1. Verificar el Cumplimiento de los Estndares de
Documentacin
La formalidad, extensin y nivel de detalle de la
documentacin a preparar dependern de las prcticas de la
organizacin y del tamao, complejidad y riesgo del proyecto.
Fig. 13. Proceso del mdulo de metodologa, estndares y procedimientos
Lo que es adecuado para un proyecto puede ser inadecuado
para otro. Para verificar la documentacin, se proceder a
comprobar si est completa, es adecuada y cumple con las
normas y estndares corporativos.
Esta tarea intenta evaluar el apego a los procedimientos y
estndares definidos por la metodologa de la organizacin,
evaluando los criterios as establecidos y determinando si el
nivel y el alcance de la documentacin cumplen con lo
requerido.
En el caso que la metodologa de la organizacin,
establezca pautadamente la documentacin necesaria para cada
tipo de proyecto segn su criticidad, se proceder a verificar si
la documentacin cumple con cada una de esas pautas.
I.3.2. Verificar la Integridad de la Documentacin
Para evaluar la integridad de la documentacin, se usarn
los criterios definidos al respecto, en la metodologa de la
organizacin. El equipo de aseguramiento de la calidad de
software deber determinar si cada documento cumple con
esos criterios. Si la documentacin no alcanza a cubrir un
criterio, deber identificarse la deficiencia y documentarse.
Otros criterios adicionales, que pueden ser utilizados para
evaluar la integridad de cada documento, son discutidos en el
captulo de Tcnicas y Herramientas, nombrndose a
continuacin cada uno de ellos:
Contenido de la documentacin.
Usuarios del documento.
Redundancia.
Flexibilidad.
Tamao del documento.
Combinacin de diferentes tipos de documentos.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Formato.
Secuencia de contenido.
Ttulos de secciones/prrafos.
Expansin de los prrafos.
Diagramas de flujo y tablas de decisin.
Formularios.
Es aconsejable llevar a cabo una o ms verificaciones de
adecuacin de la documentacin a los estndares de la
organizacin. Tales verificaciones requieren que una persona
capaz, no asociada al proyecto, haga una simulacin de cambio
al sistema basado en la documentacin actual y el
requerimiento de cambio (no deben cambiarse ni la
documentacin real ni los programas). Despus que la persona
haga el cambio, alguien familiarizado con el proyecto debe
evaluar si se ha hecho correctamente. Esta verificacin revelar
si:
La documentacin es entendible para las personas ajenas al
proyecto
Una persona ajena puede utilizar la documentacin para
hacer un cambio correctamente, y lo puede hacer de manera
eficiente y efectiva.
I.3.3. Verificar el grado de actualizacin de la
Documentacin
La documentacin que no est actualizada no ser til. Si
la metodologa de la organizacin ya establece algn mtodo
para verificar el grado de actualizacin de la documentacin,
dicho mtodo ser usado por el grupo de verificacin durante la
misma. Caso contrario, se propone que el equipo de
verificacin de la documentacin utilice cualesquiera de las
siguientes cuatro tcnicas de verificacin (que se detallarn se
detallan en el captulo de Tcnicas y Herramientas) para
validar la actualizacin de la documentacin:
Utilizar la documentacin existente para llevar a cabo un
cambio en la aplicacin
Comparar el cdigo fuente de los programas con la
documentacin
Verificar que la documentacin est vigente
Verificar la actualizacin de los documentos con el usuario
final
Las anteriores tcnicas podrn aplicarse sobre los
documentos completos o sobre partes de los mismos o sobre
una muestra de la documentacin del proyecto.
I.4. Salidas
Reporte de documentacin verificada
I.5 Lista de Verificacin (Checklist)
En la tabla XII se presenta la lista de verificacin.
I.6. Mtricas
Cantidad de documentacin
vigente no actualizada
Documentacin
Cantidad total de documentacin
vigente:
vigente
Revisin de Cantidad de documentos
documentos: revisados
Cantidad de documentos a
revisar
189
I.7. Involucrados
I.7.1. Equipo de Ingeniera
Gerente de proyecto
Responsables de elaboracin de documentos
Grupo de Metodologa, Estndares y Procedimientos
TABLA XII. LISTA DE VERIFICACIN DEL MDULO DE METODOLOGA,
ESTNDARES Y PROCEDIMIENTOS
# tem
Respuesta
SI
1 Existen estndares para la documentacin del sistema?
Los miembros del equipo de prueba estn informados sobre las
2 intenciones y contenidos de esos estndares?
Los estndares son adaptables a sistemas de varios tamaos, de
manera que el tamao del proyecto no sea directamente proporcional con
3 al tamao del documento?
Se les entreg al equipo de aseguramiento de la calidad una copia
completa de la documentacin del sistema correspondiente a esta
4 verificacin?
El equipo de aseguramiento de la Calidad ha medido las necesidades de
la documentacin de acuerdo a los criterios establecidos por la
5 metodologa de la organizacin?
El equipo de aseguramiento de la calidad ha determinado qu
6 documentos deben revisarse?
Las personas del proyecto estn de acuerdo con las sugerencias del
equipo de aseguramiento de la calidad en cuanto a las revisiones de la
7 documentacin?
El equipo de aseguramiento de la calidad determin la completitud de los
documentos usando los criterios detallados en la metodologa de la
8 organizacin?
El equipo de aseguramiento de la calidad ha utilizado el proceso de
Inspeccin para determinar la completitud de la documentacin del
9 sistema?
El equipo de Aseguramiento de la Calidad de Software ha determinado
10 el grado de actualizacin de la documentacin del proyecto?
El equipo de aseguramiento de la calidad ha desarrollado un documento
11
detallando las deficiencias de la documentacin respecto de los
estndares de la organizacin?
Se ha asegurado el equipo de aseguramiento de la calidad de que las
12 deficiencias descritas estn documentadas?
I.7.2. Equipo de Aseguramiento de la Calidad del Software
Lder de Aseguramiento de la Calidad del Software
Analistas de aseguramiento de la calidad del software Senior
y/o Semi-senior.
V. TCNICAS Y HERRAMIENTAS
En el presente captulo se presentan y describen
brevemente las principales Tcnicas y Herramientas
identificadas en los mdulos del modelo general de
aseguramiento de la calidad.
Tambin se presenta, slo a modo de ejemplo, un conjunto
de productos entregables que se obtienen al aplicar stas
tcnicas y herramientas. Lo que se pretende mostrar con estos
productos, son los datos que se deberan registrar, ms all del
formato, el soporte electrnico o detalles de implementacin.
A. Estimacin del Proyecto
A.1. Verificar la Validez de la Estimacin de los Costos de
Software
Una estimacin inapropiada de costos puede daar ms a la
calidad del Proyecto de Software que a cualquier otro factor,
por eso, la verificacin puede aumentar la validez de la
estimacin. La estimacin del software es un proceso de tres
partes como se describe a continuacin:
Validar el modelo de estimacin.
Validar que el modelo incluya todos los factores necesarios.
190 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Verificar la efectividad del modelo de estimacin de costos.
A.1.1. Validar el Modelo de Estimacin
La organizacin necesita usar un modelo para realizar las
estimaciones. El objetivo de este punto es validar la sensatez
del modelo de estimacin. Esta verificacin deber desafiar el
modelo usando las siguientes 14 caractersticas deseables para
la estimacin de costos.
Estas caractersticas buscan determinar los puntos dbiles
del modelo:
El alcance del modelo debe estar bien definido.
Comentarios El modelo debera ser ampliamente aplicado.
NO N/A El modelo debe ser fcil de usar.
El modelo debe ser capaz de usar informacin actual, cuando
est disponible.
El modelo debe permitir el uso de datos histricos y
ajustarlos para una organizacin en particular y un tipo de
software.
El modelo debe ser verificado contra un nmero histrico
razonable de proyectos.
El modelo debe requerir slo entradas basadas en las
propiedades del proyecto, las cuales estn bien definidas y
pueden ser establecidas con un grado de certeza razonable al
momento en que la estimacin es llevada a cabo.
El modelo debe proveer entradas basadas en criterios
objetivos.
El modelo no debe ser hipersensible para criterios de entrada
subjetivos.
El modelo debe ser sensible a todos los parmetros del
proyecto que fueron establecidos teniendo un marcado efecto
en el costo y no debe requerir entrada de parmetros no
correlacionados con costos.
El modelo debe incluir estimaciones de cmo y cundo van a
ser necesarios los recursos.
El modelo debe producir un rango de valores por la cantidad
que ha sido estimada.
El modelo debe incluir la posibilidad de realizar anlisis de
sensibilidad, para que el responsable de la estimacin pueda
ver la variacin de los parmetros seleccionados.
El modelo debe incluir alguna estimacin del riesgo para
completar las estimaciones de tiempo o costo.
A.1.2. Validar que el Modelo Incluya Todos los Factores
Necesarios
Los factores que influencian al costo del proyecto de
software deben estar divididos en los que contribuyen en el
desarrollo y mantenimiento de la organizacin y en aquellos
inherentes al proyecto de software.
Es importante que los modelos sean usados correctamente y
que todos los factores que influencian los costos de software
sean imputados correctamente. Los modelos pueden producir
resultados incorrectos basados en esa influencia de factores. En
primer lugar el factor puede ser excluido del modelo como
resultado de una incorrecta estimacin. En segundo lugar se
puede introducir un factor incorrecto o incompleto al modelo,
causando estimaciones incorrectas de costos de software.
Si un factor no fue incluido, el analista de calidad debe
determinar dnde afecta el factor significativamente en el costo
actual de construir el software. A continuacin se describen los
factores influyentes en el costo del software:
 Tamao del software.
Porcentaje de diseo y/o cdigo nuevo.
Complejidad del sistema de software.
Dificultad de diseo y codificacin.
Calidad.
Lenguajes a usar.
Clasificacin de nivel de seguridad del proyecto.
Tipo de mquina a utilizar (tecnologa).
Utilizacin de hardware.
Volatilidad del requerimiento
A continuacin se describen los factores influyentes, que
dependen de la organizacin:
Cronograma del proyecto.
Personal.
Ambiente de desarrollo.
Recursos no atribuibles directamente a aspectos tcnicos del
proyecto.
Recursos de computacin.
Honorarios.
Inflacin.
A.1.3. Verificar la Exactitud del Modelo de Estimacin de
Costos
Se proponen las siguientes cuatro verificaciones para
validar las estimaciones producidas por el modelo de
estimacin de costos de software:
1) Recalcular lo estimado: El analista de calidad puede
validar el proceso de estimacin ejecutando el modelo de
estimacin. El propsito de esto es:
Validar que los datos de entrada fueron ingresados
correctamente.
Validar que los datos de entrada fueron razonables.
Validar que la ecuacin matemtica fue calculada
correctamente.
2) Comparar estimaciones realizadas con proyectos
tpicos: El analista de calidad puede determinar cunto tiempo
lleva desarrollar proyectos del mismo tamao y complejidad.
El clculo realizado por el sistema de estimacin, es luego
comparado con costos actuales de proyectos tpicos. Si
existiera una diferencia el analista de calidad puede evaluar
ms en detalle, la validacin de la estimacin.
3) Razonabilidad de la estimacin: Esta verificacin es
similar a la del punto anterior, se utiliza la experiencia pasada.
El analista de calidad documenta los factores que influyen
sobre la estimacin de costos, documenta el clculo producido
por el sistema de estimacin y luego valida la razonabilidad de
esa estimacin teniendo en cuenta experiencias anteriores. Es
recomendable un mnimo de tres experiencias consultadas a los
Gerentes de proyecto. En caso en que uno o ms no sienta que
es razonable la estimacin, la misma deber ser rechazada.
4) Redundancia en estimaciones de costo de software: El
Analista de calidad debe recalcular la estimacin usando otro
modelo de estimacin de costo. Si la diferencia es pequea, la
estimacin ser confiable. Caso contrario se tendra que
realizar una investigacin adicional.
A continuacin, se detallan las fuentes de los modelos de
estimacin de software:
Desarrollos internos (propios) de la organizacin.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Modelos de estimacin incluidos en metodologas de
desarrollo de sistemas.
Paquetes de software para desarrollo de estimaciones de
software.
Uso de puntos de funcin para la estimacin de costos de
software
B. Estado del Proyecto: Sistema de Acumulacin de Puntos
La creciente complejidad de los sistemas, combinado con los
requerimientos para diseos estructurados y modulares, ha
aumentado la cantidad de elementos de software desarrollados
y entregados. El aumento de elementos, ms los tradicionales
hitos usados para medir el progreso han hecho subjetivo y a
menudo poco confiable el seguimiento del desarrollo del
software y la prediccin del consumo progresivo del tiempo.
Se ha utilizado exitosamente un sistema para seguir el
progreso del desarrollo de software a travs de un esquema de
puntos ganados. Los puntos estn asignados en cada paso en el
ciclo de desarrollo del software de la organizacin. Los pasos
son hitos en los cuales un producto generado es aceptado. Al
aceptar los productos se ganan los puntos que poseen
asociados. La proporcin de puntos ganados sobre el total de
puntos posibles se recopila y as se determina el progreso
logrado. Luego, se generan informes, tabulando la
informacin en una variedad de reportes gerenciales.
El sistema as implementado es flexible y altamente
automatizado. Los puntos acumulados son rpidamente
verificados, objetivos, y basados en el estado actual del
desarrollo del proyecto. Clculos simples o comparaciones de
los puntos acumulados proveen una medida precisa del
progreso, del desvo en el cronograma y la prediccin de
progresos futuros.
B.1. Cmo Utilizar el Sistema de Puntos
El sistema de acumulacin de puntos, propuesto por W. Perry
[5], es una extensin del sistema de "hitos". En su forma ms
simple se asume que cada tem o componente del software
pasa por procesos de desarrollo similares y hay una cantidad
de hitos claramente identificables dentro del proceso.
A modo de ilustracin, se desarrollarn 5 componentes y 4
hitos definirn el proceso de desarrollo. Los hitos pueden
representar diseos revisados y aceptados, cdigo revisado y
completo, resultados de prueba verificados, y componentes
liberados. En un caso simple, cada hito para cada tem de
software vale 1 punto. En este caso, pueden ganarse 20
puntos. Como parte de cada revisin de diseo, inspeccin de
cdigo, prueba de verificacin, o entrega, se cumple el hito y
se ganan los puntos correspondientes. Al poner en un archivo
una lista con los componentes e hitos logrados (puntos
ganados) y crear simples generadores de reportes, puede
adquirirse una medida objetiva, precisa y oportuna de los
resultados. En la tabla XIII se muestra cmo es un reporte
simple de estado.
Este esquema simplificado funciona bien para un conjunto
homogneo de componentes donde todos tienen similar
complejidad y cada hito representa una cantidad de trabajo
similar. A travs de la introduccin de "pesos" en los factores,
pueden manejarse fcilmente, los componentes de
complejidad diversa o los hitos que representan esfuerzos
dismiles para completarlos.
191
 TABLA XIII. REPORTE SIMPLE DE ESTADO
REPORTE DEL ESTADO DEL SISTEMA
TEM DISEO CODIFICACIN VERIFICACIN ENTREGA
Componente A 1 1
Componente B 1 1
Componente C 1 1
Componente D 1 1 1 3
Componente E 1 1
TOTALES 5 3 1 0
PORCENTAJE 9/20 = 45= %
El motor del sistema es un archivo de datos y algunos reportes
simples. El archivo de datos es simplemente una coleccin de
registros, uno por cada tem que debe seguirse, que contiene
campos para indicar si se ha alcanzado algn hito. Usualmente
es ventajoso incluir campos para la descripcin de los tems,
analista responsable, identificacin del trabajo, entre otros.
El mantenimiento o actualizacin del archivo puede ser tan
efectivo como modificar registros con un editor de lnea o tan
complejo como crear un programa interactivo para ese
propsito. Deben usarse algunos medios de acceso limitado
para restringir modificaciones no autorizadas al archivo. Una
vez actualizado el mismo, para incluir una entrada de datos al
componente en desarrollo se actualizan los campos de estado
de los hitos a medida que se van alcanzando tales hitos. En
algunos casos, esto puede ser un proceso manual; una vez que
el evento ocurri y se alcanz el hito, una persona (autorizada)
actualiza el estado en el archivo. En otras circunstancias, en
sistemas ms sofisticados, un programa puede determinar que
ha ocurrido un hito (compilacin sin errores o prueba exitosa)
y automticamente actualiza el estado del hito.
Una vez armado el archivo, se escriben los programas
generadores de reportes para imprimir el estado. Para
proyectos menores, puede ser suficiente un programa que
simplemente imprime cada registro, suma los puntos ganados
y definidos, y calcula el porcentaje de puntos ganados. Los
proyectos ms grandes pueden necesitar varios reportes para
subsistemas diferentes o reportes resumen que enfaticen los
cambios ocurridos.
B.2. Utilizacin del Sistema de Puntos como Mtodo de
Prueba
El mtodo de puntos para seguir el progreso del software
puede ser utilizado por el Analista de calidad en alguna de las
tres formas siguientes:
B.2.1. Validar el Progreso Informado.
El uso del sistema de puntos por el equipo de aseguramiento
de la calidad, elabora una evaluacin del progreso que puede
compararse con los reportes de progreso del Gerente del
proyecto. Si el seguimiento del progreso es aproximadamente
el mismo utilizando los dos resultados, el examinador puede
validar el sentido de los reportes del proyecto producidos por
el equipo del proyecto. Esto es un anexo de lo que la prueba
normalmente hace, pero puede ser muy valiosa desde la
perspectiva de la alta gerencia. Ntese que si hay una
diferencia significativa en la estimacin del progreso del
proyecto, la diferencia puede estar en el sistema de puntos o
en el sistema que usa el Gerente del proyecto. El objetivo de
192 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
hacer ambas estimaciones es proveer al Gerente del proyecto y
a la alta gerencia de mayor seguridad respecto de la validez de
los resultados del reporte de progreso.
PUNTOS GANADOS B.2.2. Planeamiento de la Prueba
2 El mtodo de puntos para el seguimiento del progreso indica
cundo ocurrir la prueba. Al tener un sistema que permita al
equipo de proyecto, seguir el progreso, puede asistirlo para
planificar el uso de los recursos de prueba. El sistema de
puntos no requiere muchos recursos; no obstante est
2
destinado a asistir al equipo de proyecto, indicndole cuando
los programas/subsistemas estarn disponibles para verificar.
9
B.2.3. Reportar el Estado de la Prueba
El sistema de puntos tambin indica cundo est hecha la
prueba y cuando se liberan los mdulos a produccin. La
informacin contenida en el sistema de puntos es la misma
que necesitar el equipo de proyecto para reportar los
resultados de la prueba.
C. Matriz de Riesgos
La matriz de riesgos es una herramienta diseada para
identificar y evaluar riesgos y determinar qu es lo que el
sistema debe hacer con cada uno de ellos.
A continuacin se describe como usar la matriz de riesgos. En
forma ideal la matriz de riesgos comienza en la fase de
requerimientos y se desarrolla y termina en la fase de diseo.
La implementacin de esta herramienta es un proceso de cinco
pasos. Los pasos deben ser ejecutados en la siguiente
secuencia:
C.1 Identificacin del Equipo de Evaluacin de Riesgos
La clave para el xito de la matriz de riesgos es establecer un
equipo evaluador de riesgos, cuya responsabilidad ser
completar la matriz. El objetivo de completar la matriz, es
llevar a cabo un control adecuado de requerimientos y diseo
para reducir los riesgos a un nivel mnimo aceptable.
El grupo de riesgo, puede ser parte del equipo que realiza la
toma de requerimientos o parte del grupo de test, o puede ser
un equipo seleccionado especficamente con el propsito de
confeccionar la matriz de riesgo. El grupo debera contar con
entre 3 y 6 miembros, y al menos poseer las siguientes
habilidades:
Conocimiento sobre el uso de la aplicacin.
Entender el concepto de riesgo.
Habilidad para identificar controles.
Estar familiarizado con ambos, riesgos de la aplicacin y de
los servicios de informacin.
Entender el concepto de servicio de informacin y sistema de
diseo.
Los candidatos en el grupo de riesgo debern al menos incluir
a alguien del rea usuaria, y alguno o todos de las siguientes
reas:
Auditor interno.
Consultor de riesgo.
Representante del rea de procesamiento de datos.
Representante del rea de seguridad.
Representante del rea de operaciones.
C.2. Identificacin de Riesgos
El primer objetivo del grupo evaluador de riesgos, es
identificar los riesgos enfocndose en la aplicacin, pero no en
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
los riesgos ambientales. El equipo evaluador de riesgo, puede
utilizar uno de los dos mtodos siguientes para la
identificacin del riesgo:
C.2.1. Anlisis de Escenarios de Riesgos
En este mtodo el equipo de riesgo delibera sobre los riegos
potenciales de la aplicacin usando sus experiencias, juicio y
conocimiento del rea de aplicacin. Es importante tener
sinergia, as los miembros del grupo pueden cuestionarse uno
a otro para desarrollar una lista completa de riesgos que son
compatibles a la aplicacin.
C.2.2. Lista de Verificacin de Riesgos
Se provee al equipo de riesgo de una lista con los riesgos ms
comunes que ocurren en aplicaciones automticas. El equipo
selecciona de la lista aquellos riesgos aplicables a la
aplicacin. En este mtodo, el equipo necesita pocas
habilidades porque la lista de riesgos provee el estmulo para
el proceso, y el objetivo del equipo es determinar cuales de los
riesgos de la lista son aplicables a la aplicacin. He aqu una
lista de riesgos para su identificacin:
Acceso no controlado al sistema.
Prcticas de seguridad no eficaces para la aplicacin.
Errores de procedimiento en los servicios de informacin:
Procedimientos y controles.
Manipulacin de medios de almacenamiento.
Errores del programa.
Defectos del sistema operativo.
Fallas en el Sistema de Comunicacin:
Fallas accidentales.
Actas accidentales.
C.3. Establecer Objetivos de Control
Durante la fase de requerimientos, deben establecerse los
objetivos de control para cada riesgo. Estos objetivos definen
el nivel de aceptacin del perjuicio de cada riesgo
identificado. Otra forma de manifestar el nivel de dao
aceptable, es el objetivo mensurable de control.
La adecuacin del control no puede chequearse hasta que no
est definido el nivel de perjuicio de cada riesgo. Por lo tanto,
mientras que la definicin de los objetivos de control es
responsabilidad del usuario y del proyecto, puede llevar a la
formacin de un grupo de riesgos para definirlos. Una vez
definidos los objetivos de control, se pueden chequear los
requerimientos para determinar si son factibles.
En la tabla XIV se muestra un ejemplo de matriz de riesgo al
final de la fase de requerimientos para un tpico sistema de
Facturacin y Distribucin. Esta matriz muestra cuatro riesgos
para el sistema de Facturacin y Distribucin, y objetivos de
control para cada uno de aquellos riesgos. Por ejemplo, uno de
los riesgos es que el producto sea enviado pero no facturado.
En esta instancia, el objetivo de control es asegurar que todos
los envos sean facturados. En otras palabras, el nivel de
perjuicio aceptable de este riesgo es cero, y el equipo del
proyecto debe instalar un sistema que asegure que para cada
envo que se despacha se prepara una factura. Sin embargo,
ntese que el siguiente riesgo es que el producto se facturar
con un precio o cantidad errnea y que los controles tienen
establecido un nivel de defecto mayor a cero, como los otros
dos riesgos.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
C.4. Identificar Controles en Cada Sistema
Durante la fase de diseo, el equipo de riesgo identificar los
controles en cada fase del sistema de aplicacin para cada
riesgo identificado. Los segmentos de sistemas ms comunes
son:
Origen: La creacin del documento fuente ms la
autorizacin asociada con aquella transaccin original.
TABLA XIV. EJEMPLO DE MATRIZ DE RIESGO AL FINAL DE LA
FASE DE REQUERIMIENTOS
RIESGO OBJETIVOS DE CONTROL
Despachado pero no facturado Asegurar que todos los envos estn facturados
Facturado con precio o cantidad Facturar al precio actual el 99% de los tems bsicos y error permitido
errnea menor al 10%
Facturado al cliente equivocado Reducir facturas perdidas a menos del 1%
Despacho del producto o cantidad Despachar los productos y cantidades correctas al 99% de los tems de
equivocada base
Ingreso de Datos: Transferencia de informacin a un medio
legible por la mquina.
Comunicacin: El movimiento de datos desde un punto del
sistema a otro. El movimiento puede ser manual o
electrnico.
Procesamiento: Aplicacin del sistema lgico a los datos.
Almacenamiento: La retencin de datos, por largos o cortos
perodos de tiempo.
Salida: La traduccin de la informacin de computadora a los
medios entendibles y utilizables.
Uso: Satisfaccin de la necesidad del negocio a travs de los
resultados del sistema de procesamiento.
El equipo de evaluacin de riesgos, determinar qu controles
son aplicables a qu riesgos y los registrar en el segmento
correcto del sistema. Al trmino del desarrollo de la matriz de
riesgo, el equipo de riesgo har una estimacin para verificar
si los controles son los adecuados para reducir el riesgo hasta
el nivel de aceptacin identificado en el objetivo de control.
Esto verificar la efectividad de los controles al finalizar el
proceso de diseo. En la tabla XV se muestra un ejemplo de
matriz de riesgo para sistemas de facturacin y distribucin al
final de la fase de diseo.
Los mismos cuatro riesgos identificados durante la fase de
Requerimientos (tabla XIV) tambin se muestran en esta
matriz, por lo que los controles estn asociados a cada riesgo.
En este ejemplo, el riesgo de despachar sin facturar muestra
que los controles 1, 2 y 3 ayudarn a disminuir ese riesgo
(para una matriz real estos controles deben describirse). La
matriz muestra en qu segmento del sistema de aplicacin
residen aquellos controles.
Despus de identificar y registrar los controles, el equipo de
riesgo debe determinar si aquellos tres controles y los
segmentos a los cuales pertenecen son los adecuados para
reducir el riesgo de despachar sin facturar.
C.5. Determinar si los Controles son adecuados
La verificacin termina cuando el equipo de riesgo determina
si los controles son los adecuados para reducir cada uno de los
riesgos identificados al nivel aceptable.
193
 TABLA XV. EJEMPLO DE MATRIZ DE RIESGO AL FINAL DE LA
FASE DE DISEO
RIESGO DEL SEGMENTO INGRESO
ORIGEN COMUNIC. PROCES.
DEL SISTEMA DATOS
Despacho sin facturacin #1 #2
#7
Facturado con precio o
calidad errnea
#6 #8
#9
Facturado al cliente #12
equivocado #3
Despacho de producto o
#17 #18
#19
cantidad errnea #20
D. Anlisis de Factores (Mdulo de Requerimientos)
Se llevar a cabo un proceso para estimar las incumbencias
asociadas a la fase de requerimientos del desarrollo del
sistema. Debe incluirse un programa de verificacin para cada
tem. Hay 15 tems a considerar, cubriendo cada fase del
proceso de desarrollo. Para cada tem hay un programa de
verificacin que tiene en cuenta ciertas consideraciones las
cuales se encuentran detalladas ms abajo. El programa de
verificacin enumera aquellos criterios, que aseguran al
equipo de aseguramiento de la calidad, que la magnitud de esa
preocupacin es mnima. A estos criterios debe responder el
equipo de aseguramiento de la calidad. Tambin se debe
realizar una verificacin suficiente para evaluar si el equipo de
proyecto ha manejado adecuadamente cada factor de
verificacin.
A continuacin, se detallarn brevemente cada uno de los
factores a tener en cuenta:
D.1. Requerimientos Compatibles con la Metodologa
(Factor: Metodologa)
El procedimiento utilizado para definir y documentar
requerimientos, debe estar presente durante la fase de
requerimientos. Cuanto ms formales sean estos
procedimientos, se facilita el proceso de su verificacin. El
proceso de requerimientos es un proceso de, anlisis, toma de
decisiones y registro de requerimientos en una forma
predefinida para poder utilizarse luego en el diseo.
D.2. Funcionalidad de las Especificaciones (Factor:
Precisin)
La satisfaccin del usuario solo puede asegurarse, cuando se
han cumplido los objetivos del sistema. El cumplimiento de
estos objetivos solo pueden medirse cuando stos sean
mensurables. Por ejemplo, los objetivos cualitativos, como la
mejora de servicio, no son mensurables, mientras que s lo es
el pedido de procesamiento en cuatro horas de usuario.
D.3. Usabilidad de las Especificaciones (Factor: Facilidad de
Uso)
La cantidad de esfuerzo requerido para usar el sistema y la
habilidad necesaria, deben definirse durante la fase de
requerimientos. La experiencia muestra que las aplicaciones
difciles de usar finalmente no se utilizan, en cambio los
sistemas funcionales fciles de usar son altamente utilizados.
Entonces los desarrolladores, debern crear especificaciones
fciles de usar, incrementando as la facilidad del uso del
sistema en s mismo.
D.4. Mantenimiento de las Especificaciones (Factor:
Mantenibilidad)
Debe definirse el grado de mantenimiento esperado, as como
tambin las reas donde los cambios son muy probables. Las
194 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
especificaciones determinarn los mtodos de mantenimiento
(Ej.: cambio de parmetros introducido por el usuario) y el
intervalo de tiempo en el cual se necesitan implementar dichos
ALMAC. SALIDA USO
cambios.
#6
D.5. Necesidades de Portabilidad (Factor: Portabilidad)
#10 #11 La capacidad para operar el sistema en diferentes tipos de
hardware, o migrarlo a otra versin, deber enunciarse como
#14 #15 #16 parte del requerimiento. La necesidad de tener la aplicacin
#21 #22
desarrollada como portable, puede afectar significativamente
la implementacin de requerimientos.
D.6. Interfaces del Sistema (Factor: Acoplamiento)
Se debe definir en forma precisa, la informacin esperada
como entrada desde otros sistemas computadorizados y las
salidas a entregar a otros sistemas. Esta definicin no solo
incluye los tipos de informacin intercambiada, sino tambin,
el momento en el cual debe estar disponible cada interfaz y el
procesamiento que se espera como resultado de cada una de
ellas. Otros factores a tener en cuenta al definir las interfaces
son: privacidad, seguridad y resguardo de la informacin.
D.7. Criterios de Performance (Factor: Performance)
Debe quedar establecido: la eficacia, economa y eficiencia
esperadas del sistema. Estos objetivos son una parte integral
del proceso de diseo. Cuando no son alcanzados, la
insatisfaccin del usuario est garantizada. Como producto
final de la fase de requerimientos, se realizar el anlisis del
costo-beneficio del factor performance, calculado para la
aplicacin.
D.8. Necesidades operativas (Factor: Facilidad de
Operacin)
Las consideraciones operativas deben definirse durante la fase
de requerimientos. Esto es especialmente importante en
sistemas de aplicacin manejados por el usuario. Los procesos
a seguir para operar el sistema, en otras palabras, los
procedimientos necesarios para procesar transacciones, deben
ser lo ms simple posible. Tambin deben considerarse
procedimientos de operacin por excepcin y monitoreo
centralizado.
D.9. Tolerancia (Factor: Fiabilidad)
Debe definirse la confiabilidad esperada de los controles del
sistema. Por ejemplo, la fase de requerimientos determinar
los requerimientos de control para la precisin de la
facturacin, el porcentaje de rdenes que necesitan procesarse
dentro de las 24 horas, etc.
La tolerancia de facturacin puede afirmar que se procesarn
las facturas con tolerancia 1% de los precios de los
productos actuales.
Si no se establecen estas tolerancias, no hay base para asignar
y medir la confiabilidad del sistema por perodo de tiempo. Si
no se define el nivel de defectos esperados, normalmente se
espera cero defectos. Los controles para lograr cero defectos
son antieconmicos.
Usualmente es ms econmico, que surja una cantidad mnima
de defectos en el proceso pero que sean detectados y
mensurables.
D.10. Reglas de Autorizacin Definidas (Factor:
Autorizacin)
Deben especificarse los mtodos de autorizacin (niveles de
seguridad) para asegurar que las transacciones se procesen de
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
acuerdo con la intencin que tiene la organizacin, respecto
del sistema.
D.11. Requerimientos de Integridad de Archivos (Factor:
Integridad de Archivos)
Se necesita especificar los mtodos para asegurar la integridad
de los archivos. Esto normalmente incluye el conjunto de
controles que deben mantenerse dentro del archivo e
independientemente de la aplicacin. Los controles deben
asegurar que los registros de detalle sean consistentes con los
totales de control para cada archivo.
D.12. Recuperacin ante Fallas (Factor: Auditoria)
La recuperacin abarca los procedimientos de recomposicin
ante la identificacin de un problema. Se debe definir para
cada aplicacin, las necesidades de recomposicin de procesos
e informacin. Si la recomposicin es necesaria, se necesita
enunciar el momento para su ejecucin. Este momento, puede
variar segn la hora del da y el da de la semana.
Estos requerimientos de recomposicin afectan el tipo y
disponibilidad de los datos.
D.13. Impacto de Fallas (Factor: Continuidad de
Procesamiento)
La necesidad para asegurar la continuidad de procesamiento
depende del impacto de las fallas. Si la falla causa solo
problemas mnimos, puede ser innecesario asegurarse el
procesamiento continuo. Por el contrario, cuando la
continuidad de la operacin es esencial, es necesario duplicar
los equipos y centros de cmputos, para que se pueda
continuar procesando.
D.14. Nivel de Servicio Deseado (Factor: Nivel de Servicio)
El nivel de servicio implica tiempo de respuesta basado en los
requerimientos. El nivel de servicio requerido variar sobre la
base de los requerimientos. Cada nivel de servicio deseado
necesita estar enunciado; por ejemplo, hay un nivel de servicio
para corregir un error de programacin, otro para instalar un
cambio y otro para responder a una consulta, etc.
D.15. Permisos y Accesos (Factor: Seguridad)
Los requerimientos de seguridad deben desarrollarse
mostrando la relacin entre recursos de sistema y humanos.
Los requerimientos deben enunciar todos los recursos del
sistema disponibles sujetos a control, y luego indicar quin
debe tener acceso a aquellos recursos y con qu propsitos. Al
final del mdulo, el equipo de aseguramiento de la calidad,
puede emitir juicio acerca de la adecuacin de cada criterio. El
equipo debe emitir uno de los siguientes cuatro juicios acerca
de cada criterio:
Muy adecuado: El equipo de proyecto ha hecho ms de lo
normalmente esperado para el criterio.
Evaluacin adecuada: El equipo de proyecto ha hecho el
trabajo suficiente para asegurar el control por encima del
criterio.
Evaluacin inadecuada: El equipo de proyecto no ha hecho el
trabajo suficiente, y deben trabajar ms en este criterio.
No aplicable (N/A): Debido al tipo de aplicacin o diseo
filosfico del sistema por parte de la organizacin, la
implementacin de este criterio no es aplicable al sistema que
se est revisando.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
E. Inspecciones
Las inspecciones y las recorridas walkthrough apuntan a
asistir a los productores para mejorar su trabajo.
Las inspecciones intentan examinar tcnicamente el trabajo y
proveer a los productores, una evaluacin independiente de
aquellas reas productivas en donde las mejoras son
necesarias. Las recorridas son generalmente menos formales y
estn conducidos en un formato ms educacional. Las
inspecciones, por el contrario, generalmente tienen un formato
formal, la asistencia es especfica, y la informacin se refleja
en los resultados.
Hay tantos tipos de inspecciones como tipos de productos. Es
de mucha ayuda inspeccionar los requerimientos antes de
comenzar el diseo de alto nivel, el diseo de alto nivel antes
de comenzar el diseo detallado, el diseo detallado antes de
comenzar la implementacin, y la implementacin antes de
comenzar la verificacin. Esto no significa que todos los
diseos de alto nivel deben ser inspeccionados antes del
comienzo de cualquier diseo detallado, pero el diseo
especfico a realizar debe basarse en el trabajo que ha sido
inspeccionado. Tambin es de ayuda inspeccionar los casos
verificados y la documentacin.
Se recomiendan las inspecciones para diseo, codificacin,
casos de prueba, y documentacin. Caso contrario, es
adecuado un proceso de recorrida menos formal.
E.1. Proceso
El proceso de inspeccin sigue ciertos principios bsicos:
La inspeccin es un proceso formal, estructurado a travs de
un sistema de listas de verificacin (checklists) y roles
definidos para los participantes. Provee un instrumento
ordenado para implementar un estndar de excelencia de
ingeniera del software o de conocimiento en toda la
organizacin.
Los estndares y listas de verificacin genricas son
desarrollados para cada tipo de inspeccin y, cuando sea
apropiado, se ajustan a las necesidades de un proyecto
especfico. Estas listas cubren el planeamiento de la
inspeccin, la preparacin, la conduccin, la salida y reportes
de normas.
Los inspectores estn preparados de antemano y tienen
identificados sus tareas y cuestiones antes de que comiencen
la inspeccin.
El foco de la inspeccin estar en identificar problemas, no
en resolverlos. Este foco, junto a lo mencionado en el punto
anterior, asegura que la inspeccin pueda manejarse con una
mnima prdida de tiempo.
Una inspeccin es conducida por tcnicos para tcnicos. Los
directivos no se involucrarn, aunque sern informados de los
hallazgos y las fechas en las cuales se resolvern los
problemas identificados.
La informacin de la inspeccin deber ser ingresada a una
base de datos y se la utilizar para monitorear la efectividad
de la inspeccin, seguimiento y conduccin de la calidad del
producto.
Mientras mucha gente pueda estar interesada en los resultados
de la inspeccin, el propsito de la inspeccin es asistir a los
productores para mejorar su trabajo. Esto puede hacerse mejor
limitndose a cinco o seis los inspectores. El punto clave de
esta limitacin es la atencin tcnica.
195
El moderador no es el director del trabajo que se est
inspeccionando, ni tampoco ninguno de los otros
participantes. Los moderadores necesitan una base completa
de los principios y mtodos de inspeccin antes de que puedan
hacer un trabajo competente. Esto les dar las herramientas
bsicas y los ayudar a tener mayor confianza en s mismos,
necesaria para liderar tal actividad.
Como las inspecciones bien realizadas requieren de una
intensa concentracin de todos los participantes, stos pueden
quedar exhaustos. Por esto, las sesiones de inspeccin
generalmente no deben exceder las dos horas.
Tambin es de gran ayuda asignar algunos inspectores en
reas productivas especficas durante el proyecto.
E.2. Participantes
Los participantes de la inspeccin, se detallan a continuacin:
El moderador (lder de inspeccin): Persona responsable para
liderar la inspeccin pronta y eficientemente a una conclusin
satisfactoria.
Los productores: Persona/s responsable/s de hacer que se
inspeccione el trabajo.
Los examinadores (inspectores): Generalmente es la gente
directamente involucrada y conocedora del trabajo que est
siendo inspeccionado.
El registrador (quien anota): Alguien que registra los
resultados significativos de la inspeccin.
E.3. Salidas
Las salidas a obtener luego de realizarse una inspeccin, se
detallan a continuacin:
Informe de Inspeccin (Figura 14)
Resumen de la Inspeccin (Figura 15)
Fig. 14. Informe de inspeccin
F. Ranking de Factores de xito (Mdulo de Diseo)
El ranking (scoring) es una herramienta predictiva que
utiliza experiencias en sistemas anteriores. Se analizan los
sistemas existentes para determinar los atributos o
caractersticas de los mismos y su correlacin con el xito o el
fracaso de cada aplicacin en particular. Una vez que los
atributos correlacionados al xito o al fracaso pueden ser
identificados, tambin pueden ser usados para predecir el
comportamiento del sistema que est en desarrollo.
Los lineamientos que se utilizan bajo el concepto de ranking,
se describen a continuacin:
196 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Fig. 15. Resumen de la inspeccin
Muestreo: Los atributos que se utilizarn correspondern a
una muestra de todos los atributos abarcados en la
implementacin de un sistema.
Alta correlacin positiva. Los atributos elegidos tendrn que
mostrar una alta correlacin positiva en el pasado con
cualquier xito o fracaso durante la automatizacin de una
aplicacin. Estos atributos no deberan ser intuitivos sino, que
debern ser atributos para los cuales pueda demostrarse que
la ausencia o presencia de los mismos muestre una alta
correlacin con respecto al resultado final del proyecto.
Facilidad de uso. Para ser efectivo, el proceso de ranking
debe ser lo ms simple posible.
Desarrollar el ranking de riesgo. El ranking para cada atributo
debe determinarse en un formato mensurable de modo que el
ranking de riesgo total pueda ser desarrollado para cada
aplicacin. Esto indicara el grado de riesgo, el rea de riesgo,
y tambin una comparacin de riesgos entre las diferentes
aplicaciones.
Al ranking de riesgo se llega a travs de un desarrollo
matemtico, como se muestra a continuacin.
TABLA XVI. DESARROLLO MATEMTICO PARA OBTENER UN
RANKING DE RIESGO
RIESGO DE LA # DE CARACTERSTICAS FACTOR DE FACTOR PARA
CARACTERSTICA EVALUADAS MULTIPLICACIN EL RANKING
Alta 3 3 9
Media 9 2 18
Baja 12 1 12
Total 39
Para usar esta tabla, el nmero de atributos o caractersticas
calificadas con alto, medio y bajo, deber ser totalizado, y los
totales colocados en la columna # (cantidad) de
Caractersticas Evaluadas.
Luego a cada nmero se lo multiplica por el factor de
multiplicacin y as obtener el ranking de riesgo. Por ejemplo,
el nmero total de caractersticas definidas con alto riesgo
debe multiplicarse por tres. Luego los tres nmeros se suman
para llegar a totalizar el riesgo total, el cual puede utilizarse
para comparar entre los diferentes sistemas, o bien, respecto
de un estndar definido por la organizacin. cuanto ms alto
es el puntaje, mayor ser el riesgo, y a menor puntaje menor
riesgo.
G. Anlisis de Factores (Mdulo de Diseo)
Los factores que deben analizarse durante el mdulo de diseo
se describen a continuacin:
G.1. Controles de Integridad de Datos
La integridad de datos va desde la identificacin de riesgos,
hasta la decisin gerencial de aceptar esos riesgos, establecida
en trminos de la cantidad de prdidas aceptables. Los
controles de integridad de datos se disean a partir de la
tolerancia a tales riesgos, los cuales se encuentran
especificados.
G.2. Reglas de Autorizacin
Las autorizaciones en los sistemas pueden ser manuales y/o
automticas. Los procedimientos para autorizacin manual
deben especificarse durante la fase de diseo. Los mtodos de
autorizacin automtica deben especificarse ms
detalladamente que los manuales, por el hecho de que no se
pueden dejar librados a criterios personales segn la situacin
que se presente.
G.3. Controles de Integridad de Archivos
La integridad de los archivos estar asegurada por los mtodos
de identificacin de archivos, controles automticos y
controles de integridad de archivos mantenidos
independientemente. Las especificaciones para este proceso
integrador de tres partes debe determinarse durante la fase de
diseo.
G.4. Pistas de Auditoria
Estas pistas proveen la capacidad para rastrear transacciones
desde su origen hasta los controles. Adems, las pistas de
auditoria se usan para consolidar el procesamiento de
transacciones individuales y recuperar la integridad de
operaciones luego de su prdida.
Frecuentemente los entes gubernamentales especifican las
pistas de auditoria que necesitan retener para cada tipo de
informacin que manipulan. Estas necesidades de
informacin, deben definirse durante la fase de diseo.
G.5. Plan de Contingencias
El plan de contingencias esquematiza las acciones a tomar
ante la aparicin de problemas.
Este plan deber incluir los mtodos manuales a seguir cuando
las aplicaciones automatizadas no estuvieran en operacin, as
como tambin, las consideraciones de lugar fsico. Las
especificaciones del plan de contingencia deben llevarse a
cabo durante la fase de diseo.
G.6. Mtodo para Alcanzar el Nivel de Servicio Requerido
La fase de requerimientos define el nivel de servicio a obtener
durante la operacin de la aplicacin. El mtodo para alcanzar
ese nivel de servicio es desarrollado durante la fase de diseo.
Esto involucra el desempeo del sistema y su habilidad para
satisfacer las necesidades de los usuarios a lo largo del tiempo.
G.7. Procedimientos de Acceso
La seguridad en los sistemas automatizados es llevada a cabo
predefiniendo quin puede tener acceso a qu recursos y para
hacer qu. Esto estar indicado por los perfiles de seguridad
definidos. Durante la fase de diseo, debern desarrollarse los
procedimientos, las herramientas y las tcnicas necesarias para
crear e implementar los perfiles de seguridad necesarios.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
G.8. Diseo Acorde con la Metodologa
El proceso de diseo de sistemas debe ejecutarse y
documentarse de acuerdo con la metodologa establecida por
la organizacin. Los procedimientos estndares de diseo
aseguran la facilidad de comprensin por todos los miembros
del equipo capacitados y entrenados en esa metodologa y al
mismo tiempo ayuda a asegurar que se cumpla en forma
completa el proceso de diseo.
G.9. Diseo Acorde con los Requerimientos
El diseo del sistema es una transformacin de los
requerimientos de los usuarios en especificaciones ms
detalladas. Durante cualquier transformacin, pueden ocurrir
malos entendidos o malas interpretaciones. Entonces, deben
tomarse las medidas necesarias para asegurar que el diseo
cumpla sus objetivos y est focalizado a cumplir con los
requerimientos definidos.
G.10. Facilidad de Uso
Cuanto el producto final sea ms fcil de usar, habr mayor
probabilidad que el usuario lo utilice y que las transacciones
sean procesadas correctamente. Deben considerarse las
habilidades necesarias para cada puesto de trabajo y la
motivacin en el mismo, de todas las personas usuarias del
sistema.
G.11. Mantenibilidad del Diseo
El costo de mantener una aplicacin normalmente excede el
costo de desarrollo. Identificar aquellos aspectos del sistema
que son los ms factibles de cambiar y construir aquellas
partes del sistema para facilidad del mantenimiento es un
aspecto importante del proceso de diseo. La mantenibilidad
del diseo puede cambiar significativamente dependiendo de
la frecuencia esperada de los cambios introducidos.
G.12. Portabilidad del Diseo
Si los requerimientos indican que el sistema debe poder ser
transferido desde un ambiente de hardware a otro, o una
versin de software de base a otra, el diseo debe tener en
cuenta e incorporar estos aspectos de portabilidad. Cuando el
hardware y software futuros son inciertos, el diseo debe ser
lo ms general posible y no intentar sacar ventaja de los
aspectos o facilidades que brindan el hardware y software
existentes.
G.13. Interfaces de Diseo
Deben ser identificadas y especificadas y documentadas las
interfaces con otras aplicaciones. Las especificaciones de las
interfaces deben tambin considerar usos alternativos de la
informacin de la aplicacin.
G.14. Diseo Acorde con Criterios Establecidos
El estudio de costo/beneficio realizado durante la fase de
requerimientos no provee una estimacin de gran precisin.
La estimacin de la fase de requerimientos puede estar
afectada en ms o menos el 50%. Durante la fase de diseo, la
estimacin del desempeo puede ser definida mejor por lo que
se puede hacer una mejor prediccin y as lograr el
cumplimiento del criterio de desempeo establecido. Una gua
til a ser utilizada, es que la precisin de la estimacin del
criterio de desempeo al final de la fase de diseo puede
variar en 10%.
197
G.15. Necesidades Operacionales
El sector de operaciones deber identificar los requerimientos
de procesamientos futuros para preparar el manejo de tales
requerimientos cuando el sistema se implemente. Cuanto ms
grandes sean los requerimientos de procesamiento, mayor ser
la necesidad de involucrar al sector de operaciones en la
consideracin de las alternativas de diseo.
H. Revisin del Diseo
El objetivo es identificar aquellos atributos del diseo que se
correlacionan con los problemas del sistema. Entonces durante
la revisin de diseo, se investigarn dichos atributos para
determinar si el equipo de proyecto los ha tratado
apropiadamente.
El equipo de revisin de diseo comprende los siguientes
miembros:
Personal del proyecto: El personal del proyecto puede
conducir su propia revisin del diseo. Normalmente la
persona asignada con la responsabilidad de la revisin del
proyecto no es la misma que realmente dise el sistema; sin
embargo el que revisa puede tener responsabilidad parcial en
el diseo. Esto requiere que las personas durante el proceso
de revisin acepten roles y responsabilidades diferentes a los
que han tenido en el proceso de diseo. Debido a probables
vnculos con el diseo real del sistema, tener una lista de
verificacin de revisin de diseo como herramienta
evaluadora, normalmente cumple una valiosa funcin para
el/los que revisan.
Equipo de revisin independiente: Los miembros de este
equipo de revisin no son miembros del proyecto que est
siendo revisado. Pueden ser de otros proyectos o del equipo
de aseguramiento de la calidad. Esta manera de operar provee
un mayor grado de independencia para conducir la revisin
ya que no habr conflicto de intereses entre los roles de
diseador y del que revisa. Por otro lado es frecuentemente
difcil para los inspectores ser crticos unos con otros,
especialmente en situaciones donde el que revisa pueda
eventualmente trabajar para la persona que est siendo
revisada.
La siguiente es una gua en la conduccin de una revisin de
diseo:
Seleccionar el equipo de revisin: Los miembros del equipo
de revisin deben seleccionarse antes del proceso de revisin
propiamente dicho.
Entrenar los miembros del equipo de revisin: Las personas
que conducirn la revisin deben estar entrenadas sobre cmo
dirigir la revisin. Mnimamente significa revisar el checklist
y explicar el objetivo e intencin de cada asunto. Tambin es
aconsejable entrenar a las personas involucradas en
relaciones interpersonales y as realizar la revisin en un
ambiente armonioso.
Notificar al equipo del proyecto: El equipo del proyecto debe
estar notificado de la revisin con varios das de antelacin
cuando comienza la revisin y su responsabilidad durante la
misma. Es importante organizar formalmente la revisin para
que estn todos presentes.
Asignar tiempos adecuados: La revisin debe conducirse
formalmente y tan eficientemente como sea posible. An
cuando la misma gente que dise la revisin, la dirija, las
relaciones interpersonales y los efectos de la sinergia de la
revisin pueden producir muchos efectos positivos si se
198 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
asigna el tiempo suficiente para permitir una interaccin
apropiada.
Documentar los datos de la revisin: Deben registrarse todos
los hallazgos realizados en la revisin. Normalmente esto
puede llevarse a cabo en el checklist, a menos que los
comentarios sean muy extensos. En cualquier caso, los datos
deben hacer referencia a preguntas especficas del checklist
que cubran.
Revisar los datos con el equipo de proyecto: La precisin de
los datos debe ser comprobada por todas las personas
involucradas, y la revisin no debe continuar si esto no est
hecho. Es mejor hacerlo al final de la revisin que durante el
proceso mismo.
Desarrollar recomendaciones de revisin: Basndose en los
datos, el equipo de revisin har sus recomendaciones para
corregir cualquier situacin de conflicto. Estas
recomendaciones son parte importante del proceso de
revisin.
Revisar recomendaciones con el equipo de proyecto: El
equipo de proyecto debe ser el primero en recibir las
recomendaciones y tener la oportunidad de aceptar, modificar
o rechazar las recomendaciones.
Preparar un reporte: Se debe preparar un reporte para
documentar los hallazgos, y las acciones tomadas o a tomar
acerca de las recomendaciones. Este reporte puede o no
enviarse a altos niveles gerenciales, dependiendo de las
reglas establecidas en la revisin por la organizacin. Sin
embargo es importante tener un registro formal del proceso
de revisin, qu se encontr y las acciones tomadas respecto
de las recomendaciones.
La cantidad de revisiones depender de la importancia del
proyecto y del lapso de tiempo en la fase de diseo. As
podrn llevarse a cabo revisiones del diseo de alto nivel y del
diseo detallado.
H.1. Revisin del Diseo de Alto Nivel
Cada defecto descubierto durante la revisin del diseo lgico
o de alto nivel debe documentarse. Se confecciona un reporte
de defectos para llevar registro de los mismos, incluyendo tipo
y categora de los defectos. La descripcin de cada defecto se
registra bajo una columna de Faltante, Errneo o Adicional.
Al final de la revisin del diseo lgico, los defectos se
resumen y totalizan. En la figura 16 se muestra un formulario
de registro de defectos en la fase de diseo de alto nivel:
Fig. 16. Formulario de registro de defectos en la fase de diseo
de alto nivel
H.2. Revisin del Diseo Detallado
Cada defecto descubierto durante la revisin del diseo fsico
o detallado debe documentarse. Se confecciona un reporte de
defectos para llevar registro de los mismos, incluyendo tipo y
categora de los defectos. La descripcin de cada defecto se
registra bajo una columna de Faltante, Errneo o Adicional.
Al final de la revisin del diseo fsico, los defectos se
resumen y totalizan. En la figura 17 se muestra un formulario
de registro de defectos en la fase de diseo detallado:
Fig. 17. Formulario de registro de defectos en la fase de diseo
detallado
I. Depuracin de Programas
La depuracin (debugging) permite al programador evaluar
la integridad y precisin del programa previo a la conduccin
de revisiones y verificaciones menos econmicas. La
depuracin, incluye el diseo detallado y la codificacin.
Esta operacin puede ser tan extensa o tan reducida como se
quiera. La cantidad de depuraciones a realizar depender de:
El tiempo de espera hasta que se reciba el siguiente
programa.
Cronograma de implementacin.
Recursos de prueba
Eficiencia de herramientas de test.
Polticas del rea.
La depuracin puede ser sintctica, estructural, o funcional.
I.1. Depuracin Sintctica
Las especificaciones y expresiones del programa deben
desarrollarse de acuerdo con la metodologa definida por la
organizacin y los requerimientos recopilados. El
programador puede chequear las expresiones y sintaxis para
asegurarse que ha escrito el programa de acuerdo con las
reglas establecidas. Al chequear la sintaxis se hacen preguntas
como:
La funcin a realizar, est claramente identificada?
Las sentencias del programa estn identificadas
correctamente?
Las sentencias del programa estn construidas utilizando la
estructura apropiada?
Los elementos de datos estn apropiadamente identificados?
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Las estructuras de datos son las adecuadas para colocar los
valores que sern utilizados en dichas estructuras?
I.2. Depuracin Estructural
Los problemas de estructura crean un significante nmero de
defectos en la mayora de las aplicaciones. Estos defectos
ocultan defectos funcionales por lo que su deteccin se torna
difcil. Las preguntas tpicas durante la depuracin estructural
son:
Se colocaron todas las sentencias necesarias?
Se utilizan todas las definiciones de datos en las sentencias
definidas?
Se utilizan todos los elementos de datos definidos?
Las tablas internas y valores lmite estn usados de manera
que cuando se excede el lmite se puede continuar
procesando?
5.9.3 Depuracin Funcional
Las funciones son los requerimientos que el programa
ejecutar. Las preguntas cuando se depura la funcionalidad
son:
El programa ejecutar la funcin especfica en la forma
indicada?
Algunas de las funciones son mutuamente excluyentes?
El sistema detectar datos incorrectos o ilgicos?
Se acumular apropiadamente la informacin entre
diferentes ejecuciones del programa?
J. Anlisis de Factores (Mdulo de Codificacin)
La profundidad de la verificacin en el mdulo de
codificacin, depende de cmo se adecua el sistema a las
necesidades del usuario, al final del mdulo de diseo. A
mayor confianza del equipo de verificacin en la adecuacin
de la aplicacin al final del mdulo de diseo, tendrn menos
inquietudes durante el mdulo de codificacin.
En el mdulo de codificacin, el equipo de aseguramiento de
la calidad debe identificar las inquietudes que sean de mayor
inters, y luego desarrollar el proceso de verificacin para
hacer frente a dichas inquietudes. Al identificarlas, el equipo
de aseguramiento de la calidad, debe tener en cuenta los
cambios que han ocurrido en las especificaciones del sistema
desde que se produjo la ltima verificacin. Los objetivos que
los miembros del equipo de aseguramiento de la calidad deben
considerar en el mdulo de codificacin, son:
Los sistemas son mantenibles?
Se han implementado correctamente las especificaciones del
sistema?
Los programas son compatibles con los estndares y
procedimientos?
Existe un plan de verificacin capaz de evaluar los
ejecutables?
Los programas estn adecuadamente documentados?
Las inquietudes (concerns) a considerar durante esta tarea
se describen a continuacin:
Implementacin del control de integridad de informacin: Es
necesario tener implementados controles especficos de
manera de lograr la precisin en el procesamiento deseado.
Los controles implementados en forma impropia, no
alcanzarn el nivel de tolerancia aceptado, y por la mala
comprensin del propsito de los controles, sern
implementadas soluciones simplistas cuando en realidad se
199
 requieren controles complejos para alcanzar los objetivos de
control establecidos previamente.
Implementacin de reglas de autorizacin: Es necesario
verificar la implementacin de reglas de autorizacin de
manera de dificultar su evasin. Adems, las reglas de
autorizacin no deben slo considerar la ejecucin de las
reglas si no tambin tener en cuenta los mtodos ms
comunes de evadirlas.
Implementacin de controles de integridad de archivos: Los
controles de integridad de archivos deben implementarse de
manera que minimicen la probabilidad de prdida la
integridad, debiendo adems prevenirla y detectarla
oportunamente.
Implementacin de auditoras de rastreo: Es necesario
implementar una verificacin de las auditorias para facilitar
la recuperacin de informacin de las mismas (rastreo). Si la
verificacin de la auditoria contiene informacin costosa o
demanda mucho tiempo, su valor disminuye
significativamente. Las consideraciones de la
implementacin incluyen la cantidad de informacin a
recuperar seguida de la facilidad de recuperacin, referencias
cruzadas de informacin para la recuperacin y el tiempo que
la informacin de la auditoria necesita ser almacenada.
Plan de contingencia escrito: El plan de contingencia (serie
procedimientos detallados perfilando aquellas tareas a
ejecutar ante la ocurrencia de problemas) debe describir las
tareas preparatorias para que los datos necesarios y otros
recursos estn disponibles cuando sea necesario activarse.
Abordar el diseo de la contingencia es de poco valor si no se
documenta o no estar en manos de la gente que lo utilizar.
Consecucin del nivel de servicio deseado para el sistema: El
nivel de servicio deseado puede solo hacerse realidad cuando
los procedimientos y mtodos estn implementados. Uno de
los procedimientos que debe establecerse, es el monitoreo del
nivel de servicio para asegurarse que cumple con las
especificaciones. La inclusin de la rutina de monitoreo
provee seguridad en el logro del nivel de servicio a largo
plazo, caso contrario, se detectar a tiempo para tomar
medidas correctivas.
Implementacin de procedimientos de seguridad: La
seguridad es la combinacin de previsin y entrenamiento,
ms herramientas y tcnicas de seguridad. Los
procedimientos que aseguran que tanto las herramientas
como las tcnicas de seguridad estn disponibles y que
trabajen juntas, deben desarrollarse durante la fase de
codificacin.
Cumplimiento del programa con la metodologa a adoptar:
Los procedimientos a implementar deben asegurar
conformidad con estndares, polticas, procedimientos y
mtodos definidos por la organizacin. Si se detecta la no
conformidad, se deberan tomar las medidas necesarias para
modificar el diseo y as lograr la conformidad.
Programas acordes al diseo (Correctitud): El cambio
continuo de condiciones puede provocar que varios
miembros del personal del proyecto, ignoren los objetivos del
mismo durante la fase de codificacin. El argumento es que
siempre hay cambios, de manera que el ajuste a los objetivos
del sistema ya definidos, ahora ya no es muy significativa. El
equipo de aseguramiento de la calidad, debe desalentar esta
forma de pensar y continuamente monitorear la
implementacin de dichos objetivos. Si no se han alcanzado
200 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
los mismos, o deben cambiarse, o bien, debe cambiarse el
sistema para tratar de ajustarlos a las especificaciones
funcionales ya realizadas de la aplicacin.
Programas acordes al diseo (Facilidad de uso): La
implementacin de especificaciones del sistema puede
invalidar algunas de los aspectos del diseo respecto de la
facilidad de uso, a menos que los mismos se encuentren
definidos especficamente. La programacin es la traduccin
de especificaciones de diseo a lenguaje ejecutable por la
mquina. Esto puede entorpecer el logro de la facilidad de
uso. La codificacin debe lograr la facilidad de uso, de igual
forma en que se intenta cumplir con el resto de las
especificaciones funcionales.
Mantenibilidad de los programas: El mtodo de codificacin
puede significar ms para el mantenimiento que las
especificaciones de diseo mismas. Las reglas de
mantenimiento deben definirse en parte por los estndares y
en parte por las especificaciones del sistema. Adems, el
programador debe utilizar su juicio y experiencia para
desarrollar cdigo altamente mantenible.
Programas acordes al diseo (Portabilidad): La portabilidad
de los programas depende del lenguaje seleccionado y de
cmo se usa ese lenguaje. Las especificaciones deben indicar
lo que se hace y no se hace en la programacin para lograr su
portabilidad, y la codificacin debe apegarse a esas
especificaciones de diseo. Si la portabilidad es una
preocupacin importante y las especificaciones del programa
fallan al definir adecuadamente la portabilidad de la
codificacin, la misma quedar en manos del programador.
Programas acordes al diseo (Acoplamiento): Las
especificaciones de diseo deben indicar parmetros a pasar
desde y hacia otros mdulos y aplicaciones del sistema.
Normalmente es una buena prctica del programador,
verificar que las especificaciones del sistema estn
actualizadas antes que las funciones sean codificadas. Esto no
solo asegura que el programa se ajusta al diseo, sino
tambin, que las especificaciones de interconexin entre
aplicaciones no se han modificado desde que se document el
diseo.
Desarrollo de procedimientos operativos: Los procedimientos
deben desarrollarse durante la fase de programacin, de
forma de poder operar la aplicacin. Durante la fase
siguiente, los programas ejecutables sern operados. Los
procedimientos operativos deben ser consistentes con los
requerimientos operacionales definidos para la aplicacin.
Alcance de los criterios de performance por parte de los
programas: La creacin del programa provee la primer
oportunidad para los usuarios de evaluar si el sistema puede
lograr el nivel rendimiento deseado. Una evaluacin
temprana del rendimiento, brindar una buena oportunidad
para hacer ajustes si es necesario.
K. Revisiones por Pares
La revisin por pares contribuye a construir el cdigo de un
programa a travs de revisiones informales, pero sin embargo
efectivas, acerca de la funcionalidad del programa.
Este tipo de revisin provee un anlisis esttico que evala la
estructura y funcionalidad del programa. Puede detectar
errores sintcticos en mayor medida que una simple
observacin visual, como resultado de un recorrido
(walktrhough) de requerimientos.
La revisin por pares tambin puede ser formal. Las formales
son tareas integrales en el proceso de programacin, mientras
que las informales son solicitadas a discrecin del lder de
programacin. Adems puede aplicarse a otros productos, no
slo al cdigo de un programa.
El equipo de revisin por pares debe tener entre tres y seis
miembros. Es importante tener por lo menos tres miembros
para obtener variedad de opiniones. Las personas a considerar
para este equipo sern:
Programadores (por lo menos dos).
Especialistas en JCL (Job Control Language) o similar.
Operadores.
Lderes de programacin.
El programa de revisiones por pares se realiza ejecutando las
siguientes tareas:
K.1. Establecer Reglas Bsicas para la Revisin
Esto no es necesario para cada revisin pero es importante
tener buenas reglas de base. Entre dichas reglas, estn:
reas incluidas y excluidas de la revisin por pares. Por
ejemplo: Ver si la eficiencia de los programas ser incluida.
Cundo se usarn reportes.
Mtodo para seleccionar el lder de la revisin por pares.
Ubicacin de la conduccin de la revisin.
Mtodo para seleccionar productos a ser revisados por pares.
K.2. Seleccionar al Equipo de Revisin
Los integrantes del equipo deben ser seleccionados con la
suficiente antelacin, de manera que puedan organizar su
tiempo y estar entrenados para la revisin.
K.3. Entrenar a los Miembros del Equipo
Si una persona del equipo no ha participado previamente en el
programa de revisin por pares, se la debe entrenar en el
proceso. El entrenamiento incluye el entendimiento de las
reglas bsicas de esta revisin, preferentemente algn
entrenamiento en relaciones interpersonales acerca de cmo
entrevistar y trabajar con gente en el proceso de la revisin, y
entrenamiento en los estndares y metodologa de
programacin.
K.4. Seleccionar el Mtodo de Revisin
El lder del equipo debe seleccionar el mtodo de revisin. La
revisin en s misma consiste en dos partes. La primera es una
explicacin general de los objetivos y funcionamiento del
programa. La segunda parte es la revisin de los programas
utilizando el mtodo seleccionado. Los mtodos que pueden
ser utilizados para conducir la revisin por pares son cuatro:
Diagrama de flujo: El programa se explica desde un diagrama
de flujo. Esto es ms efectivo cuando el diagrama de flujo es
producido directamente desde el cdigo fuente.
Cdigo fuente: La revisin examina cada lnea del cdigo
fuente para entender el programa.
Muestra de transacciones: El lder de programacin explica
los programas exponiendo los procesamientos tpicos que
ocurren a partir de una muestra representativa de
transacciones.
Especificaciones de programas: Las especificaciones de
programas se revisan como un medio para entender el
programa.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
K.5. Conducir la Revisin
El lder de programacin del proyecto normalmente
inspecciona la revisin por pares. La revisin comienza
habiendo hecho el lder de programacin, una revisin rpida
de las reglas bsicas, explicado los objetivos, y luego conduce
al equipo a revisar el procesamiento del programa. El equipo
de revisin ser libre de preguntar y comentar sobre cualquier
aspecto de la explicacin del programador y de hacer
recomendaciones y sugerencias acerca del programa.
Generalmente, la revisin por pares es dirigida en forma
democrtica.
El rol del lder del equipo es asegurar que las preguntas y
comentarios del equipo sean ordenados, asegurar los derechos
de hacer preguntas, recomendaciones o parar en un punto
especfico si, en la opinin del lder de inspeccin, no tiene
sentido continuar discutiendo.
K.6. Conclusiones
Al final de la revisin por pares, el lder de programacin
indicar cundo no tiene ms comentarios que hacer y lo deja
en manos del lder del equipo de revisin por pares. El lder
del equipo de revisin por pares, toma el control y resume la
informacin bosquejada de la revisin y presenta las
recomendaciones del equipo de revisin. Idealmente, esto se
hace como actividad grupal, pero algunos equipos de revisin
por pares, especialmente cuando el proceso se formaliza,
puede querer algn tiempo a solas para discutir entre ellos lo
que han escuchado y lo que van a recomendar. Las
conclusiones y recomendaciones luego se presentan al equipo
del proyecto para su consideracin.
K.7. Reportes
En el proceso de la revisin por pares, se prepara el reporte
documentando los resultados. Sin embargo, esto es opcional y
no es una parte esencial del proceso de revisin por pares.
El formato de los informes tpicos ser similar al que ya se han
detallado con anterioridad:
Informe de Inspeccin
Resumen de la Inspeccin
L. Verificacin de Documentacin
L.1. Integridad de la Documentacin
Los criterios principales para la verificacin de la integridad
de la documentacin, surgirn de la metodologa y estndares
de la organizacin. A continuacin, se detallan criterios
adicionales para verificar la integridad de la documentacin:
Contenido de la documentacin: Al ndice de cada
documento le debera seguir una breve descripcin de cada
elemento dentro del documento. Cada documento debe tener
un ndice de contenidos mnimos obligatorios, para poder
determinar si los documentos contienen toda la informacin
necesaria. Si faltan elementos, hay un defecto potencial en la
integridad de la documentacin, la cual debera ser
notificada.
Usuarios del documento: Cada tipo de documento estar
escrito dirigido a un usuario en particular, el cual podr ser
una persona o grupo, los cuales usarn el documento para
ejecutar una funcin. (Por ejemplo, operacin,
mantenimiento, diseo y programacin).
201
 La informacin deber ser presentada con la terminologa y
el nivel de detalles apropiados para el tipo de usuario al cual
est dirigido el documento.
Redundancia: Los documentos tpicos dentro del proyecto
(Ej. Especificacin de Requerimientos, Anlisis de
Factibilidad, etc.) tendrn alguna redundancia. Se deber
incluir material introductorio en cada tipo de documento para
proveer al lector de un marco de referencia, facilitando la
interpretacin del documento con la menor cantidad de
referencias cruzadas hacia otros documentos. La informacin
que debera ser incluida en cada tipo de documento diferir
en su contexto y a veces en la terminologa y nivel de detalle,
porque intenta ser ledo por diferentes usuarios en diferentes
puntos del ciclo de vida del software
Flexibilidad. La flexibilidad en el uso de los documentos
depende de los lineamientos vigentes en la organizacin.
Tamao del documento: Cada tipo de documento puede tener
un tamao que va de unas pocas a varias decenas de hojas. La
longitud depende del tamao y complejidad del proyecto y
del juicio del Gerente de proyecto as como el nivel de
detalles necesario para el ambiente en el cual el software
deber desarrollarse y ejecutarse.
Combinacin de diferentes tipos de documentos: En
ocasiones, es necesario combinar algunos tipos de
documentos bajo una sola portada o producir algunos
volmenes con los mismos tipos de documentos. Los tipos de
documentos que pueden ser combinados son manuales para
el usuario, operaciones, y mantenimiento del programa. Para
sistemas de gran envergadura, puede ser preparado un
documento para cada mdulo. Algunas veces el tamao del
documento puede requerir ser repartido en varios volmenes
para hacer ms fcil su uso. En esos casos, debern estar
separados por secciones, sub-secciones, etc.
Formato: El formato obligatorio debe ser verificado, y debe
recomendarse el uso del mismo.
Secuencia de contenido: En general, el orden de las secciones
y prrafos de un tipo de documento debe ser el mismo que el
que se muestra en el ndice de contenidos obligatorios. El
orden puede cambiarse si enriquece la presentacin, caso
contrario, debera ajustarse a los estndares ya definidos por
la organizacin.
Ttulos de secciones/prrafos. Estos ttulos generalmente son
los mismos que los mostrados en la ndice de contenidos.
Pueden modificarse para reflejar la terminologa del software
a documentar si el significado le agrega valor a la
presentacin. Se pueden agregar o eliminar secciones o
prrafos segn sea necesario.
Expansin de los prrafos: La mayora de los tipos de
documentos definidos por la metodologa, estndares o
lineamientos de la organizacin tienen prrafos con un ttulo
general y una lista de puntos que pueden discutirse dentro de
ese prrafo. La intencin de esa lista no es establecer la
discusin de cada uno de estos puntos, sino sugerir la
consideracin de los mismos al escribir el prrafo. Este y
todos los otros prrafos pueden expandirse y subdividirse
para llevar a cabo una mejor presentacin de la informacin.
Diagramas de flujo y tablas de decisin: Los grficos de las
soluciones a problemas en forma de diagramas de flujo o
tablas de decisin, pueden estar incluidos o ser un apndice
del documento.
202 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Formularios: El uso de formularios especficos depende de
las prcticas de la organizacin. Parte de la informacin
especificada en los prrafos del ndice de contenidos puede
registrarse en tales formularios. Si es as, el formulario puede
referenciarse desde el prrafo apropiado. Se requiere usar los
formularios que conforman los estndares de la organizacin.
L.2. Grado de actualizacin de la Documentacin
El equipo de verificacin de la documentacin puede usar
cualquiera de las siguientes cuatro verificaciones propuestas
para validar la actualizacin de la documentacin. Los tipos de
verificacin posibles se enumeran a continuacin:
L.2.1. Utilizar la Documentacin Vigente
La actualizacin puede validarse utilizando la documentacin
vigente para realizar algn cambio en la aplicacin. Esto
permite al analista de calidad buscar y confirmar la
consistencia entre varios documentos (por ejemplo, que las
especificaciones en el documento de diseo del programa,
sean las mismas que estn en el cdigo actual) y determinar si
la documentacin respalda el funcionamiento del sistema.
L.2.2. Comparar el Cdigo Fuente con la Documentacin
Esta verificacin usa la versin actual del cdigo fuente de
uno o ms programas como base de la documentacin. Esta
verificacin es realizada sobre la base de una muestra elegida
al azar de los programas o parte de los mismos y se las
verifica contra la documentacin. El objetivo es determinar si
el cdigo es representativo de la documentacin que se posee
del mismo.
L.2.3. Verificar la Vigencia de la Documentacin
Las personas que elaboran la documentacin deben verificar
que est vigente. Deben hacerse preguntas especficas, como
stas:
La documentacin es 100% representativa de la aplicacin
en operacin?
La documentacin cambia cada vez que se hace un cambio
en el sistema?
Los individuos que cambian el sistema confan en que la
documentacin es la correcta?
L.2.4. Verificar la Actualizacin de la Documentacin con el
Usuario
Los usuarios finales deben preguntarse si la documentacin
para el sistema est actualizada. Si los usuarios finales no
estn familiarizados con la documentacin, necesitarn que se
seleccione una muestra pidiendo piezas especficas de la
documentacin. La documentacin seleccionada debe ser
familiar para el usuario final de manera que se les pueda dar
partes representativas del documento y pedir que validen si
estn actualizadas o no.
VI. NIVEL DE SERVICIO ESPERADO
En el presente captulo se describe el Nivel de Servicio
Esperado, a travs de la cuantificacin de los resultados
esperados.
A. Generalidades
A.1. Necesidad de cuantificacin
Toda aplicacin de un modelo o servicio, requiere de ciertos
niveles de servicio o indicadores que permitan obtener una
cuantificacin de los resultados de la aplicacin del mismo y/o Comenzando con el problema se pueden rastrear las posibles
establecer las expectativas para aplicaciones futuras. Para ello, causas.
se describen cuatro indicadores.
Los indicadores aqu presentados, tanto su definicin como el B. Indicadores
valor objetivo sugerido, constituyen slo una muestra no
B.1. Indicador A
esttica del tipo de indicadores que habra que considerar; es
decir se pueden agregar nuevos y/o modificar los aqu El indicador A establece el nivel tiempo promedio en que debe
presentados, conforme a la capacidad de la organizacin y a la poder adaptarse el plan general de aseguramiento de la calidad
experiencia en la aplicacin del modelo. a un proyecto en particular. El esquema correspondiente al
indicador A se muestra en la figura 19.
A.2. Definicin de trminos
Con el objeto de clarificar diferentes trminos que se suelen
confundir o usar indistintamente y para precisar los acuerdos
de nivel de servicio, se presenta a continuacin las siguientes
definiciones, propuesta en [6]:
Errores: Estos son equivocaciones humanas como los errores
tipogrficos o sintcticos.
Defectos: Estos son condiciones impropias de un programa
que generalmente son el resultado de un error. No todos los
errores producen defectos en el programa, como comentarios
incorrectos o algunos errores de documentacin. Por el
contrario, un defecto puede producirse por causas ajenas al
programador, como problemas con las herramientas.
Bugs: Son defectos del programa que se encuentran operando
el mismo, ya sea durante la prueba o durante su uso. Los bugs
provienen de los defectos, pero no todos los defectos causan
bugs (algunas estn latentes pero nunca se encuentran). Los
defectos pueden encontrarse muchas veces, dando como
resultado mltiples bugs por defecto.
Fallas: Es un mal funcionamiento en una instalacin de
usuario. Puede ser provocado por un bug, una instalacin
incorrecta, una falla del hardware, etc.
Problemas: Son dificultades encontradas por los usuarios. Fig. 18. Proceso del mdulo de metodologa, estndares y
Pueden provenir de fallas, mal uso o mal entendimiento. Los procedimientos
problemas son eventos relacionados con los humanos,
contrariamente a las fallas que son eventos relacionados con Descripcin: Tiempo promedio insumido en la generacin
el sistema. del plan especfico de aseguramiento de la calidad para un
Entradas Unitarias: Corresponde a cada uno de los elementos proyecto dado.
del conjunto que componen la entrada a cada uno de los Valor objetivo sugerido: Menor o igual a 1 semana.
mdulos del modelo de Aseguramiento de Calidad de
Software propuesto. Ejemplos de estos elementos o entradas
unitarias son documentos, especificaciones, planes,
diagramas, etc.
En la tabla XVII se resumen algunas de las definiciones
establecidas:

TABLA XVII. DEFINICIN DE TRMINOS

Fig. 19. Tiempo promedio en que se debe adaptar el plan
Categora tems medidos Causas
general al proyecto en particular
Errores Acciones humanas Equivocaciones del programador

Defectos Propiedades del programa Errores

B.2. Indicador B
Bugs Mal funcionamiento del programa Defectos del programa
El indicador B establece el nivel de la capacidad de trabajo
concurrente del equipo de SQA en su conjunto. El esquema
Fallas Mal funcionamiento del sistema Bugs y otros mal funcionamientos correspondiente al indicador B se muestra en la figura 20.
Problemas Percepciones humanas Fallas, errores humanos, incomprensin humana Descripcin: Capacidad mxima de entradas unitarias en
proceso de verificacin concurrente.
En la figura 18 se muestran las relaciones entre las categoras Valor objetivo sugerido: Hasta 10 entradas unitarias.
de la tabla anterior. Este diagrama tiene una doble utilidad:

Comenzando con el error del programador, se puede rastrear

en el diagrama hasta llegar al problema.

Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico. 203
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
 Fig. 20. Nivel de capacidad de trabajo concurrente de SQA
B.3. Indicador C
El indicador C establece el nivel de la rapidez de trabajo del
equipo de SQA. El esquema correspondiente al indicador C se
muestra en la figura 21.
Descripcin: Tiempo mximo promedio de verificacin para
una entrada unitaria.
Valor objetivo sugerido: Menor o igual a 1 semana.
Fig. 21. Rapidez de trabajo de SQA
B.4. Indicador D
El indicador D establece el nivel de eficacia del trabajo del
equipo de SQA. El esquema correspondiente al indicador D se
muestra en la figura 22.
Descripcin: Porcentaje de defectos detectados en el proceso
de aseguramiento de la calidad del software (Considerando el
total de defectos de un sistema desde el inicio del proyecto
hasta 6 meses despus de su puesta en produccin).
Valor objetivo sugerido: 75% de los defectos
Fig. 22. Nivel de eficacia del trabajo de SQA
VII. EQUIPO DE SQA
En el presente captulo se detalla el Equipo de SQA sugerido,
indicando su estructura y responsabilidades.
A. Estructura del equipo aseguramiento de la calidad
El equipo de trabajo de SQA puede tener variadas estructuras
y depender de la propia realidad y caractersticas particulares
de la organizacin en la cual el equipo se desempea.
En el presente trabajo se presentar una estructura en tres
niveles, muy comn en varias organizaciones. En la figura 23
se esquematiza esta estructura:
204 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
Fig. 23. Estructura en tres niveles del equipo de aseguramiento
de la calidad
Cada sub-equipo, confirmado por un analista de SQA Senior y
sus Analistas de SQA Semisenior, podra ser asignado a un
proyecto en particular, mientras que, el Lder de SQA de la
organizacin, tiene el control sobre los sub-equipos y
mantiene una visin general que comprende a todos los
proyectos de dicha organizacin.
B. Responsabilidades del equipo
A continuacin de describe, slo a modo de ilustrativo, las
principales responsabilidades de cada uno de los perfiles
establecidos en la estructura de la figura 23.
B.1. Lder de SQA
Mantenimiento del dialogo primario con los referentes del
rea de desarrollo.
Administracin del presupuesto de los proyectos para la
funcin de SQA.
Responsable de asegurar al equipo de trabajo los elementos
que ste o cualquiera de sus integrantes necesite.
Coordinacin de las necesidades polticas de los proyectos
con las capacidades operativas disponibles.
Coordinacin de responsabilidades entre los analistas de
SQA de los distintos proyectos.
Mantenimiento de la conduccin de todo el equipo de SQA.
Determinacin de los objetivos de SQA, para etapa de un
proyecto y control de su cumplimiento.
Elaboracin peridica de informes de avance y seguimiento.
Participacin en reuniones tcnicas, siempre que resulte
necesario.
Participacin en los mdulos que se indica en el modelo de
aseguramiento de la calidad propuesto.
Supervisin (directa o indirecta) de los analistas de SQA.
Evaluacin de cada integrante del equipo.
Responsable de la disciplina y cumplimiento del equipo.
B.2. Analista de SQA Senior
Aseguramiento del cumplimiento de su presupuesto
asignado.
Aplicacin de la metodologa de aseguramiento de la calidad
para los proyectos asignados.
Aseguramiento del cumplimiento de los objetivos fijados por
el lder de SQA.
Aseguramiento del cumplimiento de la metodologa de
trabajo fijada.
 Participacin en los mdulos que se indica en el modelo de
aseguramiento de la calidad propuesto.
Conduccin y administracin del equipo asignado a su cargo.
Asignacin de tareas a los analistas de SQA Semi-senior.
Supervisin de las tareas de los analistas de SQA Semi-senior
que le correspondan en cada proyecto.
Elaboracin peridica de informes de gestin de su equipo.
Elaboracin de informes por excepcin cada vez que resulte
necesario.
Comunicacin inmediata en situaciones que excedan su
capacidad de control o decisin.
Responsable primario de la disciplina y cumplimiento de su
equipo.
Colaboracin tcnica con el Lder de SQA en las reuniones o
consultas que ste requiera.
Asesoramiento al Lder de SQA en toda cuestin tcnica
vinculada a su rea de influencia.
B.3. Analista de SQA Semi-senior
Participa en los mdulos que se indica en el modelo de
aseguramiento de la calidad propuesto.
Cumplimiento detallado con la metodologa de trabajo
impuesta y con las pautas que le fijen sus supervisores.
Elaboracin de informes detallados de cada unidad de
anlisis.
Elaboracin de informes por excepcin cada vez que resulte
necesario.
Comunicacin inmediata en situaciones que excedan su
capacidad de control o decisin.
Colaboracin tcnica con el Analista de SQA Senior en las
reuniones o consultas que ste requiera.
VIII. CONCLUSIONES
En el presente captulo se establecen las Conclusiones
obtenidas al concluir el presente trabajo, sealando los
beneficios y problemas esperados en la aplicacin de la
funcin de SQA en una organizacin. Tambin se establecen
las bases para un anlisis costo-beneficio.
A. Beneficios y problemas
Aunque pocos profesionales pondran en duda la necesidad de
calidad en el software, muchos no estn interesados en
establecer funciones de SQA formales. Las principales
razones de esta aparente contradiccin son las siguientes:
Los responsables del desarrollo se resisten a hacer frente a los
costos extras inmediatos y les cuesta ver los beneficios a
largo plazo.
Por desconocimiento, muchos profesionales creen que ya
estn haciendo todo lo que hay que hacer con respecto al
aseguramiento de la calidad.
Pocos saben dnde situar esa funcin dentro de la
organizacin.
Todos quieren evitar cierto nivel de burocracia que la funcin
de SQA tiende a introducir en el proceso de ingeniera del
software o de conocimiento.
En el presente trabajo, se ha presentado un enfoque prctico
para la aplicacin de la funcin de aseguramiento de la calidad
del software en una organizacin, que intenta echar luz sobre
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
las razones ya enunciadas que impiden la aplicacin de la
dicha funcin.
Aunque instanciada en la metodologa IDEAL, este enfoque
es independiente de la metodologa de desarrollo que esa
organizacin utilice. La independencia del enfoque con
respecto a metodologa utilizada por la organizacin, se debe a
qu el enfoque presentado es general, aplicable a fases
comunes de cualquier metodologa y a que no obliga a su
aplicacin rgida, sino que permite su adaptacin a esa
metodologa y a la propia realidad de la organizacin.
Asimismo, el enfoque presentado constituye un complemento
no disruptivo de la metodologa de desarrollo que ya utiliza
una organizacin y no obliga a profundos cambios en la
misma. Por el contrario, si la organizacin no utiliza una
metodologa, incentiva la utilizacin de una.
Algunos de los principales beneficios esperados de la
aplicacin constante y rigurosa de la funcin de SQA,
mediante el enfoque presentado, son los siguientes:
El software tendr menos defectos latentes, como
consecuencia, se reducir el esfuerzo y el tiempo durante las
etapas de prueba y mantenimiento.
Se dar una mayor fiabilidad y, por tanto, una mayor
satisfaccin del cliente.
Se podrn reducir los costos de mantenimiento (un porcentaje
sustancial de los costos totales del software).
El tiempo y el costo total del ciclo de vida del software
disminuir.
Por el lado negativo, la funcin de SQA podra resultar
problemtica por las siguientes razones:
Es difcil institucionalizar en organizaciones pequeas, en las
que no estn disponibles los recursos necesarios para llevar a
cabo esas actividades.
Representa un cambio cultural, y el cambio nunca es fcil.
Requiere un gasto que, de otro modo, nunca se hubiera
destinado explcitamente a la ingeniera del software o de
conocimiento o al aseguramiento de la calidad.
B. Evaluacin costo-beneficio
A la hora de establecer la funcin de aseguramiento de la
calidad del software en una organizacin, es razonable
preguntarse si valdr la pena, si el costo de su establecimiento
y aplicacin continua se ver justificado por los beneficios
alcanzados.
En el marco de un anlisis bsico de costo-beneficio, se puede
afirmar que la funcin de SQA en una organizacin ser
efectiva si se cumple con la siguiente: A > B + C siendo:
A: Costo de las fallas que aparecen sin la aplicacin de la
funcin de SQA. Esto incluye, entre otros, las actividades de
reparacin y re-trabajo, resolucin de quejas del cliente,
retorno y reemplazo del producto, soporte y ayuda al cliente, y
el pago de penalidades contractuales.
B: Costo de la propia aplicacin de la funcin de SQA. Esto
incluye, entre otros, los salarios del equipo de SQA y las
actividades de planificacin, revisiones y auditorias.
C: Costo de las fallas que no se encuentran con la aplicacin
de la funcin de SQA. Esto incluye los mismos puntos que A,
pero deberan ser dramticamente inferiores.
Sin embargo, es importante resaltar que en un anlisis ms
minucioso habra que considerar tambin otros aspectos, tales
como:
Reducciones en los costos de las pruebas y de la integracin.
205
 Reduccin del nmero de cambios en las primeras versiones.
Reduccin en los costos de mantenimiento.
y otros de no tan fcil cuantificacin, tales como:
Mejora en satisfaccin del cliente.
Mejora en la imagen de la imagen externa de la organizacin.
Mejora en la imagen interna del equipo de ingeniera del
software o de conocimiento.
Finalmente, tambin es necesario tener en cuenta al momento
de hacer un anlisis costo-beneficio, que la funcin de SQA
no necesariamente est circunscripta al mbito de la ingeniera
del software o de conocimiento, sino que evoluciona como
parte de un esfuerzo general de gestin en la organizacin,
dirigido a mejorar la calidad. A ese esfuerzo general de
gestin dentro de la organizacin se lo suele denominar
gestin de la calidad total.
IX. BIBLIOGRAFA
[1] Roger S. Pressman (2001). Software Engineering: A
Practitioner's Approach. McGraw-Hill.
[2] J. Mc Call, P. Richards y G. Walters (1977). Factors in Software
Quality. Rome Air Development Center, United States Air
Force.
[3] R. Grady y D. Caswell (1987). Software Metrics: Establishing a
Company-Wide Program. Prentice Hall.
[4] Carnegie Mellon University - Software Engineering Institute
(1994) The Capability Maturity Model: Guidelines for
Improving the Software Process. Addison Wesley.
[5] William E. Perry (2000). Effective Methods for Software
Testing. Wiley Computer Publishing.
[6] Watts S. Humphrey (1989). Managing the Software Process.
Addison Wesley.
206 Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
X. FINANCIAMIENTO
Las investigaciones cuyos resultados se presentan en este
trabajo fueron parcialmente financiados por subsidio del
proyecto UNLa 33B102.
Eduardo Diez. Es Profesor Asociado del Area de
Ingeniera de Software en la Licenciatura en
Sistemas (Res. CONEAU 1089/12) del
Departamento de Desarrollo Productivo y
Tecnolgico de la Universidad Nacional de Lans
y Profesor Adjunto Regular del rea de Ingeniera
de Software en la Carrera de Ingeniera
Informtica de la Facultad de Ingeniera de la Universidad de Buenos
Aires. Es Profesor de la Maestra en Ingeniera de Software
(Acreditada por Resolucin CONEAU nro 239/04) en el marco del
Convenio Universidad Politcnica de Madrid - ITBA y Profesor de
Posgrado en la Maestra en Ingenieria de Sistemas de Informacin en
la Escuela de Posgrado de la Facultad Regional Buenos Aires de la
Universidad Tecnolgica Nacional. Es Investigador del Grupo de
Investigacin en Sistemas de Informacin y dirige del Laboratorio de
Investigacin y Desarrollo en Aseguramiento de Calidad de Software
de la Licenciatura en Sistemas y de la Maestria en Sistemas de
Informacin del Departamento de Desarrollo Productivo y
Tecnolgico de la Universidad Nacional de Lans. Su areas de
interes en investigacin son Calidad de Software y Modelos de
Madurez de Procesos de Software. Es Director del Proyecto UNLa
33B102 Aseguramiento de la Calidad para Proyectos de Explotacin
de Informacin. Es Analista de Sistemas y Licenciado en Sistemas
por la Universidad de Belgrano. Es Especialista en Ingeniera de
Sistemas Expertos y Magister en Ingeniera de Software por el
Instituto Tecnolgico de Buenos Aires y por la Facultad de
Informtica de la Universidad Politcnica de Madrid.
 Estudio Comparativo de Plataformas Cloud
Computing para Arquitecturas SOA
Franco Bocchio 1,2
1. Programa de Maestra en Ingeniera de Sistemas de Informacin.
Escuela de Posgrado, Facultad Regional de Buenos Aires. Universidad Tecnolgica Nacional. Argentina.
2. Laboratorio de Investigacin y Desarrollo en Arquitecturas Complejas.
Grupo de Investigacin en Sistemas de Informacin. Universidad Nacional de Lans. Argentina.
franco.bocchio.ar@member.mensa.org

ResumenLas plataformas Cloud Computing estn fundadas
en un paradigma tecnolgico moderno que ofrece nuevas
alternativas a empresas de diversas envergaduras para
implementar modelos de negocios innovadores. Con estos nuevos
modelos de negocio las empresas pequeas pueden hacer uso de
las plataformas Cloud Computing disponiendo de la posibilidad
de incrementar, tanto progresiva como abruptamente, su
capacidad de cmputo y almacenamiento de datos en funcin de
las necesidades y en tiempo real, implicando una oportunidad
singular para la competencia de mercado.
En adicin, las arquitecturas orientadas a servicios otorgan
caractersticas de grandes beneficios para los sistemas modernos,
permitiendo altos niveles de reutilizacin de funcionalidades,
encapsulamiento y nuevas oportunidades para sociedades entre
proveedores y consumidores de servicios. En este trabajo se
propone, entonces, analizar y comparar las plataformas de los
principales proveedores de servicios Cloud Computing, alineados
a los distintos modelos arquitectnicos SOA que de las
plataformas antedichas se desprenden con el objetivo de
encontrar similitudes y diferencias, as como tambin faltantes.
Palabras Clave. Cloud Computing, Arquitectura orientada a
Servicios, Plataformas.
I. QU ES UNA ARQUITECTURA SOA?
SOA es una representacin de una arquitectura abierta,
extensible y federada basada en composicin, que promueve la
orientacin a los servicios interoperables e independientes de
los proveedores, los cuales pueden ser identificados en
catlogos con gran potencial de reutilizacin e implementados
como servicios Web. SOA puede establecer una abstraccin de
la lgica del negocio y la tecnologa, resultando en un bajo
acoplamiento entre dominios [1].
SOA es el producto de la evolucin de plataformas de
tecnologa que se solan utilizar con frecuencia, preservando
las caractersticas exitosas de las arquitecturas tradicionales.
Podemos entender a las arquitecturas SOA como un estilo de
diseo que gua los aspectos de creacin y uso de servicios de
negocio a travs de su correspondiente ciclo de vida. Adems
define y aprovisiona la infraestructura de tecnologas de la
informacin que permite a diferentes aplicaciones intercambiar
datos y participar en los procesos de negocio,
independientemente del sistema operativo o de los lenguajes de
programacin con los cuales estos servicios (y aplicaciones)
fueron desarrollados e implementados [2].
Muchas definiciones de SOA incluyen el trmino servicios
web, sin embargo, es necesario hacer la distincin de estos
conceptos y aclarar que SOA no es lo mismo que servicios
Web puesto que SOA, a diferencia de los servicios web, define
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
y trata un paradigma, en tanto que los servicios web son solo
una forma posible de consumar la infraestructura utilizando
una estrategia de implementacin especfica.
Podemos decir entonces que SOA es un paradigma
arquitectnico que permite el tratamiento de procesos de
negocio distribuidos de nuevos sistemas heterogneos que se
encuentran bajo el control o responsabilidad de diferentes
propietarios, siendo sus conceptos clave principales los
servicios, la interoperabilidad entre lenguajes, y el bajo
acoplamiento. En tanto que los ingredientes principales de
SOA son la infraestructura, la arquitectura y los procesos.
Es preciso tambin aclarar que SOA no es una bala de
plata (silver bullet) ni una tecnologa especfica, por lo cual,
hay casos en los cuales SOA puede ser un paradigma
apropiado y otros en los cuales pueden no ser la solucin ms
adecuada o conveniente.
SOA puede ser entendido tambin como un modelo de
diseo cuyas races conceptuales establecen los principios de
encapsulamiento de la lgica de la aplicacin por medio de
servicios, los cuales pueden interactuar a travs de protocolos
de comunicacin estandarizados.
La arquitectura orientada a servicios representa la
evolucin a un nuevo modelo que permite la construccin de
aplicaciones distribuidas. Los servicios implementados en esta
arquitectura son distribuidos en componentes que proveen
interfaces bien definidas (las cuales funcionan como contratos),
que para el caso de los servicios web procesan y distribuyen
mensajes basados en XML.
Las soluciones basadas en servicios encuentran sentido
cuando se trata la construccin de aplicaciones y sistemas que
resuelven problemas organizacionales, departamentales y
corporativos.
Un negocio con mltiples sistemas y aplicaciones
desarrolladas en diferentes plataformas pueden utilizar SOA
para construir soluciones integradas de bajo acoplamiento que
implementan flujos de trabajos unificados y cooperativos [3].
El siguiente ejemplo esclarece el marco terico de SOA: el
concepto de servicios puede resultar familiar para cualquiera
que realice compras en lnea utilizando aplicaciones web de
tipo e-commerce (comercio electrnico; algunos ejemplos de
estas aplicaciones pueden ser Ebay, Amazon, etc). Una vez
que se realiza un pedido, se debe proporcionar al sistema los
datos de una tarjeta de crdito, la cual es tpicamente
autorizada y actualizada (gasto) por un proveedor de servicios
externo. Una vez que la orden ha sido consumada, la compaa
de comercio electrnico coordina la entrega con un proveedor
de servicios de envos para entregar el producto que el cliente
207
adquiri. SOA no es la primera arquitectura distribuida que
permite utilizar componentes a travs de interfaces de dominios
independientes, por lo cual su aporte diferencial no reside
precisamente en esta caracterstica. SOA usa los servicios web
como puntos de entrada (entry points) de las aplicaciones, los
cuales conceptualmente son equivalentes a los componentes
proxis y stubs tradicionales utilizados por aos en arquitecturas
distribuidas, con excepcin de que la interaccin entre los
proveedores de servicios web y los consumidores se
caracterizan por presentar mucho menor acoplamiento.
SOA tambin es un paradigma nico en tanto que incorpora
factores que son crticamente importantes para el negocio, tales
como fiabilidad de servicios, integridad de mensajes,
integridad transaccional y protocolos de seguridad para los
mensajes.
Muchas aplicaciones implementan modelos de
comunicacin sincrnicos rgidos bajo un flujo de trabajo lineal
el cual es altamente susceptible a fallas en algn punto. SOA
asume que los errores ocurren y en efecto ocurrirn, para lo
cual ofrece estrategias para una eficiente administracin de
estos. Por ejemplo, si un servicio falla al recibir una peticin
de mensaje en su primer intento, la arquitectura SOA propone
que su implementacin reintente el envo de este mensaje, y si
el servicio se encontrara por completo no disponible (lo cual
nunca debera ocurrir en una SOA robusta), la arquitectura
debe estar diseada para evitar posibles fallas catastrficas que
podran interrumpir por completo la recepcin de peticiones
(requests).
En conclusin, y en un sentido ms amplio, podemos decir
que SOA representa un proceso de maduracin de la tecnologa
como el incremento de uso de los servicios web y tecnologas
de integracin en general. SOA reconoce que los sistemas de
misin crtica basadas en tecnologas distribuidas deben
proporcionar ciertas garantas. Debe asegurar entonces que las
solicitudes de servicio se entreguen correctamente, que sern
respondidas en el momento oportuno y que se publicarn sus
polticas de comunicacin e interfaces [4].
A CONTINUACIN SE PRESENTA UN EJEMPLO DE
ARQUITECTURA ALINEADA A SOA
En la Figura 1 se presenta un diagrama que modela una
arquitectura genrica de 3 capas alineada a SOA. A
continuacin se presenta la Tabla 1, que describe cada uno de
los componentes que integran esta arquitectura genrica.
II. ESTADO DE LA CUESTIN
A. Caractersticas de SOA:
Bajo acoplamiento: el acoplamiento es el grado en que
cada mdulo de programa depende de cada uno de los otros
mdulos de programa. El bajo acoplamiento generalmente se
correlaciona con la alta cohesin y viceversa [5].
Los servicios web poseen la caracterstica de estar basados
en una estructura flexible mediante la cual, una vez que una
pieza de software ha sido expuesta como un servicio web, es
relativamente fcil de mover a otro equipo, puesto que la
funcionalidad se encuentra abstrada de la interfaz que define el
contrato de sus operaciones [6].
La figura 2 ilustra el bajo acoplamiento del servicio. En la
parte 1 del dibujo, un miniordenador accede a un servicio web
que se ha expuesto en un mainframe.
208 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
TABLA 1. DESCRIPCIN DE LOS COMPONENTES QUE INTEGRAN LA
ARQUITECTURA GENRICA
Trmino Definicin
Este componente (Service Agents) permite a
las implementaciones de los servicios de negocio
acceder a otras instancias de servicios, con el
propsito de reutilizar funcionalidades, testear
minimizar las pruebas funcionales (las
Agentes de funcionalidades reutilizables se encuentran
Servicio encapsuladas en componentes y se implementan
una nica vez),minimizar el mantenimiento
(cuando se implementan mejoras sobre un
componente de servicios reutilizables, todos los
servicios que refieran a este servicio podrn
beneficiarse con las mejoras implementadas).
Se refiere a los componentes de interfaz de
Componentes de
IU
usuario que sern implementados y desplegados en
esta arquitectura
Estos componentes contienen la lgica de
acceso a datos (Data Access Logic Components),
Componentes de
abstrayendo y separando concretamente la capa de
Lgica de Acceso a
Datos
lgica del negocio de la capa de acceso a datos
(separacin y asignacin de responsabilidades por
capas).
Corresponden a la implementacin de los
servicios de negocio, comprendiendo
Componentes de fundamentalmente las funcionalidades y
Negocio operaciones de negocio requeridas. Implementan
las operaciones definidas en las interfaces del
negocio (Service Interfaces).
Hace referencia a los componentes que
Componentes de
implementan procesos competentes a la capa de
Procesos de IU
interfaz de usuario.
Corresponden a las entidades del modelo de
Entidades de dominio (Business Entities). Son utilizadas tanto
Negocio por los servicios como por los componentes de
acceso a datos.
Este componente encapsula e implementa
mecanismos de flujos de trabajo (Business
Flujo de Trabajo
Workflow) que permiten formalizar y organizar los
del Negocio
procesos del negocio para el modelo de dominio en
cuestin.
Algunas de las fuentes de datos posibles (Data
Fuentes de datos
Sources) podran ser una base datos relacional,
archivos de datos, un data grid, bases de datos
NoSQL, etc.
Las interfaces de servicios funcionan como
Interfaces de contratos, definiendo formalmente las operaciones
Servicios (capacidades) que brindarn los servicios basados
en esta arquitectura.
Estos componentes (Security, Operational
Management, Communication) operan de manera
transversal porque su funcionamiento debe
Seguridad,
considerarse en todas las capas. La aplicacin
gestin operativa,
Comunicaciones
podra utilizar tambin componentes para realizar
la administracin de excepciones, autorizar a los
usuarios a realizar ciertas tareas y comunicarse con
otros servicios y aplicaciones.
Se refiere a los usuarios que harn uso de la
Usuarios
aplicacin.
a. Componentes de la arquitectura genrica. Adaptado de [Microsoft Corp., 2003].
Digamos que, sin embargo, el propietario de la unidad
central quiere remplazar la mquina antigua con un nuevo
servidor Sun. Como vemos en la parte 2, la mquina Sun
sustituye a la unidad central, pero la minicomputadora, que es
el consumidor del servicio web no tiene conocimiento de esta
sustitucin. La minicomputadora se sigue comunicando por
medio del protocolo SOAP. Es completamente transparente
para el consumidor del servicio (cliente) que la interfaz del
servicio est implementada en una computadora central, en un
equipo Windows o en cualquier otra plataforma. Una vez que
la unidad central ha sido sustituida por la mquina Sun, la
minicomputadora contina accediendo al servicio sin percibir
este cambio.
Fig. 1. Arquitectura de 3 capas alineada a SOA. Adaptado de [70].
En las partes 3 y 4 de la figura antedicha el proceso de
sustitucin de ordenadores contina. El propietario de la
minicomputadora la remplaza con un PC. El PC que est
equipado con su propia interfaz SOAP puede acceder
fcilmente a los servicios web expuestos por la mquina Sun.
Si por cualquier razn el propietario del servicio decidiera
sustituir la mquina Windows por otro servidor Sun, no habra
problema alguno; una vez ms se podra acceder al servicio sin
necesidad de realizar ninguna modificacin a ste. La figura 2,
que ilustra el bajo acoplamiento de servicios.
A.1. Transparencia de Red
Debido a que el acoplamiento entre los servicios web es
"flojo" y que los consumidores y los proveedores de servicios
de Internet envan mensajes entre s mediante protocolos
abiertos de Internet, los servicios web ofrecen transparencia
total de la red a los que los emplean. Transparencia de la red se
refiere a la capacidad de un servicio web para estar activos en
cualquier parte de una red, o grupo de redes, sin tener ningn
impacto en su capacidad de funcionar. Debido a que cada
servicio web tiene su propia URL, servicios web tienen una
flexibilidad similar a sitios web en Internet. De la misma
manera que no hay diferencia en qu parte del mundo un sitio
web est alojado para poder ser navegado, un servicio web se
puede encontrar en cualquier equipo que est conectado a la
red y se comunica con protocolos de Internet. Cuando
navegamos por ejemplo Amazon.com para comprar un libro,
no existe ninguna necesidad de conocer dnde residen las
aplicaciones a las cuales estamos est accediendo con nuestro
navegador, lo nico que se necesita saber es la direccin web.
Un mismo servicio web puede estar situado en dos
dominios diferentes. Si por alguna razn el dominio A se
encontrara no disponible, entonces el consumidor del servicio
podra acceder al servicio web desde el dominio B de manera
alternativa. Lo nico que tiene que ocurrir es la modificacin
de la direccin (URL) del servicio web en el documento
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
WSDL, de manera que se establezca un vnculo entre el cliente
(consumidor del servicio) y la nueva direccin del servicio web
en el dominio B.
Fig. 2. Bajo acoplamiento del servicio. Adaptado de [6]
Dada nuestra amplia experiencia con la Internet en los
ltimos aos, la propiedad de transparencia de la red puede no
parecer tan importante, pero en realidad se trata de un aspecto
fundamental para el futuro de la informtica. La combinacin
de acoplamiento dbil y la transparencia de red presentan nada
menos que una revolucin en la informtica empresarial, no
porque se trate de una idea novedosa, sino debido a que la
infraestructura y los estndares han llegado por fin para que sea
una realidad. Las empresas han gastado fortunas en los ltimos
aos en la gestin de interfaces que hacen factible la
interoperabilidad de los equipos en entornos distribuidos.
Algunas empresas Norteamericanas gastan cientos de miles de
millones de dlares por ao en tecnologas de la informacin
[6].
Reusabilidad y granularidad: Un servicio es un software
reutilizable y auto-contenido, independiente de las aplicaciones
y las plataformas de computacin en las cuales se ejecuta. Los
servicios tienen interfaces bien definidas y permiten una
correspondencia entre las tareas de negocio y los componentes
exactos de TI necesarios para ejecutar la tarea. Los servicios
SOA se centran en tareas de nivel de negocio, actividades e
interacciones. La relacin entre los servicios y los procesos de
negocios es crtica. Un proceso de negocio es un conjunto de
tareas de negocios relacionados que abarcan personas, sistemas
e informacin para producir un resultado o producto especfico.
Con SOA, un proceso se compone de un conjunto de servicios.
Antes de SOA, el foco estaba en sub-tareas tcnicas. Puede
haber odo que la gente llama a esto un buen "nivel de
granularidad" o bajo "grado de abstraccin." Por la simplicidad
de SOA, sabemos que es ms que una simple relacin uno-a-
uno entre los pasos de un proceso (como la comprobacin de
una calificacin crediticia) y los servicios que estn diseados
para apoyar ese proceso de negocio flexible.
209
 Cada empresa tiene una visin diferente respecto de la
granularidad que requieren sus servicios en funcin de su
diseo de negocios. En pocas palabras, la granularidad es la
cantidad de funcin que un servicio expone. Por ejemplo, un
servicio de granularidad fina proporciona unidades ms
pequeas de un proceso de negocio, y un servicio de
granularidad gruesa proporciona una tarea de negocio ms
amplia que contiene un mayor nmero de pasos [7].
Los servicios no pueden ser demasiado grandes o
demasiado pequeos, sino que deben tener la granularidad
adecuada. Disear y decidir la granularidad de los servicios es
una cuestin clave que conduce al xito. Si el servicio es
demasiado grande, ser menos reutilizable. Si el servicio es
demasiado pequeo, provoca una disminucin en el
rendimiento y mala asignacin de tareas entre los negocios y
los servicios que los apoyan.
Determinar qu tan grande o pequeo debe disearse un
servicio es funcin qu tan atmica es la composicin de su
funcin.
Es importante observar que este concepto de servicios es
una de las claves para hacer que SOA sea el lenguaje de los
negocios. La mayora de los lderes empresariales no
comprenden el valor de SOA. En su lugar, se centran -y con
razn- en el problema en cuestin. Debido a estos servicios de
negocio, este lenguaje y la vinculacin de los servicios de
negocio y SOA se convierten en una pieza fundamental para la
solucin del problema, y constituyen la futura misin
estratgica [7].
Sistemas distribuidos: A medida que las empresas crecen se
vuelven ms y ms complejas, y cada vez se involucran ms
empresas y sistemas. Hay una integracin y un cambio
constantes. SOA es muy adecuado para tratar con sistemas
distribuidos complejos. De acuerdo con el modelo de
referencia SOA de OASIS, es un paradigma para "organizar y
utilizar capacidades distribuidas.
NOTA: Una definicin ms adecuada para "capacidades
distribuidas" en IT sera "sistemas distribuidos", o como dice la
definicin de SOA de Wikipedia: "nodos de una red" o
"recursos de una red."
SOA permite a las entidades que necesitan ciertas
capacidades distribuidas, localizar y hacer uso de esas
capacidades. En otras palabras, facilita las interacciones entre
los proveedores de servicios y sus consumidores, lo que
permite la realizacin de funcionalidades de negocio [3].
Diferentes propietarios: La definicin de SOA del modelo de
Referencia de OASIS dice que las capacidades distribuidas
"pueden estar bajo el control de diferentes dominios de
propiedad." Este es un punto muy importante que a menudo es
suprimido en definiciones de SOA. Esta es una de las claves
para ciertas propiedades de SOA, y una razn importante por la
que SOA no es slo un concepto tcnico.
SOA incluye prcticas y procesos que se basan en el hecho
de que las redes de los sistemas distribuidos no son controladas
por los propietarios individuales. Diferentes equipos, diferentes
departamentos o incluso diferentes empresas pueden gestionar
diferentes sistemas. Por lo tanto, diferentes plataformas,
programas, prioridades, presupuestos, etc. deben ser tenidos en
cuenta. Este concepto es clave para la comprensin de SOA y
de grandes sistemas distribuidos en general.
Se presenta la figura 3, que ilustra un conjunto de sistemas
distribuidos con diferentes propietarios.
Fig. 3. Sistemas distribuidos con diferentes propietarios. Adaptado de [3].
Las formas de lidiar con problemas y realizar
modificaciones en los entornos con diferentes propietarios y en
entornos donde se dispone de control total, pueden variar. No
se puede implementar la funcionalidad y modificar el
comportamiento de la misma manera en grandes sistemas
como en sistemas ms pequeos. Una consideracin
importante es que "la poltica" entra en juego: hay que
comprometerse con los dems, y hay que aceptar que existen
diferentes prioridades y soluciones. Porque no se puede
controlar todo, hay que aceptar que no siempre puede ser capaz
de hacer las cosas a su manera [3].
A.2. Heterogeneidad
Una diferencia muy importante entre los sistemas pequeos
y grandes es la falta de armona. Todos lo sabemos por
experiencia (aunque podramos no estar de acuerdo acerca de si
se trata de un fenmeno natural o el resultado de un mal
diseo). Los grandes sistemas utilizan distintas plataformas,
diferentes lenguajes de programacin (y paradigmas de
programacin), e incluso diferentes componentes middleware.
Se trata de un lo de mainframes, ejrcitos de SAP, bases de
datos, aplicaciones J2EE, pequeos motores de reglas, etc. En
otras palabras, son heterogneos.
En el pasado, se han propuesto una gran cantidad de
mtodos para resolver el problema de la integracin de
sistemas distribuidos mediante la eliminacin de la
heterogeneidad: "Vamos a armonizar, y todos los problemas
habrn desaparecido," "Vamos a sustituir todos los sistemas
con aplicaciones J2EE", "Vamos a usar CORBA en todas
partes", "Usemos serie MQ," y as sucesivamente. Pero todos
sabemos que estos mtodos no funcionan. Grandes sistemas
distribuidos con diferentes propietarios son heterogneos.
Esto es un hecho, y por lo tanto algo que debemos aceptar
la hora de disear soluciones distribuidas de gran tamao [3].
B. Modelos Usuales de SOA
Erl [2009] observa que todos los programas de software
acaban siendo compuestos, o bien residiendo en alguna forma
de combinacin arquitectnica de recursos, tecnologas y
plataformas (relacionadas con la infraestructura o no). Si nos
tomamos el tiempo para personalizar estos elementos
arquitectnicos, podemos establecer un ambiente refinado y
normalizado para la aplicacin de programas de software
tambin personalizados. El diseo intencional de la tecnologa

210 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
de arquitectura es muy importante para la computacin
orientada a servicios. Es esencial crear un entorno en el que los
servicios pueden ser recompuestos varias veces para maximizar
la realizacin de las necesidades de negocio. El beneficio
estratgico para personalizar el alcance, el contexto y los
lmites de una arquitectura es significativo. Para comprender
mejor los mecanismos bsicos de SOA, ahora tenemos que
estudiar los tipos ms comunes de las arquitecturas
tecnolgicas que existen.
Se presentan a continuacin, en la tabla 2, estos tipos de
arquitecturas tecnolgicas ms comunes, con sus
correspondientes definiciones.
TABLA 2. ARQUITECTURAS TECNOLGICAS MS COMUNES. ADAPTADO DE
[MICROSOFT CORP., 2003]
Trmino Definicin
Arquitectura de La arquitectura de un conjunto de servicios
Composicin de reunidos en composicin de servicios
Servicios
Arquitectura que soporta un conjunto de
Arquitectura de
Inventario
servicios relacionados que son
independientemente estandarizados y
de Servicios
gobernados
La arquitectura de la propia empresa (para
Arquitectura empresarial
cualquier tamao de empresa) orientada a
Orientada a Servicios
servicios
Arquitectura de Servicios
Se trata de la arquitectura de un nico
servicio
B.1. Arquitectura de servicios
La arquitectura de servicios es una arquitectura de
tecnologa limitada al diseo fsico de un programa de software
diseado como un servicio. Esta forma de arquitectura de la
tecnologa es comparable en alcance a una arquitectura de
componentes, excepto que se suele contar con una mayor
cantidad de extensiones de infraestructura para apoyar su
necesidad de aumentar la fiabilidad, el rendimiento, la
escalabilidad, la previsibilidad del comportamiento, y sobre
todo su necesidad de una mayor autonoma. El mbito de
aplicacin de una arquitectura de servicios tambin tender a
ser mayor debido a que un servicio puede, entre otras cosas,
abarcar mltiples componentes.
Considerando que no siempre fue comn documentar una
arquitectura diferente para cada componente en aplicaciones
distribuidas tradicionales, la importancia de la produccin de
servicios que deben existir como programas de software
independiente, muy autosuficiente y autnomo, requiere que
cada uno de ellos sea diseado de forma individual [8].
B.2. Arquitectura de Composicin de Servicios
El propsito fundamental de entregar una serie de servicios
independientes es que se puedan combinar en composiciones
de servicios totalmente funcionales capaces de automatizar las
tareas de negocio ms grandes y ms complejas.
Cada composicin de servicios tiene una arquitectura de
composicin de servicios correspondiente. De la misma
manera que una arquitectura de aplicacin para un sistema
distribuido incluye las definiciones de la arquitectura de sus
componentes individuales, esta forma de arquitectura abarca
las arquitecturas de servicio de todos los servicios que
participan.
Una arquitectura de composicin (especialmente una que
compone servicios que encapsulan sistemas heredados
dispares) puede ser comparado con una arquitectura de
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
integracin tradicional. Esta comparacin por lo general slo es
vlida parcialmente, ya que las consideraciones de diseo
destacadas por la orientacin a servicios aseguran que el diseo
de una composicin de servicios es muy diferente a la de las
aplicaciones integradas.
Por ejemplo, una diferencia en cmo se documentan las
arquitecturas de composicin tiene que ver con la medida de
detalle que estas incluyen acerca de los servicios reutilizables
que participan en la composicin. Debido a que estos tipos de
especificaciones de arquitecturas de servicios estn a menudo
protegidas (segn las necesidades planteadas por el principio
de abstraccin de Servicios), una arquitectura de composicin
slo podr hacer referencia a la interfaz tcnica y acuerdo de
nivel de servicio (SLA), publicado como parte del contrato
pblico de servicios [8].
B.3. Arquitectura de Inventario de Servicios
Un inventario de servicio es un conjunto de servicios
estandarizados y gobernados de manera independiente
entregados en arquitectura pre-definida.
Esta coleccin representa un alcance significativo que excede
el lmite de procesamiento de un nico proceso de negocio e
idealmente abarca numerosos procesos de negocio. El alcance
y los lmites de una arquitectura de inventario de servicio
pueden variar.
Idealmente, el inventario de servicios es primero modelado
conceptualmente, lo que lleva a la creacin de un modelo de
inventario de servicios. A menudo es este modelo el que
termina por definir el alcance del tipo de arquitectura
requerido, siendo referido como una arquitectura de inventario
de servicio.
Desde una perspectiva de diseo de la empresa, el inventario
de servicios puede representar un lmite concreto para la
implementacin de la arquitectura estandarizada. Esto significa
que debido a que los servicios dentro de un inventario estn
estandarizados, son las tecnologas y las extensiones
proporcionadas por la arquitectura subyacente.
El alcance de un inventario de servicio puede ser de toda la
empresa, o puede representar un dominio dentro de la empresa.
Por esa razn, a este tipo de arquitectura no se le llama
"arquitectura de dominio". Se relaciona con el alcance del
inventario, que puede abarcar mltiples dominios.
Es difcil comparar una arquitectura de inventario de servicios
con los tipos de arquitecturas tradicionales, porque el concepto
de un inventario no ha sido comn. El candidato ms cercano
sera una arquitectura de integracin que representa algn
segmento importante de una empresa. Sin embargo, esta
comparacin slo sera relevante en su alcance, ya que las
caractersticas del diseo orientado a servicios y los esfuerzos
de estandarizacin relacionados intentan convertir un
inventario de servicios en un entorno altamente homogneo
[8].
B.4. Arquitectura Empresarial Orientada a Servicios
Esta forma de arquitectura tecnolgica representa
prcticamente la totalidad de los servicios, composicin de
servicios y arquitecturas de inventario de servicios que residen
dentro de una empresa de IT especfica.
Una arquitectura orientada a servicios empresariales, es
comparable con una arquitectura tcnica empresarial
tradicional slo cuando la mayora o todos los entornos
tcnicos de la empresa estn orientados a servicios. De lo
contrario, puede ser simplemente una documentacin de las
211
partes de la empresa que han adoptado SOA, en cuyo caso
existe como un subconjunto de la tecnologa arquitectnica
empresarial.
En entornos de mltiples inventarios o en entornos en los
cuales los esfuerzos de estandarizacin no fueron un xito total,
una especificacin de arquitectura empresarial orientada a
servicios documentar todos los puntos de transformacin y la
disparidad de diseo que tambin pueda existir.
Adems, la arquitectura orientada a servicios empresarial
puede establecer estndares y convenciones de diseo que
apliquen a la totalidad de empresa que todos los servicios, la
composicin y las implementaciones de la arquitectura del
inventario deben cumplir [8].
C. Amazon Elastic Compute Cloud
C.1. Descripcin
Amazon Elastic Compute Cloud (Amazon EC2) es un
servicio web que proporciona capacidad informtica con
tamao modificable en la nube. Est diseado para facilitar a
los desarrolladores recursos informticos escalables y basados
en web.
Amazon EC2 reduce el tiempo necesario para obtener y
arrancar nuevas instancias de servidor en minutos, lo que
permite escalar rpidamente la capacidad, ya sea aumentndola
o reducindola, segn cambien sus necesidades. Amazon EC2
cambia el modelo econmico de la informtica, al permitir
pagar slo por la capacidad que utiliza realmente.
Amazon EC2 presenta un autntico entorno informtico
virtual, que permite utilizar interfaces de servicio web para
iniciar instancias con distintos sistemas operativos, cargarlas
con su entorno de aplicaciones personalizadas, gestionar sus
permisos de acceso a la red y ejecutar su imagen utilizando los
sistemas que desee [9].
C.2. Caractersticas principales
C.2.1. Elastic
Amazon EC2 permite aumentar o reducir la capacidad en
cuestin de minutos, sin esperar horas ni das. Puede enviar
una, cientos o incluso miles de instancias del servidor
simultneamente. Desde luego, como todo esta operacin se
controla con API de servicio Web, la aplicacin se escalar
(aumentar o disminuir su capacidad) dependiendo de sus
necesidades [9].
C.2.2. Totalmente controlado
Tendr control total sobre sus instancias. Tiene acceso de
usuario raz (root) a todas ellas, y puede interactuar con ellas
como con cualquier otra mquina. Puede detener su instancia y
mantener los datos en su particin de arranque, para reiniciar a
continuacin la misma instancia a travs de las API del servicio
web. Las instancias se pueden reiniciar de forma remota
mediante las API del servicio web. Asimismo, tiene acceso a la
emisin de consola de sus instancias [9].
C.2.3. Flexible
Tendr la posibilidad de elegir entre varios tipos de
instancia, sistemas operativos y paquetes de software. Amazon
EC2 permite seleccionar una configuracin de memoria, CPU,
almacenamiento de instancias y el tamao de la particin de
arranque ptimo para su sistema operativo y su aplicacin. Por
212 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
ejemplo, entre sus opciones de sistemas operativos se incluyen
varias distribuciones de Linux y Microsoft Windows Server.
C.2.4. Diseo pensado para su uso con otros Amazon Web
Services
Amazon EC2 trabaja con Amazon Simple Storage Service
(Amazon S3), Amazon Relational Database Service (Amazon
RDS), Amazon SimpleDB y Amazon Simple Queue Service
(Amazon SQS) para proporcionar una solucin informtica
completa, procesamiento de consultas y almacenamiento en
una gran gama de aplicaciones [9].
C.2.5. Fiable
Amazon EC2 ofrece un entorno muy fiable en el que las
instancias de sustitucin se pueden enviar con rapidez y
anticipacin. El servicio se ejecuta en los centros de datos y la
infraestructura de red acreditados de Amazon. El compromiso
del contrato a nivel de servicio de Amazon EC2 es de una
disponibilidad del 99,95% en cada Regin de Amazon EC2 [9].
C.2.6. Seguro
Amazon EC2 ofrece diversos mecanismos para proteger los
recursos informticos [9].
C.2.7. Interfaces de seguridad
Amazon EC2 incluye interfaces de servicio web para
configurar el cortafuegos (firewall) que controla el acceso de
red a grupos de instancias, y el acceso entre estos [9].
C.2.8. Instancias Aisladas
Al iniciar recursos de Amazon EC2 en Amazon Virtual
Private Cloud (Amazon VPC), puede aislar sus instancias
informticas especificando el rango de IP que desea utilizar, as
como conectarse a su infraestructura de IT existente mediante
la red cifrada IPsec VPN estndar del sector. Tambin puede
optar por lanzar instancias dedicadas en su VPC. Las instancias
dedicadas son instancias de Amazon EC2 que se ejecutan en
hardware dedicado a un nico cliente para ofrecer ms
aislamiento [9].
C.2.9. Econmico
Amazon EC2 permite disfrutar de las ventajas financieras
de Amazon. Pagar una tarifa muy baja por la capacidad
informtica que realmente utiliza. Consulte las Opciones de
compra de instancias de Amazon EC2 para obtener una
descripcin ms detallada [9].
C.2.10. Instancias en demanda
Con On-Demand Instances puede pagar por la capacidad
informtica por hora, sin compromisos a largo plazo. Esto le
liberar de los costes y las complejidades de la planificacin, la
compra y el mantenimiento del hardware y transformar lo que
normalmente son grandes costes fijos en costes variables
mucho ms pequeos. Gracias a On-Demand Instances
tambin se elimina la necesidad de comprar una "red de
seguridad" de capacidad para gestionar picos de trfico
peridicos [9].
C.2.11. Instancias reservadas
Las instancias reservadas ofrecen la opcin de realizar un
pago puntual reducido por cada instancia que desee reservar y
recibir a cambio un descuento importante en el cargo de uso
por horas de dicha instancia. Existen tres tipos de instancias
reservadas (instancias reservadas de utilizacin ligera, mediana
e intensa) que permiten equilibrar el importe del pago
anticipado a realizar con su precio por hora efectivo. Est a su
disposicin el Marketplace de instancias reservadas, que le
ofrece la oportunidad de vender instancias reservadas si
cambian sus necesidades (p. ej., si desea transferir instancias a
una nueva regin de AWS, pasar a un tipo de instancia nuevo o
vender capacidad para proyectos que finalizan antes de que
expire el plazo de su instancia reservada) [9].
C.2.12. Instancias puntuales
Con las instancias puntuales, los clientes pueden ofertar la
capacidad sin utilizar de Amazon EC2 y ejecutar dichas
instancias mientras su oferta supere el precio puntual. El precio
puntual cambia peridicamente segn la oferta y la demanda, y
los clientes cuyas ofertas alcancen o superen dicho precio
tendrn acceso a las instancias puntuales disponibles. Si es
flexible respecto a cundo ejecutar sus aplicaciones, las
instancias puntuales pueden reducir significativamente sus
costes de Amazon EC2 [9].
C.3. Amazon CloudWatch (autoescalabilidad)
Amazon CloudWatch proporciona la supervisin de los
recursos de la nube de AWS y de las aplicaciones que los
clientes ejecutan en AWS. Los desarrolladores y
administradores de sistema la utilizan para recopilar mtricas y
realizar su seguimiento, obtener conocimientos y reaccionar
inmediatamente para que sus aplicaciones y empresas sigan
funcionando sin problemas. Amazon CloudWatch supervisa
recursos de AWS como las instancias de bases de datos de
Amazon EC2 y Amazon RDS, y tambin puede supervisar
mtricas personalizadas generadas por las aplicaciones y los
servicios de un cliente. Con Amazon CloudWatch, obtendr
una visibilidad para todo el sistema de la utilizacin de
recursos, el rendimiento de las aplicaciones y el estado de
funcionamiento.
Amazon CloudWatch le permite supervisar las instancias
de Amazon EC2, volmenes de Amazon EBS, Elastic Load
Balancers y las instancias de bases de datos de Amazon RDS
en tiempo real. Mtricas como la utilizacin de la CPU, la
latencia y los recuentos de solicitudes se proporcionan
automticamente para estos recursos de AWS [10].
C.4. Blueprints / Imgenes para acelerar el aprovisionamiento
Amazon denomina AMIs a sus Blueprints o imgenes
para acelerar y facilitar el aprovisionamiento de instancias en la
nube. Una mquina de imagen Amazon (AMI) es un tipo
especial de sistema operativo pre-configurado y software de
aplicaciones virtualizadas que se utiliza para crear una mquina
virtual en el Amazon Elastic Compute Cloud (EC2). Adems,
es la unidad bsica de la implementacin de los servicios
prestados mediante EC2.
La plataforma Elastic Compute Cloud cuenta con ms de
2200 imgenes de mquinas virtuales alternativas, con
diferentes sistemas operativos, aplicativos y configuraciones.
Una de las configuraciones ms populares cuenta con un
sistema operativo Ubuntu y software de base LAMP
(Linux, Apache, MySQL y PHP).
Adems, las instancias de AMIs se pueden filtrar por
Proveedor (Ej. IBM, Oracle, Amazon Web Services, Sun
Microsystems, Novell, Microsoft o Community), por Regin
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
(fsica), por Arquitectura (i386, x86_64), por Root Device
Type (Elastic block Store, instance-store) or Platform (Ubuntu,
Red Hat, Fedora, Windows, Debian, etc.) [11].
C.5. Amazon EC2 con Microsoft Windows Server y SQL Server
Amazon EC2 con Microsoft Windows Server (ediciones
2003 R2, 2008, 2008 R2 y 2012) es un entorno rpido y fiable
para implementar aplicaciones con Microsoft Web Platform,
incluidos ASP.NET, ASP.NET AJAX, Silverlight e Internet
Information Server (IIS). Amazon EC2 permite ejecutar
cualquier solucin compatible basada en Windows en la
plataforma informtica en la nube de AWS, que ofrece alto
rendimiento, fiabilidad y rentabilidad. Entre los casos prcticos
de uso habitual con Windows se incluye el alojamiento de
aplicaciones empresariales basadas en Windows, alojamiento
de sitios web y de servicios web, procesamiento de datos,
transcodificacin de medios, pruebas distribuidas, alojamiento
de aplicaciones en ASP.NET y cualquier otra aplicacin que
requiera software de Windows. Amazon EC2 tambin es
compatible con las bases de datos SQL Server Express, SQL
Web y SQL Standard y, adems, pone estas ofertas a
disposicin de sus clientes con tarifas por horas.
Amazon EC2 ejecutndose sobre Windows Server
proporciona una integracin perfecta con funciones existentes
en Amazon EC2, como por ejemplo Amazon Elastic Block
Store (EBS), Amazon CloudWatch, Elastic Load Balancing y
Elastic IP. Las instancias de Windows estn disponibles en
varias zonas de disponibilidad en todas las regiones.
La capa de uso gratuito de AWS incluye instancias de
Amazon EC2 que se ejecutan en Microsoft Windows Server.
Los clientes que renen los requisitos para incluirse dentro de
la capa de uso gratuito de AWS pueden utilizar hasta 750 horas
al mes de instancias de t1.micro que se ejecutan en Microsoft
Windows Server de manera gratuita [12].
C.6. Soporte para Sistemas operativos Linux
La AMI de Amazon Linux es una imagen de Linux
mantenida y soportada que ofrece Amazon Web Services para
su uso en Amazon Elastic Compute Cloud (Amazon EC2).
Est diseada para proporcionar un entorno de ejecucin
estable, seguro y de alto rendimiento para aplicaciones que se
ejecuten en Amazon EC2. Tambin incluye paquetes que
permiten una fcil integracin con AWS, incluidas
herramientas de configuracin de inicio y muchas bibliotecas y
herramientas populares de AWS. Amazon Web Services
tambin proporciona actualizaciones continuas de seguridad y
mantenimiento para todas las instancias ejecutadas en la AMI
de Amazon Linux. La AMI de Amazon Linux se proporciona
sin cargo adicional a los usuarios de Amazon EC2 [13].
C.7. Soporte para almacenamiento de datos
Amazon Simple Storage Service (Amazon S3): Amazon S3
es almacenamiento para Internet. Est diseado para facilitar a
los desarrolladores recursos informticos escalables basados en
la Web.
Amazon S3 proporciona una sencilla interfaz de servicios
web que puede utilizarse para almacenar y recuperar la
cantidad de datos que desee, cuando desee y desde cualquier
parte de la Web. Concede acceso a todos los desarrolladores a
la misma infraestructura econmica, altamente escalable,
fiable, segura y rpida que utiliza Amazon para tener en
funcionamiento su propia red internacional de sitios web. Este
213
servicio tiene como fin maximizar las ventajas del escalado y
trasladar estas ventajas a los desarrolladores [14].
C.7.1. Amazon Relational Database Service (Amazon RDS)
(beta)
Amazon Relational Database Service (Amazon RDS) es un
servicio web que facilita las tareas de configuracin, utilizacin
y escalado de una base de datos relacional en la nube.
Proporciona capacidad rentable y de tamao modificable y, al
mismo tiempo, gestiona las tediosas tareas de administracin
de la base de datos, lo que le permite centrarse en sus
aplicaciones y en su negocio.
Amazon RDS le permite acceder a todas las funciones de
un motor de base de datos MySQL, Oracle o Microsoft SQL
Server conocido. Esto supone que el cdigo, las aplicaciones y
las herramientas que ya utiliza en la actualidad con sus bases
de datos existentes funcionarn a la perfeccin con Amazon
RDS [15].
C.7.2. Amazon SimpleDB (beta)
Amazon SimpleDB es un almacn de datos no relacionales
de alta disponibilidad y flexible que descarga el trabajo de
administracin de bases de datos. Los desarrolladores
simplemente almacenan elementos de datos y los consultan
mediante solicitudes de servicios Web; Amazon SimpleDB se
encarga del resto.
Sin las limitaciones impuestas por las bases de datos
relacionales, Amazon SimpleDB est optimizado para ofrecer
alta disponibilidad y flexibilidad con poca o ninguna carga
administrativa. La labor de Amazon SimpleDB pasa
inadvertida: se encarga de crear y gestionar varias rplicas de
sus datos y las distribuye geogrficamente para permitir alta
disponibilidad y capacidad de duracin. El servicio slo le
cobra los recursos realmente consumidos en almacenamiento
de los datos y en distribucin de las solicitudes. Es posible
cambiar el modelo de datos sobre la marcha, y el sistema
indexa los datos automticamente por usted [16].
C.8. Soporte para Colas
Amazon Simple Queue Service (Amazon SQS) ofrece un
sistema de gestin de colas fiable y ampliable para almacenar
mensajes a medida que se transfieren entre sistemas. Mediante
Amazon SQS, los desarrolladores pueden transferir datos entre
componentes distribuidos de aplicaciones que realizan distintas
tareas, sin perder mensajes y sin necesidad de que cada
componente est siempre disponible. Amazon SQS facilita la
tarea de creacin de un flujo de trabajo automatizado,
trabajando en estrecha conexin con Amazon Elastic Compute
Cloud (Amazon EC2) y el resto de los servicios web de la
infraestructura de AWS.
Amazon SQS funciona utilizando la infraestructura de
gestin de mensajes a escala web de Amazon como un servicio
web. Cualquier sistema de Internet puede aadir o leer
mensajes sin tener instalado ningn software ni configuracin
de cortafuegos especial. Los componentes de las aplicaciones
que utilizan Amazon SQS se pueden ejecutar
independientemente y no es necesario que estn en la misma
red, que se hayan desarrollado con las mismas tecnologas ni
que se ejecuten a la vez [17].
214 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
C.9. Alternativas de Hipervisor
Amazon EC2 actualmente utiliza una versin altamente
personalizada del hipervisor Xen, aprovechando la
paravirtualizacin. Como los huspedes ("Guest") para-
virtualizados se basan en el hipervisor para proporcionar apoyo
a las operaciones que normalmente requieren un acceso
privilegiado, es posible ejecutar el sistema operativo invitado
sin acceso elevado a la CPU [18].
D. Windows Azure
D.1. Descripcin
Windows Azure es una plataforma de nube abierta y
flexible que permite compilar, implementar y administrar
aplicaciones rpidamente en una red global de centros de datos
administrados por Microsoft. Puede compilar aplicaciones en
cualquier lenguaje, herramienta o marco, permitiendo adems
integrar sus aplicaciones de nube pblicas con el entorno de TI
existente [19].
D.2. Caractersticas Principales
D.2.1. Siempre Disponible
Disponibilidad 24x7x365 [19].
D.2.2. Alto nivel de servicio
Windows Azure entrega un Contrato de nivel de servicio
mensual del 99,95 % que permite compilar y ejecutar
aplicaciones de alta disponibilidad sin importar la
infraestructura. Proporciona revisiones automticas del Sistema
Operativo y de los servicios, equilibrio de carga de red
integrado y resistencia ante errores de hardware. Admite un
modelo de implementacin con el que se puede actualizar una
aplicacin sin inactividad (downtime) [19].
D.2.3. Abierto
Windows Azure permite utilizar cualquier lenguaje, marco
o herramienta para crear aplicaciones. Las caractersticas y los
servicios se exponen utilizando protocolos REST abiertos. Las
bibliotecas de cliente de Windows Azure estn disponibles
para varios lenguajes de programacin, se comercializan bajo
una licencia de cdigo abierto y se hospedan en GitHub [19].
D.2.4. Servidores ilimitados, almacenamiento ilimitado
Windows Azure permite escalar aplicaciones a cualquier
tamao con facilidad. Es una plataforma de autoservicio
totalmente automatizada que permite el aprovisionamiento de
recursos en cuestin de minutos. El uso de recursos aumenta o
disminuye de manera flexible en funcin de las necesidades.
Solo se pagan los recursos que usa la aplicacin. Windows
Azure est disponible en varios centros de datos del mundo, lo
que permite implementar las aplicaciones cerca de los clientes
[19].
D.2.5. Gran capacidad
Windows Azure proporciona una plataforma flexible en la
nube que puede satisfacer los requisitos de cualquier
aplicacin. Permite hospedar y ampliar el cdigo de aplicacin
dentro de roles de proceso de un modo totalmente confiable.
Los datos se pueden almacenar en bases de datos SQL
relacionales, almacenes de tablas NoSQL y almacenes de blobs
no estructurados, y existe la opcin de usar la funcionalidad de
Hadoop e inteligencia empresarial para la minera de datos.
Puede aprovechar la slida funcionalidad de mensajera de
Windows Azure para habilitar aplicaciones distribuidas
escalables, as como para entregar soluciones hbridas que se
ejecuten en la nube y en un entorno empresarial local [19].
D.2.6. Cache distribuida y CDN
Los servicios de cach distribuida y red de entrega de
contenido (CDN) de Windows Azure permiten reducir la
latencia y ofrecer aplicaciones con un gran rendimiento en
cualquier lugar del mundo [19].
D.3. Autoescalabilidad
El "Bloque de Aplicacin Autoescalable" puede escalar
automticamente su aplicacin de Windows Azure basado en
reglas definidas especficamente para su aplicacin. Puede
utilizar estas reglas para ayudar a la aplicacin de Windows
Azure a mantener su rendimiento en respuesta a los cambios en
la carga de trabajo, y al mismo tiempo controlar los costos
asociados con el alojamiento de su aplicacin en Windows
Azure. Junto con la escalabilidad, aumentando o disminuyendo
el nmero de instancias de rol (working role) en su aplicacin,
el bloque tambin permite utilizar otras medidas de
escalabilidad tales como funcionalidades determinadas de
estrangulamiento ("throttling") dentro de la aplicacin o el uso
de las acciones definidas por el usuario.
Brinda adems la posibilidad de optar por implementar el
bloque en un rol de Windows Azure o en una aplicacin
interna.
El Bloque de Aplicacin Autoescalable forma parte del
Pack de la Enterprise Library 5.0 de Microsoft Integration para
Windows Azure. El bloque utiliza dos tipos de reglas para
definir el comportamiento automtico de escalabilidad para su
aplicacin:
Reglas de restricciones: Para establecer los lmites superior
e inferior en el nmero de instancias, por ejemplo, digamos que
8:00-10:00 todos los das quiere un mnimo de cuatro y un
mximo de seis instancias, se utiliza una regla de restriccin.
Reglas Reactivas: Para permitir que el nmero de instancias
de rol puedan cambiar en respuesta a los cambios
impredecibles en la demanda, se utilizan reglas reactivas [20].
D.4. Blueprints / Imgenes para acelerar el aprovisionamiento
Las mquinas virtuales entregadas a demanda ofrecen una
infraestructura de computacin escalable cuando se necesita
aprovisionar rpidamente recursos para satisfacer las
necesidades de un negocio en crecimiento. Es posible obtener
mquinas virtuales de los sistemas operativos Linux y
Windows Server en mltiples configuraciones.
Los blueprints de Windows Azure ofrecen la posibilidad de
desbloquear la cartera de TI y la infraestructura de suministro
al ritmo que su negocio requiere. Para ello, simplemente hay
que elegir la configuracin deseada (instancias de memoria
estndar o alta) y seleccionar una imagen de la galera de
imgenes de mquinas virtuales.
Las Mquinas virtuales de Windows Azure ofrecen a los
sistemas y aplicaciones la posibilidad de mover los discos
duros virtuales (VHD) desde las instalaciones locales a la nube
(y viceversa) [21].
D.5. Soporte para Sistemas operativos Microsoft Windows
Si usted se est preguntando si el cdigo va a ser diferente,
ya que se ejecuta en la nube, o si vas a tener que aprender un
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
nuevo marco (traducido del trmino en ingls "framework"), la
respuesta es "no". Continuar escribiendo cdigo que se
ejecuta en Windows Server. El marco de. NET (3.5 SP1) se
instala por defecto en todas las mquinas, y el cdigo
ASP.NET tpico funcionar. Es tambin posible utilizar el
soporte FastCGI para correr cualquier marco que soporte
FastCGI (como PHP, Ruby on Rails, Python, etc). Si dispone
de cdigo nativo o binario, tambin puede ejecutarlo [22].
Cada hipervisor administra varios sistemas operativos
virtuales. Todos ellos corren el sistema operativo Windows
Server compatible con 2008. En realidad, no se nota ninguna
diferencia entre ejecutar un Windows Server 2008 y estas
mquinas. Las nicas diferencias son algunas optimizaciones
especficas para el hipervisor en el cual estn corriendo [22].
Bajo qu sistema operativo estar corriendo su cdigo en
Windows Azure? Incluso con toda esta discusin sobre el
funcionamiento del sistema y las optimizaciones de integracin
con el hipervisor, la mayora de los desarrolladores slo se
preocupan por el entorno en el cual corrern sus aplicaciones
(el sistema operativo). La respuesta es simple: Las aplicaciones
corren en Windows Server 2008 x64 Enterprise Edition.Bueno,
casi. Microsoft lo llama "sistema operativo 2008 compatible
con Windows Server", que se refiere al hecho de que se trata de
Windows Server en casi todos los aspectos, excepto en algunos
cambios de bajo nivel para optimizar el hipervisor. Sin
embargo, las aplicaciones estn abstradas varias capas lejos de
estos cambios, y no deben notar nada distinto respecto de su
ejecucin en una mquina Windows Server normal [22].
D.6. Soporte para Sistemas operativos Linux
Crear una mquina virtual que ejecute el sistema operativo
Linux en Windows Azure es fcil por medio de la Galera de
imgenes (blueprints) utilizando el Portal de administracin. Es
tambin posible acceder a las instancias de estas mquinas
virtuales Linux para personalizarlas a gusto, por medio de un
usuario con privilegios de adminsitrador ("Root").
Es tambin factible implementar En Azure mquinas
virtuales ya disponibles que corren sistemas operativos Linux,
por ejemplo con instancias de mquinas virtuales vmWare.
Para esto, solo es necesario convertir la imagen de la mquina
virtual Linux al formato de Windows Azure (de .vmx a .vmdk),
para luego subirla a nuestra cuenta Azure por medio del
administrador de imgenes personalizadas de Windows Azure.
Algunas de las distribuciones del Sistema operativo Linux
que soporta Windows Azure, inclusive proporcionando
blueprints para acelerar el aprovisionamiento de las mquinas
virtuales son las siguientes [21]:
openSUSE 12.3
SUSE Linux Enterprise Server 11 Service Pack 2
Ubuntu Server 12.04 LTS
Ubuntu Server 12.10
Ubuntu Server 13.04
OpenLogic CentOS 6.3
Ubuntu Server 12.10 DAILY
D.7. Soporte para almacenamiento de datos
D.7.1. SQL Server en mquinas virtuales de Windows Azure
Cuando las aplicaciones requieren funcionalidad completa
de SQL Server, Mquinas virtuales es la solucin ideal.
Encontrar ofertas de imgenes de SQL Server 2012 y SQL
215
Server 2008 R2, en sus ediciones Standard, Web y Enterprise.
Si tiene una licencia de SQL Server con Software Assurance,
como ventaja adicional puede trasladar la licencia existente a
Windows Azure y pagar solo por proceso y almacenamiento.
La ejecucin de SQL Server en Mquinas virtuales es una
solucin adecuada en los escenarios siguientes:
Para desarrollar y probar nuevas aplicaciones de SQL
Server rpidamente No es necesario esperar semanas para el
aprovisionamiento local de hardware, sino que basta con captar
la imagen de SQL Server correcta en la galera de imgenes.
Puede optar por realizar la implementacin en un entorno de
produccin o local con poco esfuerzo.
Para hospedar aplicaciones de SQL Server de nivel 2 y
nivel 3 existentes Gracias a los distintos tamaos de VM entre
los que elegir y dada la compatibilidad total con SQL Server,
es posible trasladar las aplicaciones de SQL Server locales
existentes y disfrutar de la eficacia de la computacin en la
nube.
Para realizar copias de seguridad y restauraciones de bases
de datos locales Es posible realizar la copia de seguridad de
una base de datos local en un almacenamiento en blobs de
Windows Azure y poder as restaurar la base de datos en una
mquina virtual de Windows Azure en caso de que sea
necesaria la recuperacin ante desastres en el entorno local.
Para ampliar aplicaciones locales Cree aplicaciones
hbridas que utilicen activos locales y mquinas virtuales de
Windows Azure para disfrutar de una mayor eficacia y alcance
global.
Para crear aplicaciones de varias capas en la nube Cree una
aplicacin de varias capas que utilice la funcionalidad de
escalado nica del servicio Base de datos SQL para la capa de
aplicacin y que aproveche la compatibilidad completa de SQL
Server en Mquinas virtuales de Windows Azure para la capa
de base de datos [23].
D.7.2. Base de datos SQL
Para aquellas aplicaciones que necesitan una base de datos
relacional completamente funcional como servicio, Windows
Azure ofrece la base de datos SQL, antes denominada Base de
datos de SQL Azure. La base de datos SQL ofrece un alto nivel
de interoperabilidad, lo que permite a los clientes crear
aplicaciones en la mayora de los principales marcos de
desarrollo. Adems, la base de datos SQL, basada en las
tecnologas probadas de SQL Server, permite utilizar los
conocimientos y la experiencia existente para reducir el tiempo
de solucin, as como crear o ampliar aplicaciones entre los
sistemas locales y la nube [24].
Use la base de datos SQL para:
D.7.3. Tablas
Las tablas ofrecen funcionalidad NoSQL para las
aplicaciones que requieren el almacenamiento de grandes
cantidades de datos no estructurados. Las tablas son un servicio
administrado con certificacin ISO 27001 que se pueden
escalar automticamente para satisfacer un rendimiento y
volumen masivos de hasta 100 terabytes, accesibles
prcticamente desde cualquier lugar a travs de REST y las
API administradas [24].
D.7.4. Blob no estructurado
Los blobs son el modo ms sencillo de almacenar grandes
cantidades de texto no estructurado o datos binarios tales como
216 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
vdeo, audio e imgenes. Los blobs son un servicio
administrado con certificacin ISO 27001 que se pueden
escalar automticamente para satisfacer un rendimiento y
volumen masivos de hasta 100 terabytes, accesibles
prcticamente desde cualquier lugar a travs de REST y las
API administradas [24].
D.8. Soporte para colas
El bus de servicio de Colas soporta un modelo de
comunicacin de mensajera negociado.Cuando se utilizan
colas, los componentes de una aplicacin distribuida no se
comunican directamente entre s, en cambio, intercambian
mensajes via una cola, lo cual acta como un intermediario. Un
productor de mensajes (remitente) enva un mensaje a la cola y
continua su procesamiento. Asincrnicamente, un consumidor
de mensajes (receptor) obtiene el mensaje de la cola y lo
procesa. El productor no tiene que esperar una respuesta por
parte del consumidor para poder continuar el proceso y enviar
ms mensajes. Las colas ofrecen la implementacin de la
tcnica "primero que entra, primero que sale" (modelo
conocido por sus siglas en ingls como "FIFO") enviando
mensajes a uno o ms consumidores que compiten por el
tratamiento del mensaje. Es decir, los mensajes suelen ser
recibidos y procesador por los receptores en el orden en que
fueron aadidos a la cola, y cada mensaje es recibido y
procesado por un nico consumidor [25].
D.9. Alternativas de Hipervisor
En 2006/2007, un equipo dirigido por Dave Cutler (el padre
de Windows NT) comenz a trabajar en un nuevo hipervisor
pensado para ser optimizado para el centro de datos. Este
hipervisor se bas en los siguientes tres principios:
D.9.1. Rpido
El hipervisor de Windows Azure ha sido diseado para ser
lo ms eficiente posible. Gran parte de esto se consigue a travs
de optimizaciones de bajo nivel realizadas a la vieja usanza,
tales como empujar cargas de trabajo al hardware siempre que
sea posible. Puesto que Windows Azure controla el hardware
en sus centros de datos, puede confiar en la presencia de
caractersticas de hardware, a diferencia de hipervisores
genricos diseados para un mercado ms amplio [22].
D.9.2. Pequeo
El hipervisor es construido para ser claro y directo, y no
incluye aquellas caractersticas que no estn directamente
relacionadas con la nube. Menor cantidad de cdigo no slo
significa un mejor rendimiento, sino que tambin significa
menos cdigo para corregir o actualizar [22].
D.9.3. Estrechamente integrado con el ncleo
En Windows Azure, el kernel del sistema operativo que se
ejecuta en el hipervisor est altamente optimizado para el
hipervisor.
Con Windows Server 2008, Microsoft lanz un hipervisor
llamado Hyper-V. A menudo hay confusin sobre las
diferencias entre Hyper-V y el hipervisor de Windows Azure, y
algunos libros / artculos a menudo asumen que se trata del
mismo hipervisor.
En realidad, ambos son diferentes y estn construidos
tambin con diferentes propsitos. Hyper-V es entregado como
parte de Windows, y est destinado para funcionar en una
amplia variedad de hardware para una amplia variedad de
propsitos. El hipervisor de Windows Azure se ejecuta slo en
los centros de datos de Microsoft, y se ha optimizado
especficamente para el hardware que se ejecuta en Windows
Azure.
Como era de esperar con dos productos similares de la
misma empresa, no hay intercambio de cdigo y diseo. En el
futuro, las nuevas caractersticas del hipervisor de Windows
Azure tendrn influencias en Hyper-V, y viceversa [22].
E. Google App Engine
E.1. Descripcin
Google App Engine permite crear y alojar aplicaciones web
en los mismos sistemas escalables con los que funcionan las
aplicaciones de Google. Google App Engine ofrece procesos
de desarrollo y de implementacin rpidos, y una
administracin sencilla, sin necesidad de preocuparse por el
hardware, las revisiones o las copias de seguridad y una
ampliacin sin esfuerzos.
Las aplicaciones Google App Engine son fciles de crear,
fciles de mantener y fciles de escalar a medida que el trfico
y las necesidades de almacenamiento de datos crecen. Con App
Engine no es necesario mantener ningn servidor. Basta con
cargar su aplicacin y esta ya se encontrar lista para servir a
los usuarios [26].
E.2. Caractersticas Principales
E.2.1. Rpido para iniciar
Sin necesidad de comprar ni mantener ningn software o
hardware, puede prototipar y desplegar aplicaciones
disponibles para los usuarios en cuestin de horas [27].
E.2.2. Fcil de usar
Google App Engine incluye las herramientas necesarias
para crear, probar, ejecutar y actualizar sus aplicaciones [27].
E.2.3. Conjunto rico de APIs
Google App Engine provee un conjunto rico de APIs de
servicios de fcil uso, permitiendo cerar servicios rpidamente
[27].
E.2.4. Escalabilidad Inmediata
No hay prcticamente ningn lmite respecto de qu tan
alto o qu tan rpido su aplicacin pueda escalar [27].
E.2.5. Modelo de negocio de pago por uso
Pague por lo que usa, comenzando sin ningn costo inicial.
Pagar slo por los recursos que su aplicacin utilice a medida
que crece [27].
E.2.6. Infraestructura probada
Google App Engine utiliza la misma tecnologa probada
que alberga otras aplicaciones de Google, ofreciendo
automticamente escalabilidad sin problemas. Preocuparse por
las configuraciones de servidor y balanceo de carga se
convierte en una cosa del pasado, ya que los expertos de
Google manejan la supervisin del sistema [27].
E.3. Autoescalabilidad
Google App Engine est diseado para alojar aplicaciones
con muchos usuarios simultneos. Cuando una aplicacin
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
puede servir a muchos usuarios simultneos sin degradar su
rendimiento, se dice que es escalable. Las aplicaciones escritas
para App Engine escalan automticamente. A medida que ms
personas utilizan la aplicacin, App Engine asigna ms
recursos para la aplicacin y administra el uso de esos recursos.
La aplicacin en s no necesita saber nada acerca de los
recursos que utiliza [27].
E.4. Soporte para Sistemas operativos Linux
Las aplicaciones se ejecutan en un entorno seguro que
proporciona un acceso limitado al sistema operativo
subyacente. Estas limitaciones permiten que App Engine
distribuya peticiones web para la aplicacin en varios
servidores, as como tambin iniciar y detener los servidores
para satisfacer las demandas de trfico. La caja de arena
(traduccin literal del trmino en ingls "Sandbox") asla la
aplicacin en su propio entorno seguro y confiable que es
independiente del hardware, sistema operativo y la ubicacin
fsica del servidor web.
Ejemplos de las limitaciones de acceso al sistema operativo
incluyen:
Una aplicacin slo puede acceder a otros ordenadores
situados en internet a travs de la URL proporcionada y/o por
medio de servicios de correo electrnico. Otros equipos slo se
pueden conectar a la aplicacin realizando peticiones HTTP (o
HTTPS) en los puertos estndar.
Las aplicaciones no pueden escribir en el sistema de
archivos en ninguno de los entornos de ejecucin. Una
aplicacin puede leer archivos, pero slo los archivos subidos
con el cdigo de la aplicacin. La aplicacin debe utilizar el
almacn de datos de App Engine, memcache u otros servicios
para aquellos datos que se persisten entre las peticiones.
El cdigo de aplicacin slo se ejecuta en respuesta a una
peticin de web, una tarea en cola, o una tarea programada, y
debe devolver datos de respuesta dentro de 60 segundos en
cualquier caso. Un controlador de solicitudes no se puede
generar un sub-proceso o ejecutar cdigo despus de que la
respuesta haya sido enviada [28].
E.5. Soporte para almacenamiento de datos
El almacenamiento de datos de una aplicacin web
escalable puede ser complicado. Un usuario puede interactuar
con cualquiera de las docenas de servidores web en un
momento dado, y la siguiente peticin del usuario podra ir a
un servidor web diferente a la anterior solicitud. Todos los
servidores web deben interactuar con los datos, que tambin se
extienden a travs de docenas de mquinas, posiblemente en
diferentes lugares del mundo.
Con Google App Engine, no es necesario preocuparse por
nada de eso. La infraestructura de App Engine se encarga de
toda la distribucin, la replicacin y el equilibrio de carga de
los datos detrs de una sencilla API-y se obtiene un motor de
bsqueda de gran alcance, garantizando tambin las
transacciones.
El repositorio de datos de App Engine y el almacn de
datos de alta replicacin (HRD) utilizan el algoritmo Paxos
para replicar datos a travs de mltiples centros de datos. Los
datos se escriben en el almacn de datos en objetos conocidos
como entidades. Cada entidad tiene una clave que identifica de
manera nica. Una entidad puede designar opcionalmente otra
entidad como su matriz, la primera entidad es un hijo de la
entidad matriz. Las entidades en el almacn de datos forman
217
as un espacio de estructura jerrquica similar a la estructura de
directorios de un sistema de archivos.
El almacn de datos es extremadamente resistente frente a
fallos catastrficos, sin embargo, garantizar la consistencia
puede ser bastante diferente de lo que usted est familiarizado.
Las entidades que descienden de un antepasado comn se dice
que pertenecen a un mismo grupo de entidades, las llaves de su
ancestro comn es la clave principal del grupo, que sirve para
identificar a todo el grupo. Las consultas en una nica entidad
de su grupo, llamado consultas de antepasados, hacen
referencia a la clave principal en lugar de la clave de una
entidad especfica. Los grupos de entidad son una unidad de
consistencia y transaccionalidad: mientras que las consultas
sobre mltiples grupos de entidades pueden devolver
resultados viciados, eventualmente consistentes, aquellas
limitadas a un nico grupo de entidad siempre retornan
actualizadas, produciendo resultados muy consistentes [29].
E.6. Soporte para colas
Una aplicacin puede realizar tareas adems de responder a
solicitudes web. Las aplicaciones implementadas en Google
App Engine pueden ejecutar estas tareas siguiendo la
programacin que se configure, por ejemplo, cada da o cada
hora. Asimismo, es posible ejecutar tareas que ella misma ha
aadido a una cola, como una tarea en segundo plano creada
durante el procesamiento de una solicitud.
Las tareas programadas tambin se conocen como "tareas
cron", administradas por el servicio cron.
Las colas de tareas se incluyen actualmente como una
funcin experimental. En este momento, solo el entorno de
tiempo de ejecucin Python puede utilizar colas de tareas. Se
incluir una interfaz de cola de tareas para aplicaciones Java en
poco tiempo.
Con el API de la cola de tareas, las aplicaciones pueden
realizar fuera de solicitudes de usuario trabajos que se han
iniciado dentro de ellas. Si una aplicacin necesita ejecutar
algn trabajo en segundo plano, puede utilizar el API de la cola
de tareas para organizarlo en pequeas unidades discretas
llamadas tareas. A continuacin, la aplicacin inserta estas
tareas en una o ms colas. App Engine detecta
automticamente nuevas tareas y las ejecuta cuando los
recursos del sistema lo permiten [28].
E.7. Alternativas de Hipervisor
Google App Engine brinda muy escasa informacin acerca
del hipervisor que utiliza, ya que no es posible cambiarlo o
utilizar otro, dado que el servicio que brinda App Engine es
PaaS (plataforma como servicio, por sus siglas en ingls
Platform as a Service), motivo por el cual no es posible
administrar la infraestructura, sino que esta se encuentra
subyacente y transparente para el usuario de la plataforma.
F. Red Hat Open Shift
F.1. Descripcin
OpenShift es la oferta de plataforma como servicio para
Computacin en la nube de Red Hat.
En esta plataforma los desarrolladores de aplicaciones
pueden construir, desplegar, probar y correr sus aplicaciones.
Prporciona espacio en disco, recursos de CPU, memoria,
conectividad de red y un servidor Apache o JBoss.
Dependiendo del tipo de aplicacin que se est construyendo,
tambin proporciona acceso a una plantilla de sistema de
218 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
archivos para esos tipos (por ejemplo PHP, Python y
Ruby/Rails).
Tambin proporciona herramientas de desarrollo integradas
para apoyar el ciclo de vida de las aplicaciones, incluyendo la
integracin de Eclipse, JBoss Developer Studio, Jenkins,
Maven y GIT. OpenShift utiliza un ecosistema de cdigo
abierto para proporcionar servicios clave de la plataforma de
aplicaciones mviles (Appcelerator), servicios NoSQL
(MongoDB), servicios de SQL (PostgreSQL, MySQL), y ms.
JBoss proporciona una plataforma de middleware empresarial
para aplicaciones Java, proporcionando apoyo para Java EE6 y
servicios integrados tales como transacciones y mensajes, que
son fundamentales para las aplicaciones empresariales [30].
F.2. Caractersticas Principales
F.2.1. Prestacin de servicios de aplicacin acelerada
La plataforma OpenShift mejora la productividad y la
agilidad de los desarrolladores de aplicaciones vinculada con el
retraso relacionado con los servidores, sistemas operativos,
middleware y aprovisionamiento mediante aplicaciones de
auto-servicio y a la carta. Este aumento de la productividad,
junto con una normalizacin del desarrollo del ciclo de vida de
aplicacin de flujo de trabajo, permitir la aceleracin de la
entrega de servicios de aplicaciones. Esto aumenta eficazmente
la velocidad de las TI [31].
F.2.2. Dependencia minimizada con el proveedor
Al ser construida sobre una pila de tecnologas de cdigo
abierto, la plataforma OpenShift est diseada para
proporcionar libertad de eleccin, incluyendo la libertad de
elegir alejarse de las PaaS. Para lograr esto, dentro de la
plataforma OpenShift solo se utilizan lenguajes de cdigo
abierto y frameworks sin alteraciones. No se utilizan APIs,
tecnologas o recursos privados. Esto asegura la portabilidad de
aplicaciones de la plataforma OpenShift, evitando as las
dependencias con los proveedores de tecnologa utilizada por la
plataforma PaaS OpenShift [31].
F.2.3. Pilas de aplicaciones de autoservicio y en demanda
Al permitir a los desarrolladores desplegar rpida y
fcilmente las pilas de aplicaciones, la plataforma OpenShift
puede aumentar la productividad y fomentar la innovacin en
el diseo y la entrega de aplicaciones. Las nuevas ideas pueden
ser prototipos rpidamente y proyectos de misin crtica
pueden ser llevados al mercado ms rpidamente [31].
F.2.4. Flujos de trabajo estandarizados para Desarrolladores
[Red Hat Inc., 2013b.] OpenShift como plataforma de
aplicaciones cloud permite que la organizacin de desarrollo de
aplicaciones pueda normalizar el flujo de trabajo del
programador, y crear procesos repetibles para la entrega de
aplicaciones para agilizar todo el proceso [31].
F.2.5. Polglota
Eleccin de los lenguajes de programacin y los softwares
de base. La capacidad de los desarrolladores para elegir entre
Java, Ruby, Node.JS, Python, PHP y Perl en la plataforma
OpenShift les permite elegir la herramienta adecuada para el
trabajo, y hacer una eleccin diferente para cada proyecto,
segn sea necesario. Adems de estos y otros lenguajes de
cdigo abierto, muchos de los marcos de cdigo abierto
populares se incluyen tambin dentro de OpenShift. Algunos
ejemplos incluyen Rails, Django, EE6, Spring, Play, Sinatra y
Zend [31].
F.2.6. Aplicaciones empresariales con Java EE6
Ser capaz de desplegar aplicaciones Java EE6 en JBoss
EAP funcionando en OpenShift permite que muchos
departamentos de TI que se han estandarizado con Java EE
puedan migrar sus aplicaciones legadas a la nube sin necesidad
de aplicar reingeniera al cdigo o a la arquitectura [31].
F.2.7. Servicios de base de datos incorporados
Con las opciones de tecnologa de bases de datos
disponibles en OpenShift y la capacidad de tener estas
instancias de bases de datos conectadas automticamente a las
pilas de aplicacin segn sea necesario, los desarrolladores y
arquitectos de la empresa pueden elegir entre los almacenes de
datos relacionales clsicos y los modernos NoSQL [31].
F.2.8. Sistema de cartucho Extensible para agregar servicios
Adems de la funcin de idiomas y servicios, los
desarrolladores pueden aadir otro idioma, base de datos o
componentes de middleware que necesitan a travs del sistema
de cartuchos OpenShift personalizable. Esta extensibilidad
Cartucho permite a los desarrolladores (y operaciones)
extender las PaaS para soportar los estndares o requisitos
especficos de la empresa [31].
F.2.9. Soporte para mltiples entornos (desarrollo / Pruebas /
Produccin)
Con la capacidad de la plataforma OpenShift para soportar
mltiples ambientes del ciclo de vida de desarrollo de las
aplicaciones (como Desarrollo, Calidad, Pre-Produccin y
Produccin), las empresas pueden adoptar e implementar la
plataforma PaaS (Platform As A Service) OpenShift sin
necesidad de cambiar sus metodologas o procesos actuales
[31].
F.2.10. Dependencia y Gestin de la Construccin
La plataforma OpenShift incluye Dependencia y gestin de
la Construccin para muchos de los lenguajes de programacin
ms populares, incluyendo Bundler para Ruby, NPM para
Node.JS y Maven para Java. Estas herramientas automatizan el
proceso de identificacin de las dependencias en el cdigo
fuente, y la construccin de la aplicacin completa. Estas
caractersticas incrementan la productividad y reducen la
posibilidad de error, volvindose crticas en una plataforma de
aplicaciones de nube como PaaS [31].
F.2.11. Integracin Continua y Gestin de Versiones
La plataforma OpenShift incluye Jenkins para integracin
continua y gestin de lanzamiento. Jenkins puede realizar
pruebas cuando se sube cdigo al repositorio, organizar el
proceso de construccin, y promover o cancelar
automticamente una versin de la aplicacin dependiendo de
los resultados de las pruebas. Esta gestin automatizada de los
releases se convierte en una parte fundamental para simplificar
el desarrollo de aplicaciones [31].
F.2.12. Gestin de versiones de cdigo fuente
La plataforma OpenShift incluye el control distribuido de
versiones Git y un sistema de gestin de cdigo fuente. El
protocolo Git asegurado con SSH es utilizado por los
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
desarrolladores para comprobar el cdigo en el repositorio Git
seguro que reside dentro de su contenedor de aplicaciones con
OpenShift. Git permite tanto la gestin rpida, segura y
controlada de origen de la aplicacin de control de versiones de
cdigo [31].
F.2.13. Inicio de sesin Remoto por SSH al contenedor de
aplicaciones
La arquitectura nica basada en SELinux de la plataforma
OpenShift permite a los usuarios (desarrolladores u
operadores) que inicien sesin remotamente en contenedores
de aplicaciones individuales para las aplicaciones
implementadas en las PaaS. El usuario registrado podr ver
solamente sus procesos, sistema de archivos y archivos de
registro. Esto le da a los usuarios el acceso que necesitan para
una mejor arquitectura y administracin de sus aplicaciones
[31].
F.2.14. Integracin con IDE
Con integracin incorporada con Eclipse de la plataforma
de OpenShift, JBoss Developer Studio y Titanium Studio,
muchos desarrolladores pueden permanecer completamente
dentro del IDE con el cual se sientan cmodos a la hora de
trabajar con OpenShift [31].
F.2.15. Lnea de comandos enriquecida
Para desarrolladores que prefieren trabajar desde la lnea de
comandos, la plataforma OpenShift incluye un amplio conjunto
de herramientas de lnea de comandos que proporcionan acceso
completo a la interfaz del programador de las PaaS. Estas
herramientas son fciles de usar, as como secuencias de
comandos para las interacciones automatizadas [31].
F.2.16. Desarrollo de aplicaciones mviles
A travs de una asociacin con Appcelerator, la plataforma
OpenShift incluye una estrecha integracin con Titanium
Studio IDE mvil que permite el desarrollo de aplicaciones
mviles en la nube con respaldo para Android o iOS que
pueden ser ejecutados por aplicaciones de servidor que se
ejecutan en OpenShift [31].
F.2.17. Redundancia de componentes del sistema para alta
disponibilidad
La plataforma OpenShift posee una arquitectura con un
plano de control sin estado (stateless Brokers), una
infraestructura de mensajera, e infraestructura de alojamiento
de aplicaciones (nodos). Cada pieza de la plataforma se puede
configurar con redundancia mltiple para conmutacin por
error y equilibrio de carga escenarios para eliminar el impacto
de fallo de hardware o infraestructura [31].
F.2.18. Aprovisionamiento automtico de la pila de
aplicaciones
Cuando un desarrollador utiliza la plataforma OpenShift de
autoservicio para crear una aplicacin, OpenShift crear
automticamente los engranajes necesarios, desplegar los
runtimes del lenguaje (a travs de cartridges), configurar las
interfaces de red y la prestacin de los ajustes del DNS y,
finalmente, retornar al usuario las credenciales que necesitar
para comenzar a subir el cdigo para la aplicacin. Este
aprovisionamiento automtico reemplaza lo que histricamente
podra tomar das, semanas o incluso meses para el equipo de
219
operaciones de TI para hacerlo manualmente. Esto libera al
equipo de operaciones para centrarse en las necesidades crticas
de los clientes en lugar de ocuparse en la configuracin de
servidores de forma repetida [31].
F.2.19. Escalabilidad automtica de aplicacin
La plataforma OpenShift permite elasticidad cloud,
proporcionando escalabilidad de aplicacin horizontal
automtica a medida que aumenta la carga de aplicaciones,
eliminando la necesidad de Operaciones para aumentar
manualmente el nmero de instancias de aplicacin [31].
F.2.20. Eleccin de la infraestructura de nube (No disponible
en OpenShift Online)
OpenShift empresarial est diseado para ser desplegado en
la capa superior, y se ejecuta en Red Hat Enterprise Linux
(RHEL). RHEL es necesario debido a la utilizacin de
SELinux dentro de la plataforma OpenShift, y permite adems
brindar Servicios de Soporte Global de Red Hat proveer
soporte a las PaaS y a los runtimes y bibliotecas incluidas.
OpenShift empresarial no tiene requisitos especficos para la
capa de infraestructura aparte de que debe ser capaz de proveer
instancias de RHEL. Para ello, los clientes OpenShift
empresarial tienen la opcin de infraestructura. Los clientes de
la platasforma como servicios de OpenShift empresarial
cuentan con opciones de infrasestructura, pudiendo
implementar la solucin mediante servidores fsicos, mediante
una plataforma de virtualizacin, una Infraestructura como
servicio, o un proveedor de nube pblica, siempre y cuando las
instancias de RHEL puedan ser configuradas y accedidas, se
pueden implementar. Esto otorga la libertad de implementar la
solucin PaaS de OpenShift empresarial en la forma que mejor
se ajuste a sus opciones de infraestructura existentes [31].
F.3. Autoescalabilidad
Por defecto, cuando se crea una aplicacin OpenShift, es
automticamente escalada basndose en la cantidad de
peticiones (del ingls request). OpenShift tambin permite
escalar manualmente las aplicaciones ajustando los umbrales
mnimos y mximos permitidos para escalar [32].
Cmo funciona la escalabilidad de OpenShift: El cartucho
HAProxy se sienta entre la aplicacin y el Internet pblico y
las rutas de trfico web a sus cartuchos web. Cuando aumenta
el trfico, HAProxy notifica a los servidores OpenShift que
necesita capacidad adicional. OpenShift Chequea que tenga
disponibilidad (de los tres engranajes libres) y luego crea otra
copia de su cartucho web en ese nuevo equipo. El cdigo en el
repositorio git se copia en cada nuevo equipo, pero el directorio
de datos comienza vaco. Cuando se inicia el nuevo cartucho
de copia realizar los procedimientos necesarios y el proxy de
alta disponibilidad (del ingls High availability Proxy, de
acrnimo "HAProxy") comenzar a realizar el enrutamiento de
las peticiones web al mismo.
El algoritmo para la escalabilidad hacia arriba y hacia abajo
(expansin y decremento) se basa en el nmero de solicitudes
simultneas a su aplicacin. OpenShift asigna 10 conexiones
por equipo. Si el HAProxy ve que la aplicacin est
sosteniendo el 90% de su capacidad mxima, aade otra
instancia. Si la demanda cae un 50% de su capacidad mxima
durante varios minutos, HAProxy elimina dicha instancia.
Debido a que cada cartucho es "nada compartido", si desea
compartir datos entre los cartuchos puede utilizar un cartucho
220 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
de base de datos. Cada uno de los engranajes creados durante la
escala tiene acceso a la base de datos y puede leer y escribir
datos consistentemente.
OpenShift, en su plan de expansin y crecimiento, pretende
aadir ms capacidades como almacenamiento compartido,
bases de datos a escala, y el almacenamiento en cach
compartida.
La consola web OpenShift muestra cuntas instancias estn
actualmente siendo consumidas por la aplicacin [33].
F.4. Blueprints / Imgenes para acelerar el aprovisionamiento
En OpenShift se crean aplicaciones y las aplicaciones se
componen de equipos (o instancias). Por razones de
simplicidad, es conveniente pensar en un equipo como un
usuario con un directorio raz y su propio contexto.
Las instancias son lo que ponemos dentro de su equipo para
que sean tiles. Si desea utilizar PHP, usted necesitar un
cartucho de PHP. Si desea utilizar Jboss, deber hacer uso del
cartucho Jboss [34].
OpenShift funciona nicamente con el sistema operativo
Red Hat Enterprise Linux en su versin 6.3 (o superior) para
las plataformas de hardware x86 o bien x64. A la fecha de
creacin de este documento no es factible correr OpenShift
bajo otro sistema operativo [35].
F.5. Soporte para almacenamiento de datos
Las aplicaciones online de OpenShift soportan diferentes
motores de bases de datos. Entre ellos podemos mencionr a
MySQL 5.1, PostgreSQL 8.4, MongoDB 2.2 y SQLite.
Tanto MySQL como PostgreSQL son motores de bases de
datos relacionales tradicionales basadas en el lenguaje de
consultas SQL [36].
SQLite, en cambio, es una base de datos que se implementa
simplemente en una librera transaccional tambin basada en
una base de datos SQL que no requiere configuracin alguna
[37].
Adems, MongoDB es una base de datos documental
OpenSource, de tipo NoSQL, escrita en lenguaje C++ que est
principalmente orientada al almacenamiento de documentos
basados en formato JSON y tcnicas de Map-Reduce [38].
F.6. Soporte para colas
Red Hat OpenShift ofrece soporte para colas de mensajera
con el producto IronMQ [39].
IronMQ es un servicio de colas de mensajera fcil de usar
y de alta disponibilidad. IronMQ est construido para distribuir
aplicaciones en la nube con necesidades de mensajera crticos.
Proporciona colas de mensajes en demanda con el transporte
HTTPS, entrega FIFO, y persistencia de mensajes, con
rendimiento optimizado en la nube [40].
F.6.1.Caractersticas principales
F.6.1.1. Listo para usar
Slo tiene que conectar IronMQ a los puntos finales (del
ingls "endpoints") y ya est listo para crear colas y enviar y
recibir mensajes. Perfecto para hacer mucho ms cosas de
forma asncrona.
F.6.1.2. Alta disponibilidad
Se ejecuta sobre infraestructuras de nube y utiliza mltiples
centros de datos de alta disponibilidad. Utiliza almacenes de
datos fiables para la durabilidad y persistencia de sus mensajes.
F.6.1.3. Rendimiento escalable / Alto
Escrito con la elasticidad y la escalabilidad en su ncleo.
Construido con lenguajes de alto rendimiento diseados para la
concurrencia, se ejecuta en las nubes de potencia industrial.
F.6.1.4. Mltiples enlaces de lenguaje
Hace uso de un amplio conjunto de bibliotecas de idiomas
IronMQ como Ruby, PHP, Python, Java, Go, y mucho ms.
Gateways Seguros / OAuth2: Utiliza HTTPS y SSL para
proporcionar pasarelas (del ingls "gateways") seguras para la
gestin de colas y mensajes. OAuth2 proporciona flexibilidad,
escalabilidad y seguridad.
F.7. Alternativas de Hipervisor
Si bien OpenShift ofrece tres alternativas para el uso de
hipervisores. Estas son KVM (Kernel-Based Virtual Machine),
Xen y Qemu. Esta plataforma no ofrece soporte para
virtualizadores de Microsoft como Hyper-V, lo cual implica
limitaciones para la implementacin de Sistemas operativos
basados en Kernels Windows.
Las instalaciones tpicas de OpenShift se realizan con el
hipervisor KVM [41].
G. IBM SmartCloud
G.1. Descripcin
SmartCloud ofrece una gestin de cloud con el valor
agregado que permite la eleccin y la automatizacin ms all
del aprovisionamiento de mquinas virtuales.
IBM SmartCloud Enterprise+ es un entorno Cloud seguro,
totalmente administrado y listo para produccin, diseado para
garantizar una alta performance y disponibilidad.
SmartCloud Enterprise+ ofrece un control completo de
"governance", administracin y gestin, permitiendo definir
acuerdos de nivel de servicio (SLA) para alinear las
necesidades de negocio y los requisitos de uso.
Ofrece adems mltiples opciones de seguridad y
aislamiento, integrados en la infraestructura virtual y de red,
manteniendo el cloud separado de otros entornos cloud [42].
G.2. Caractersticas Principales
PureApplication System soporta mltiples virtualizadores.
Es posible virtualizar, por ejemplo, con VMWare o Hyper-V.
Los usuarios pueden autogestionar los recursos que
necesitan (patterns de aplicacin, requerimientos de
disponibilidad, CPU, memoria, storage, etc) y el sistema realiza
el deployment y el accounting automticamente.
Es posible definir polticas para las aplicaciones de manera
que los recursos que esta insume sean elsticos, es decir, que
crezcan o disminuyan de acuerdo con las variaciones de la
demanda.
Datagrid provisto por WebSphere eXtreme Scale, que se
integra con PureApplication System. Ofrece un datagrid
distribuido, manejando la peristencia y la transaccionalidad.
Adems, opcionalmente soporta la sincronizacin con una
fuente de datos.
WSX brinda una API simple y poderosa para manipular los
datos del grid, permitiendo que sean accedidos por REST o
directamente por conector nativo ADO.NET para las
aplicaciones C#.
Los servicios de PureApplication System son diferenciales
conceptualmente con respecto a los servicios provistos por los
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
otros clouds vendors mencionados, puesto que se implementa
en un appliance. PureApplication System, que integra la
funcionalidad de Cloud, de virtualizacin de aplicaciones y de
datagrid, funciona todo en una misma "caja" (hardware)
provista por IBM.
G.3. Autoescalabilidad
Obtener aplicaciones basadas en WebSphere rpidamente
en la nube con el Servicio de Carga de Trabajo de aplicacin de
IBM SmartCloud: El Servicio de Carga de Trabajo de
aplicacin (SCAWS) de IBM SmartCloud elimina el tedio de
la gestin de middleware y de infraestructura, lo que permite
implementar ms fcil, rpida y repetidamente aplicaciones
basadas en WebSphere para la nube pblica de IBM
SmartCloud Enterprise [43].
Acelerar y simplificar la llegada a la nube con patrones:
Como ncleo de la tecnologa PaaS de IBM y construido en los
aos de experiencia de IBM, los patrones son plantillas que
consisten en software y recursos de la mquina virtual. Los
patrones simplifican radicalmente la configuracin y gestin de
los recursos de hardware y software, lo que permite a los
equipos implementar rpidamente entornos de aplicaciones
complejas para la nube con resultados validados, de alta
calidad y consistentes [43].
Escale las Aplicaciones con escalabilidad automatizada
basada en polticas: Los patrones tienen polticas para
proporcionar automatizacin de gran alcance, incluyendo una
poltica de enrutamiento para el balanceo de cargas, una
poltica de registro, una poltica de JVM, y una poltica de
escalabilidad basada en reglas automatizadas. Al establecer la
poltica de ampliacin, un patrn desplegado puede escalar de
forma dinmica en funcin de las reglas (por ejemplo, sobre la
base de tiempo de respuesta de solicitud) [43].
Rpido aprovisionamiento y escalabilidad: Con el
aprovisionamiento de IBM SmartCloud, las organizaciones de
TI pueden implementar rpidamente el tipo especfico de
entorno cloud que necesitan sin importar el tamao, para
empezar a tomar ventaja del aumento de la flexibilidad y el
rendimiento que ofrece el cloud computing. En cualquier
momento, la nube se puede escalar rpidamente hacia arriba o
hacia abajo segn sea necesario, para ayudar a las
organizaciones a satisfacer las necesidades cambiantes de TI
sin interrumpir las operaciones.
Despliegue de cientos de mquinas virtuales en menos de
cinco minutos: El aprovisionamiento de IBM SmartCloud
permite a las organizaciones tomar ventaja inmediata de la
mayor flexibilidad y rendimiento que ofrece el cloud
computing. Al acelerar la entrega de los recursos informticos,
a su vez acelera la entrega de productos y servicios
innovadores, lo que permite una respuesta ms rpida a los
retos y oportunidades del mercado.
El aprovisionamiento de IBM SmartCloud permite un
rpido despliegue y la integracin de las capacidades de la
nube utilizando patrones de carga de trabajo. Los patrones
pueden ser creados utilizando un patrn suministrado como
una plantilla o bien se pueden crear desde cero. Una vez creado
un patrn, se puede reutilizar una y otra vez para crear varias
instancias idnticas en la nube. Se puede lograr una integracin
significativa con componentes de middleware y recursos de
infraestructura para optimizar los componentes para un tipo
particular de carga de trabajo de la aplicacin. Capacidades
dinmicas y elsticas se realizan plenamente. El sistema puede
221
crear o eliminar recursos adicionales segn sea requerido por la
demanda de la aplicacin [44].
G.3.1. Caractersticas destacadas
Reducir los costos y la complejidad al permitir solicitudes
de autoservicio y automatizacin de las operaciones
Obtener una rpida escalabilidad para satisfacer el
crecimiento del negocio con un despliegue casi instantneo de
cientos de mquinas virtuales
Evitar los proveedores de tecnologa mediante la creacin
de cargas de trabajo en la nubes optimizadas para entornos
heterogneos
Acelerar las implementaciones de aplicaciones utilizando
los patrones de carga de trabajo repetibles
Optimizar los entornos virtualizados con la gestin del
ciclo de vida y anlisis de imagen avanzada
Con herramientas como la Biblioteca Virtual de imagen,
Construccin de Imagen y Composicin (ICONO), y el Editor
de diseos, El aprovisionamiento de IBM SmartCloud ayuda a
las organizaciones a gestionar la expansin de imagen, velar
por el cumplimiento, crear imgenes base, automatizar la
instalacin de software y crear patrones repetibles. Esta
amplitud de capacidades ayuda a asegurar que las
organizaciones no slo puedan crear entornos de nube
robustos, sino que tambin puedan controlar y gestionar estos
entornos.
Implementaciones aceleradas con los patrones de carga de
trabajo reutilizables: El aprovosionamiento de IBM
SmartCloud ayuda a las organizaciones a desarrollar fcil y
rpidamente, y probar y desplegar aplicaciones de negocio,
poniendo fin a la utilizacin de los procesos manuales,
procesos complejos o aquellos que requieren mucho tiempo
asociado a la creacin de entornos de aplicacin. Una vez que
las solicitudes han completado sus tareas, los recursos retornan
automticamente al administrador de recursos compartidos.
Esta solucin tambin gestiona usuarios individuales y accesos
grupales, dando a los administradores de TI el tipo correcto de
los controles de acceso con niveles de eficiencia ptimos [44].
G.4. Soporte para Sistemas operativos Microsoft Windows y
Linux
El aprovisionamiento de IBM SmartCloud ofrece una nica
plataforma de gestin a lo largo de las diferentes
infraestructuras, ayudando a reducir la complejidad y el coste
de las operaciones. Permite el diseo y despliegue de
aplicaciones compuestas consistentes y repetibles en una nube
de hardware virtualizado ejecutando cualquiera de los
hipervisores soportados, incluyendo Linux en IBM System z,
mquinas virtuales basada en el kernel (KVM), Xen, Microsoft
Hyper-V, IBM PowerVM e IBM z/VM. Integra cmupto,
almacenamiento de red y distribucin de aplicaciones para
ayudar a permitir la integracin organizacional. Adems, ayuda
a reducir los costos de licencias y hardware con su soporte para
mltiples hipervisores y gestin de entornos mixtos [44].
G.5. Soporte para almacenamiento de datos
G.5.1. IBM SONAS 1.3
21 Petabytes de almacenamiento con rendimiento escalable
y accesible a nivel global
Proporciona escalabilidad extrema para ajustarse a la
capacidad de crecimiento, satisfaciendo a las aplicaciones
hambrientas de ancho de banda con rendimiento escalable.
222 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
TCO hasta en un 40 por ciento inferior con la gestin del
ciclo de vida y la migracin automatizada en cinta
Ofrece la opcin de puerta de enlace (del ingls "gateway")
con los para sistemas de discos IBM XIV e IBM Storwize
V7000 [45].
G.5.2. IBM Storwize V7000 Unified
Sistema de almacenamiento virtualizado construido para
complementar los entornos de servidores virtualizados.
Proporcionar hasta 200 por ciento de mejora en el
rendimiento con la migracin automtica de las unidades de
estado slido de alto rendimiento (SSD) [46].
Habilita el almacenamiento de hasta cinco veces los datos
primarios ms activos en el mismo espacio fsico en disco
utilizando Real-time Compression [46].
Consolida el bloque y el almacenamiento de archivos para
simplificar, obteniendo una mayor eficiencia y facilidad de
gestin [46].
Habilita la disponibilidad casi continua de las aplicaciones
a travs de la migracin dinmica [46].
Gestin de datos diseada para que sea fcil de usar, con
una interfaz grfica de usuario y sistema de gestin con la
capacidad "apuntar y hacer clic" [46].
Metro Mirror y Global Mirror para la replicacin de datos
sncrona o asncrona entre sistemas para la eficiencia del
backup [46].
SSD para aplicaciones que requieren alta velocidad y
acceso rpido a los datos [46].
RAID 0, 1, 5, 6 y 10 [46].
G.5.3. IBM XIV Storage Systems Gen3
IBM XIV es un sistema de almacenamiento en disco de alta
gama que permite a miles de empresas hacer frente al desafo
creado por el crecimiento sorprendente de datos. IBM XIV
ofrece un alto rendimiento de punto de acceso y facilidad de
uso para el cambio de juego. Por agilidad ptima en entornos
de nube, IBM XIV ofrece un escalado simple, altos niveles de
servicio para cargas de trabajo dinmicas, heterogneas y una
estrecha integracin con hipervisores, as como tambin con la
plataforma OpenStack [47].
Almacenamiento en disco virtualizado con hasta 3 terabytes
de espacio.
Un sistema revolucionario, probado, de alta gama de
almacenamiento en disco diseado para el crecimiento de los
datos y una incomparable facilidad de uso
Alto Rendimiento uniforme, logrado a travs de
paralelismo masivo y ajuste automtico
Almacenamiento virtualizado, fcil aprovisionamiento y
agilidad extrema para la nube optimizada y entornos virtuales
Opcin de aumento de rendimiento adicional a travs del
manejo libre de almacenamiento en cach SSD
Alta fiabilidad y disponibilidad a travs de la redundancia
completa, velocidad de reconstruccin sin precedentes
TCO bajo permitido por el almacenamiento de alta
densidad, la planificacin simplificada, las caractersticas de la
gratuidad y la gestin bajo-touch [47].
G.6. Soporte para colas
El bus de Integracin de IBM (antes conocido como
WebSphere Message Broker) es un bus de servicios
empresariales (ESB) que proporciona conectividad y
transformacin de datos universal para la arquitectura orientada
a servicios (SOA) y entornos no SOA. Ahora las empresas de
cualquier tamao pueden eliminar las conexiones punto a
punto y procesamiento por lotes, independientemente de la
plataforma, protocolo o formato de datos [48].
Con IBM Integration Bus es posible: Utilizar las capacidades
robustas para hacer frente a los diferentes requisitos de
integracin para satisfacer las necesidades de cualquier tamao
de proyecto.
Ayudar a toda su organizacin a tomar decisiones ms
inteligentes de negocios, proporcionando un rpido acceso,
visibilidad y el control sobre los datos que fluyen a travs de
sus aplicaciones empresariales y sistemas.
Conectar toda una serie de aplicaciones heterogneas y
servicios web, eliminando necesidades complejos de
conectividad de punto a punto.
Contar con el soporte de aplicaciones y servicios de
Microsoft.
Proporcionar una base de integracin estandarizada,
simplificada y flexible para ayudarle con mayor rapidez y
facilidad a apoyar las necesidades del negocio y escalar con el
crecimiento del negocio [48].
G.7. Alternativas de Hipervisor
IBM Systems Director es la columna vertebral de la
plataforma de gestin para lograr una computacin inteligente.
Un componente integral de la cartera de Sistemas de IBM,
IBM Systems Director permite la integration con Tivoli y
plataformas de gestin de terceros, proviendo componentse
para los servicios de gestin integrados. Con Systems Director
puede:
Automatizar las operaciones del centro de datos mediante
la implementacin de infraestructuras virtuales cloud-ready
Unificar la gestin de los recursos fsicos y virtuales,
almacenamiento y redes, para los servidores IBM
Simplificar la gestin de los sistemas optimizados
Lograr una visin nica de la utilizacin real de energa a
travs de su centro de datos
Gestin del ciclo de vida simple de las cargas de trabajo
con un uso intuitivo y reduccin de la complejidad - IBM
Systems Director ofrece una plataforma unificada integral de
gestin de sistemas. Proporciona herramientas para el
descubrimiento, el inventario, el estado, la configuracin,
notificacin de eventos de salud del sistema, monitoreo de los
recursos, actualizaciones del sistema y la automatizacin de la
gestin.
Integracin - Tivoli y plataformas de gestin de terceros
proporcionan la base para la gestin integrada de los servicios
de virtualizacin. Con una amplia gama de tareas disponibles
en la plataforma de gestin y las herramientas automatizadas,
Director asiste al personal de gestin de sistemas en el aumento
de la productividad, lo que resulta en una mayor capacidad de
respuesta y servicio [49].
El valor de la clave de IBM Systems Director es su
capacidad para trabajar en diferentes entornos de TI. Reduce
drsticamente el nmero de herramientas de gestin e
interfaces, simplificando la forma en que los administradores
de TI realizan sus tareas, y la liberacin de su tiempo para
satisfacer las cambiantes necesidades del negocio [49].
IBM Systems Director VMControl: gestin de
infraestructuras fsicas y virtuales lista parra la nube.
IBM Systems Director VMControl le ayuda a obtener ms de
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
la infraestructura de virtualizacin, con una gestin lista para la
nube. La combinacin de IBM Systems Director y VMControl
le permite reducir el coste total de propiedad de su entorno
virtualizado - servidores, almacenamiento y redes - al
disminuir los costes de gestin, aumentando la utilizacin de
activos, y la vinculacin de rendimiento de la infraestructura de
los objetivos de negocio [49].
VMControl simplifica la gestin de los entornos virtuales a
travs de mltiples tecnologas de virtualizacin y plataformas
de hardware. VMControl es una solucin de gestin de
virtualizacin multi-plataforma lder que se incluye con
ediciones de IBM Systems Director, disponibles por separado o
como un plug-in para IBM Systems Director. Esta diversidad
de opciones de despliegue le permite seleccionar el nivel
ptimo de funcionalidad de VMControl (Express, Standard o
Enterprise) para su infraestructura virtualizada y para escalar
sin problemas a medida que la misma evoluciona [49].
G.7.1. Caractersticas destacadas
Rene la gestin fsica y virtual en una interfaz nica para
reducir la complejidad
Ofrece una inigualable plataforma cruzada para la gestin
de mltiples sistemas operativos, lo que ayuda a mejorar la
prestacin de servicios mediante la eliminacin de silos
aislados de virtualizacin en entornos heterogneos.
Proporciona un "time-to-value" ms rpido, y una mayor
agilidad del negocio a travs de la gestin de la virtualizacin
simplificada que permite una utilizacin ms eficaz de los
recursos virtualizados.
Establece una precisin y consistencia repetibles gracias a
la automatizacin.
Reduce los costos operativos y de infraestructura a travs
de una mayor eficiencia y utilizacin de los recursos [49].
G.8. Soporte para Datagrids
WebSphere eXtreme Scale proporciona almacenamiento
esencial en cach de objetos distribuido para entornos de nube
de prxima generacin y escalabilidad elstica [50].
El Software de IBM WebSphere eXtreme Scale
proporciona un marco cach escalable de alto rendimiento y
tecnologa de redes. WebSphere eXtreme Scale proporciona
una mayor calidad de servicio en entornos de computacin de
alto rendimiento a travs de "caching elstico". El Caching
elstico mejora el rendimiento y la rentabilidad de la inversin
[50].
WebSphere eXtreme Scale es una herramienta esencial para
la escalabilidad elstica y ofrece estos valiosos beneficios:
Procesa grandes volmenes de transacciones con extrema
eficiencia y escalabilidad lineal.
Construye rpidamente una rejilla elstica transparente,
flexible y de alta disponibilidad que escala acorde a las
necesidades de las aplicaciones, eliminando los lmites de
rendimiento de la base de datos.
Proporciona alta disponibilidad y seguridad con copias
redundantes de datos de la cach. Dispone de esquemas de
autenticacin que ayudan a garantizar la seguridad del sistema.
Permite a los sistemas de back-end existentes soportar una
cantidad significativamente mayor de aplicaciones, lo que
reduce el coste total de propiedad (del ingls "Total cost of
ownership", por sus siglas TCO) [50].
223
H. VMware VCloud Suite vCloud Suite incluye VMware vCloud Automation Center, que
introduce un potente modelo de aprovisionamiento de servicios
H.1. Descripcin de TI gestionados en rgimen de autoservicio a travs de un
La virtualizacin ha reducido los costos de IT portal seguro y fcil de usar controlado mediante polticas.
dramticamente, mejorando la eficiencia en gran medida. Las redes definidas por software permiten a las mquinas
Ahora las unidades de negocio necesitan un acceso rpido a los virtuales de una cloud de VMware utilizar los recursos en
recursos de IT para lograr mayor eficiencia en el "time to cualquier lugar del centro de datos, sin importar los lmites de
market" de los proyectos. VMware vCloud Suite es una las redes. Adems, con VMware vCloud Connector, el equipo
solucin de infraestructura integral y completa que simplifica de TI puede estar preparado para una demanda inesperada,
las operaciones de IT ofreciendo mejores SLAs para las recurriendo a clouds pblicas de confianza, fuera de sus
aplicaciones. Ayuda adems a mejorar la agilidad, la eficiencia instalaciones, basadas en VMware cuando sea preciso [52].
y a realizar una gestin inteligente de la administracin de
operaciones de computacin en la nube [51].
Qu es VMware vCloud Suite?: La virtualizacin de
VMware ha ayudado a los clientes a reducir drsticamente los
gastos de capital gracias a la consolidacin de servidores. Ha
mejorado los gastos de explotacin mediante la automatizacin
y ha minimizado la prdida de ingresos porque reduce el
tiempo de inactividad, planificado y no planificado. Sin
embargo, las empresas actuales tambin necesitan reducir el
tiempo de comercializacin de sus productos y servicios. Las
unidades de negocio exigen acceso rpido a los recursos de TI
y a las aplicaciones. Se presenta a continuacin (Figura 4), la
solucin para la nube propuesta por VMware, y tambin un
cuadro que define las responsabilidades de cada uno de los
productos para la gestin e infraestructura de la nube (Figura 5)
[52].

Fig. 5. Responsabilidades de productos [52].

H.2.2. Simplifique y automatice la gestin de operaciones

Fig. 4. Solucin completa e integrada en la nube [52].
H.2. Caractersticas Principales
H.2.1. Agilice el acceso a los recursos y a las aplicaciones
vCloud Suite permite a los tcnicos de TI prestar servicios
de TI controlados por polticas en rgimen de autoservicio, as
como aprovisionar mquinas virtuales y aplicaciones de
mltiples niveles en solo unos minutos. Adems, ampla la
capacidad disponible para las
unidades de negocio tanto de forma interna como externa.
A medida que el centro de datos se convierte en una cloud
privada o hbrida, la gestin de operaciones cobra una
importancia fundamental. Un entorno gil proporciona
escalabilidad elastica y permite un cambio constante de las
cargas de trabajo. Para respaldar de manera proactiva a la
empresa, el departamento de TI necesita planificacin
inteligente de la capacidad, solucin automatizada de los
problemas de rendimiento y gestin continua del cumplimiento
normativo. vCloud Suite incluye las completas prestaciones de
gestin de TI de vCenter Operations Management. La
supervisin del rendimiento y las alertas proactivas garantizan
que el departamento de TI pueda reaccionar a los desafos de
cumplimiento de los acuerdos de nivel de servicio en la cloud
antes de que lleguen a afectar al negocio [52].

224 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
H.2.3. Mejores acuerdos de nivel de servicio para todas las
aplicaciones
Adems de proporcionar agilidad a los propietarios de los
negocios y de realizar una gestin ptima de los recursos del
centro de datos, se espera que los equipos de TI aporten los
acuerdos de nivel de servicio de rendimiento, seguridad y
recuperacin ante desastres que la empresa necesita [52].
H.2.4. Infraestructura de la nube:
Aprovisionamiento e implementacin automatizados.
Forme nuevas aplicaciones con componentes reutilizables e
implemntelas en minutos, no semanas.
Administracin automatizada de operaciones. Administre
su nube en forma eficiente con herramientas desarrolladas
especialmente para optimizar el rendimiento, asegurar la
seguridad y rectificar problemas potenciales antes de que los
usuarios se enteren siquiera.
Disponibilidad, recuperacin ante desastres y cumplimiento
normativo. Suministre acuerdos exigentes de nivel de servicio,
proteja sus datos y verifique el cumplimiento de polticas y
regulaciones.
Visibilidad de los costos del departamento de TI. Planifique
la capacidad, optimice la asignacin de recursos y desarrolle un
modelo de cobro retroactivo de gastos completo para el
departamento de TI con sensatez.
Capacidad completa de extensibilidad. Personalice su
entorno, integre soluciones de terceros e interopere con los
servicios de computacin en nube pblica regidos por VMware
[53].
H.2.5. Operaciones en la nube
Servicios segn demanda: Implemente un nuevo modelo de
autoservicio para reducir los costos del departamento de TI y
aumentar la agilidad [53].
H.2.6. Implementacin y aprovisionamiento automatizados
Revolucione el cumplimiento de los pedidos, el desarrollo
de aplicaciones y los procesos de implementacin para generar
gran eficiencia.
Administracin anticipativa de problemas e permite que se cumplan los niveles de servicio mediante el
incidentes. Aproveche la administracin segn polticas y la
automatizacin para eliminar los procesos manuales propensos
a errores y administrar los sistemas anticipndose a los
problemas.
Administracin de riesgo, el cumplimiento normativo y la
seguridad: proteja su negocio asegurando estndares de nivel
empresarial para la manera en que se protegen los sistemas en
todo su entorno de nube.
Administracin financiera del departamento de TI: Adopte
un nuevo paradigma financiero que le brinde transparencia y
conecte los costos de los servicios de TI directamente con la
demanda y el consumo [53].
H.3. Autoescalabilidad
VMware vCenter Server proporciona una plataforma
centralizada y extensible para la gestin de la infraestructura
virtual. vCenter Server administra entornos de VMware
vSphere, proporcionando a los administradores de TI un
control simple y automatizado en el ambiente virtual para
entregar la infraestructura con confianza.
Principales beneficios:
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
Analizar y solucionar problemas rpidamente con
visibilidad de la infraestructura virtual vSphere.
Entregar la seguridad y disponibilidad de vSphere a travs
de funciones de gestin proactiva automatizadas, como el
balanceo de carga automtico y fuera de la caja (de la
expresin en ingls "out-of-the-box") de automatizacin de
flujos de trabajo.
Ampliar las capacidades de virtualizacin con soluciones
ambientales de terceros [52].
H.4. Blueprints / Imgenes para acelerar el aprovisionamiento
VMware vCenter Server proporciona una gestin
centralizada de la infraestructura virtual vSphere. Los
administradores de TI pueden asegurar la seguridad y
disponibilidad, simplificar las tareas del da a da, y reducir la
complejidad de la gestin de la infraestructura virtual.
Cmo funciona el vCenter Server?: El Control y visibilidad
centralizada proporciona una gestin centralizada de hosts
virtuales y mquinas virtuales desde una nica consola. Esto
proporciona a los administradores una mayor visibilidad en la
configuracin de los componentes crticos de una
infraestructura virtual, todo desde un solo lugar. Con vCenter
Server, los entornos virtuales son ms fciles de manejar: un
solo administrador puede gestionar cientas de cargas de
trabajo, ms del doble de la productividad tpica en la gestin
de la infraestructura fsica [52].
Infraestructura Virtual entregada con confianza: Cumplir
consistentemente con los Acuerdos de nivel de servicio de
aplicacin crticos para el negocio (del ingls "Service level
agreement", y su acrnimo SLA), exige una gestin proactiva
automatizada para maximizar las capacidades de vSphere.
Entre las principales funcionalidades habilitadas por vCenter
Server incluyen: VMware vSphere vMotion, VMware vSphere
Distributed Resources Scheduler, VMware vSphere High
Availability (HA) y VMware vSphere Fault Tolerance.
VMware vCenter Orchestrator tambin proporciona a los
administradores la capacidad de crear e implementar
fcilmente los flujos de trabajo con las mejores prcticas.
Con una gestin proactiva automatizada, vCenter Server
aprovisionamiento de nuevos servicios de forma dinmica,
equilibrando los recursos y la automatizacin de alta
disponibilidad [52].
H.5. Soporte para Sistemas operativos Microsoft Windows y
Linux
El Gestor Multi-hipervisor de vCenter Server proporciona
una gestin integrada y simplificada de hosts VMware e
Hyper-V, brinando la posibilidad de implementar tanto
sistemas operativos de la lnea Windows como tambin
aquellos basados en kernels Linux [52].
H.6. Soporte para almacenamiento de datos
En el entorno de vCloud Director, el proveedor
expone un conjunto de cmputo virtualizado, almacenamiento
y recursos de red para ser consumidos por los usuarios en la
nube. La puesta en comn de los recursos virtuales se define y
se gestiona a travs de vCloud Director por el administrador de
una manera que ofrece tanto elasticidad como escalabilidad.
Desde la perspectiva de los usuarios (consumidores) los
recursos de almacenamiento aparecen como un conjunto
ilimitado de almacenamiento de rendimiento y costo uniforme.
225
El objetivo de vCloud Director es el de proporcionar a los
consumidores la capacidad de almacenamiento ilimitado. Un
Proveedor VDC es un fondo de recursos de un clster de
servidores VMware ESX que acceden a un recurso de
almacenamiento compartido. El proveedor VDC puede
contener:
1) parte de un almacn de datos (compartida por otros CDA
Provider)
2) un almacn de datos completo
3) mltiples almacenes de datos.
Como el almacenamiento se aprovisiona por Organizacin
de VDCs, la agrupacin de almacenamientos compartido para
el proveedor de VDC se considera como una agrupacin de
almacenamiento sin distincin de caractersticas de
almacenamiento, protocolos u otras caractersticas que lo
diferencian de ser algo ms que un espacio de direcciones de
gran tamao.
En el caso de un Proveedor de VDC que se compone de
ms de un almacn de datos, se considera buena prctica que
los almacenes de datos tengan capacidades de rendimiento
iguales, as como protocolos y calidad de servicio. En caso
contrario, el rendimiento del Proveedor de agrupacin de
almacenamiento VDC se ver afectado por el almacenamiento
ms lento. Algunos VDCs podran terminar con el
almacenamiento ms rpido que otros. Con el fin de obtener
los beneficios de los diferentes niveles o protocolos de
almacenamiento, ser necesario definir los Proveedores VDCs
separados donde cada proveedor de VDC tendra
almacenamiento de diferentes protocolos y diferentes calidades
de servicio de almacenamiento. Por ejemplo, se podra
suministrar un proveedor de VDC que se base en un almacn
de datos de respaldo de discos de 15K RPM FC con un montn
de cach en el disco para obtener el ms alto rendimiento de
disco, y un segundo proveedor de VDC que se basa en un
almacn de datos de respaldo de unidades SATA y con poco
cach en la matriz de un nivel inferior. Cabe sealar que
cuando un proveedor de VDC tiene un almacn de datos que se
comparte con otro Proveedor de VDC, uno puede encontrar
que un Proveedor de VDC est causando impacto en el
rendimiento en otro Proveedor de VDC. Por lo tanto, se
considera buena prctica tener un proveedor de VDC que tenga
un almacn de datos dedicado de forma que el aislamiento del
almacenamiento reduzca las posibilidades de diferentes
calidades de servicios de almacenamiento en un solo proveedor
de VDC [54].
H.7. Soporte para colas
El plug-in AMQP de VMware vCenter Orchestrator
permite a las organizaciones activar automticamente los flujos
de trabajo basados en mensajes Advanced Message Protocol
Queue Server (AMQP). AMQP es un protocolo de alta
escalabilidad de publicacin y suscripcin de mensajes que se
utiliza cada vez ms en las arquitecturas de nube. Es el
protocolo de mensajera por defecto para vCloud Director. Con
el AMQP plug-in, las organizaciones pueden definir polticas
que activan automticamente los flujos de trabajo especficos
en funcin de ciertos mensajes AMQP. Por ejemplo, como
parte de una actividad de pre-aprovisionamiento de una vApp,
vCloud Director Orchestrator puede detectar la peticin de
provisin y recuperar automticamente la direccin IP de un
sistema externo antes de permitir que vCloud Director continue
con la actividad de aprovisionamiento. Cuando Orchestrator
226 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
detecta que el aprovisionamiento de vApp se ha completado,
Orchestrator puede actualizar las bases de datos de gestin de
la configuracin y otros sistemas de gestin de la informacin
sobre la nueva instancia de vApp.
El AMQP plug-in proporciona la capacidad de controlar y
publicar mensajes AMQP, as como para llevar a cabo tareas
administrativas, como la configuracin de corredores AMQP y
gestin de colas. El plug-in AMQP de VMware soporta
RabbitMQ as como otras implementaciones de AMQP [55].
H.8. Alternativas de Hipervisor
El Gestor de Multi-hipervisor proporciona una gestin
integrada y simplificada de hosts VMware e Hyper-V.
VMware vCenter Server proporciona la gestin
centralizada de infraestructura virtual vSphere. Los
administradores de TI pueden asegurar as la seguridad y
disponibilidad, simplificar las tareas del da a da, y reducir la
complejidad de la gestin de la infraestructura virtual [52].
Qu es VMware vCenter Multi-Hypervisor Manager 1.1?
VMware vCenter Multi-Hypervisor Manager es un
componente que activa el soporte para los hipervisores
heterogneos en VMware vCenter Server. Ofrece los siguientes
beneficios a su entorno virtual:
Una plataforma integrada para la gestin de VMware y los
hipervisores de terceros desde una nica interfaz.
Alternativas de hipervisores para las diferentes unidades de
negocio de la organizacin para satisfacer sus necesidades
especficas.
Mltiples proveedores de hipervisores soportados.
Cuando se agrega un host de terceros a vCenter Server,
todas las mquinas virtuales que existen en el host se detectan
automticamente y se agregan al inventario de los ejrcitos de
terceros [56].
H.8.1. Caractersticas destacadas
vCenter Multi-Hypervisor Manager 1.1 introduce el
siguiente conjunto de capacidades bsicas de gestin sobre
otros fabricantes:
Gestin de hosts de terceros incluyendo agregar, quitar,
conectar, desconectar y ver la configuracin del host.
Posibilidad de migrar mquinas virtuales desde hosts de
terceros para ESX o ESXi.
Capacidad para la provisin de mquinas virtuales en hosts
de terceros.
Capacidad para editar la configuracin de la mquina
virtual.
mecanismo de autorizacin integrado del servidor vCenter
en ESX / ESXi e inventarios de los host de terceros para
obtener privilegios, roles y usuarios.
Deteccin automtica de las mquinas virtuales de terceros
preexistentes
Capacidad para realizar operaciones sobre hosts y mquinas
virtuales.
Posibilidad de conectar y desconectar DVD, CD-ROM,
unidades de disco y las imgenes de disco para instalar
sistemas operativos [56].
I. OpenStack
I.1. Descripcin
OpenStack es un conjunto de proyectos de software de
cdigo abierto que las empresas / proveedores de servicios
pueden usar para configurar y ejecutar su nube de computacin
e infraestructura de almacenamiento. Rackspace y la NASA
son los contribuyentes iniciales clave para la pila. Rackspace
contribuy con su plataforma "Archivos en la Nube" (cdigo)
para alimentar la parte de almacenamiento de objetos de
OpenStack, mientras que la NASA aport su plataforma
"Nebulosa" (cdigo) para alimentar la parte Compute. El
Consorcio OpenStack ha logrado tener ms de 100 miembros,
incluyendo Canonical, Dell, Citrix, etc en menos de un ao.
OpenStack hace que sus servicios se encuentren disponibles
por medio de una API compatible con Amazon EC2/S3. Por lo
tanto, las herramientas cliente escritas para AWS se pueden
utilizar con OpenStack [57].
I.2. Caractersticas Principales
I.2.1. Infraestructura de Cmputo (Nova)
Nova es el controlador de fbrica para Cmputo para la
nube OpenStack. Todas las actividades necesarias para apoyar
el ciclo de vida de las instancias dentro de la nube OpenStack
se manejan por Nova. Esto hace que Nova sea una plataforma
de gestin que administra los recursos de cmputo, redes,
autorizacin, y las necesidades de escalabilidad de la nube
OpenStack. Sin embargo, Nova no proporciona ninguna
capacidad de virtualizacin por s mismo, sino que utiliza las
API de libvirt para interactuar con los hipervisores
compatibles. Nova expone todas sus capacidades a travs de
una API de servicios web que sea compatible con la API de
EC2 de Amazon Web Services [58].
I.2.1.1. Funciones y caractersticas
Gestin del ciclo de vida de Instancias
Gestin de recursos informticos
Redes y Autorizacin
API basada en REST
Comunicacin consistente, eventualmente asincrnica
Agnsticismo de Hypervisor: soporte para Xen, XenServer /
XCP, KVM, UML, VMware vSphere y Hyper-V [59].
I.2.2. Infraestructura de Almacenamiento (Swift)
Swift proporciona un almacn de objetos virtuales
eventualmente consistentes distribuida para OpenStack. Es
anlogo a Amazon Web Services - Simple Storage Service
(S3). Swift es capaz de almacenar miles de millones de objetos
distribuidos en diferentes nodos. Swift ha incorporado
redundancia y tolerancia a fallos de gestin y es capaz de
transmitir y guardar multimedia. Es sumamente escalable tanto
en trminos de tamao (varios petabytes) y de capacidad
(Nmero de objetos) [60].
I.2.2.1. Funciones y caractersticas
Almacenamiento de gran cantidad de objetos
Almacenamiento de objetos de tamao grande
Redundancia de datos
Capacidad de Archivo - Trabajo con conjuntos de datos
grandes
Contenedor de datos de mquinas virtuales y aplicaciones
cloud
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
Capacidad de transmisin de multimedia
Almacenamiento seguro de los objetos
Copia de seguridad y archivado
Escalabilidad Extrema [61]
I.2.3. Servicios de Imagen (Glance)
Servicios de imagenes de OpenStack es un sistema de
bsqueda y recuperacin de imgenes de mquinas virtuales.
Puede ser configurado para utilizar uno cualquiera de los
siguientes backends de almacenamiento:
Sistema de archivos local (por defecto)
Almacenar objetos OpenStack para almacenar imgenes
Almacenamiento directo en S3 (Simple storage service de
Amazon EC2)
Almacenamiento S3 con almacn de objetos como
intermediario para el acceso a S3.
HTTP (de slo lectura)
[OpenStack, 2013f] Funciones y caractersticas:
Proporciona servicios de imgenes [62]
I.3. Autoescalabilidad
Heat es un servicio para orquestar mltiples aplicaciones
compuestas en la nube utilizando el formato de la plantilla
CloudFormation AWS, tanto a travs de una API REST
OpenStack-nativa como un API de consultas CloudFormation-
compatible.
Heat proporciona una implementacin CloudFormation
AWS para OpenStack que orquesta una plantilla
CloudFormation AWS que describe una aplicacin de nube
ejecutando las llamadas apropiadas a la API OpenStack, para
generar la ejecucin de aplicaciones de nube.
El software integra otros componentes bsicos de
OpenStack en un sistema de plantillas de un archivo. Las
plantillas permiten la creacin de la mayora de los tipos de
recursos OpenStack (tales como instancias, IPs flotantes,
volmenes, grupos de seguridad, usuarios, etc), as como
tambin algunas funciones avanzadas tales como una alta
disponibilidad de instancias, autoescalabilidad de instancias, y
pilas anidadas. Al proporcionar una integracin tan estrecha
con otros proyectos ncleo de OpenStack, todos los proyectos
ncleo de OpenStack podran recibir un mayor nmero de
usuarios [63].
I.4. Blueprints / Imgenes para acelerar el aprovisionamiento
I.4.1. Oz
Oz es una herramienta de lnea de comandos que
automatiza el proceso de creacin de un archivo de imagen de
mquina virtual. Oz es una aplicacin Python que interacta
con KVM para pasar por el proceso de instalacin de una
mquina virtual. Se utiliza un conjunto predefinido de arranque
rpido (sistemas basados en RedHat) y ficheros de pre-
configuracin (sistemas basados en Debian) para los sistemas
operativos que soporta, y tambin permite crear imgenes de
Microsoft Windows [64].
I.4.2. vmbuilder
Vmbuilder (Generador de mquinas virtuales) es una
herramienta de lnea de comandos que se puede utilizar
para crear imgenes de mquinas virtuales para diferentes
hipervisores. La versin de vmbuilder que viene con
227
 Ubuntu slo puede crear mquinas virtuales de Ubuntu. La
versin de vmbuilder que viene con Debian pueden crear
mquinas virtuales Ubuntu y Debian [64].
I.4.3. BoxGrinder
BoxGrinder es otra herramienta para la creacin de
imgenes de mquinas virtuales. BoxGrinder puede crear
imagenes de mquinas virtuales Fedora, Red Hat Enterprise
Linux, CentOS. BoxGrinder slo est soportado en Fedora
[64].
I.4.4 VeeWee
VeeWee se utiliza a menudo para construir cajas de
Vagrant, pero tambin puede ser usado para construir imgenes
KVM [64].
I.4.5. Imagefactory
Imagefactory es una herramienta nueva diseada para
automatizar la construccin, y convertir y subir imgenes a
diferentes proveedores de la nube. Utiliza Oz como su back-
end e incluye soporte para las nubes basadas en OpenStack
[64].
I.5. Soporte para Sistemas operativos Microsoft Windows
Es posible utilizar Hyper-V como un nodo de clculo
dentro de una implementacin de OpenStack. El servicio de
cmputo nova se ejecuta como un servicio de 32 bits
directamente en la plataforma de Windows con la funcin
Hyper-V habilitada. Los componentes de Python necesarios,
as como el servicio de Cmputo Nova se instalan directamente
en la plataforma Windows. Los Servicios de Cluster Server de
Windows no son necesarios para la funcionalidad de la
infraestructura OpenStack. El uso de la plataforma Windows
Server 2012 se recomienda para obtener mejores resultados.
Las plataformas Windows siguientes han sido probadas como
nodos de cmputo [63]:
I.5.1 Windows Server 2008R2
Tanto Server y Server Core con el rol Hyper-V activados
(Nada Compartido La migracin en vivo no es compatible con
2008r2)
Windows Server 2012: Server y Core (con la funcin
Hyper-V habilita) e Hyper-V Server
I.6. Soporte para Sistemas operativos Linux
Qu es RDO?
RDO es una disposicin de distribucin libre, apoyada por la
comunidad de OpenStack, que se ejecuta en Red Hat
Enterprise Linux, Fedora y sus derivados. Adems de
proporcionar un conjunto de paquetes de software, RDO
permite adems a los usuarios de la plataforma de computacin
en la nube en los sistemas operativos Red Hat Linux obtener
ayuda y comparar notas sobre la ejecucin de OpenStack.
El proyecto OpenStack se beneficia de un amplio grupo de
proveedores y distribuidores, pero ninguno cuenta con la
experiencia en produccin de Red Hat, la experiencia tcnica y
el compromiso con la forma de cdigo abierto de la produccin
de software. Algunas de las ms grandes nubes de produccin
en el mundo se ejecutan y son apoyadas por Red Hat, y los
ingenieros de Red Hat contribuyen a todas las capas de la
plataforma OpenStack. Desde el ncleo de Linux y los
componentes del hipervisor KVM hasta los componentes de
228 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
nivel superior del proyecto OpenStack, Red Hat se encuentra
cerca de la parte superior de la lista en trminos de nmero de
desarrolladores y de contribuciones [65].
I.7. Soporte para almacenamiento de datos
Adems de la tecnologa de almacenamiento de clase
empresarial tradicional, muchas organizaciones ahora tienen
una variedad de necesidades de almacenamiento con requisitos
de rendimiento y precios variables. OpenStack tiene soporte
para almacenamiento de objetos y Block Storage, con muchas
opciones de implementacin para cada uno dependiendo del
caso de uso. El almacenamiento de objetos es ideal para el
almacenamiento eficaz con escalabilidad horizontal.
Proporciona una plataforma de almacenamiento accesible por
medio de una API completamente distribuida que se puede
integrar directamente en las aplicaciones o utilizar para copia
de seguridad, archivo y conservacin de los datos. Block
Storage permite mejorar el rendimiento y la integracin con las
plataformas de almacenamiento empresarial, como NetApp,
Nexenta y SolidFire.
OpenStack ofrece, almacenamiento de objetos escalable y
redundante utilizando clusters de servidores estandarizados
capaces de almacenar petabytes de datos
El almacenamiento de objetos no es un sistema de archivos
tradicional, sino ms bien un sistema de almacenamiento
distribuido de datos estticos, como imgenes de mquina
virtual, almacenamiento de fotos, almacenamiento de correo
electrnico, copias de seguridad y archivos. Al no tener
"cerebro" central, el punto principal de control proporciona una
mayor escalabilidad, redundancia y durabilidad.
Los objetos y los archivos se escriben en mltiples
unidades de disco distribuidos en el centro de datos (del ingls
"Data Center"), con ka responsabilidad del software de
OpenStack de asegurar la replicacin y la integridad de los
datos en el clster.
Las agrupaciones de almacenamiento (del ingls "Storage
Clusters") escalan horizontalmente simplemente aadiendo
nuevos servidores. En caso de que un servidor fallara,
OpenStack replica el contenido a otros nodos activos en nuevas
ubicaciones del clster. Debido a que OpenStack utiliza la
lgica del software para asegurar la replicacin y distribucin a
travs de diferentes dispositivos, se pueden utilizar, en lugar de
los equipos ms caros, los discos duros y servidores de datos de
materias primas baratas.
Bloque Capacidades de almacenamiento: OpenStack ofrece
dispositivos de almacenamiento persistentes a nivel de bloque
para su uso con instancias de proceso OpenStack.
El sistema de almacenamiento de bloques gestiona la
creacin, montaje y desmontaje de los dispositivos de bloque
en los servidores. Los volmenes de almacenamiento de
bloques se integran plenamente en OpenStack Compute y su
tablero de control permite a los usuarios en la nube gestionar
sus propias necesidades de almacenamiento.
Adems, utiliza el almacenamiento del servidor Linux
simple, que tiene soporte de almacenamiento unificado para
numerosas plataformas de almacenamiento, incluyendo Ceph,
NetApp, Nexenta, SolidFire y Zadara.
Bloquear el almacenamiento es adecuado para escenarios
sensibles al rendimiento, como el almacenamiento de bases de
datos, sistemas de archivos expandibles, o la prestacin de un
servidor con acceso al almacenamiento a nivel de bloque en
bruto.
 La gestin de Snapshots proporciona una funcionalidad de
gran alcance para hacer copias de seguridad de los datos
almacenados en volmenes de almacenamiento en bloque. Los
Snapshots se pueden restaurar y utilizar para crear un nuevo
volumen de almacenamiento en bloque [66].
I.8. Soporte para colas
Message Queue (Rabbit MQ Server)
OpenStack se comunica entre s utilizando la cola de mensajes
a travs de AMQP (Protocolo avanzado de colas de mensajera,
del ingls "Advanced Message Queue Protocol). Nova utiliza
llamadas asincrnicas para la solicitud de respuesta, con una
devolucin de llamada que se desencadena una vez que se
recibe una respuesta. Dado que se utiliza la comunicacin
asincrnica, ninguna de las acciones del usuario se bloquea por
mucho tiempo en un estado de espera. Esto es efectivo ya que
muchas de las acciones previstas por la API de llamadas tales
como el lanzamiento de una instancia o aadir una imagen
demandan mucho tiempo [67].
Qu puede hacer RabbitMQ?
Las funciones de Mensajera permiten conectar y ampliar las
aplicaciones de software. Las aplicaciones pueden conectarse
entre s, como componentes de una aplicacin ms grande, o a
los dispositivos de usuario y datos. La mensajera es asncrona,
desacoplando las aplicaciones mediante la separacin del envo
y recepcin de datos.
La entrega de datos, las operaciones no bloqueantes,
notificaciones push, publicacin/suscripcin, procesamiento
asincrnico y colas de trabajo son patrones que forman parte de
la mensajera.
RabbitMQ es un broker de mensajera que opera como
intermediario. Proporciona a las aplicaciones una plataforma
comn para enviar y recibir mensajes, de manera que los
mensajes permanezcan en un lugar seguro hasta que sean
recibidos [68].
I.9. Alternativas de Hipervisor
El mdulo de cmputo de OpenStack soporta varios
hipervisores. La mayora de las instalaciones slo utilizan un
nico hipervisor, sin embargo, es posible utilizar el
ComputeFilter e ImagePropertiesFilter para permitir la
programacin de diferentes hipervisores dentro de la misma
instalacin.
KVM - Mquina Virtual basada en el Kernel. Los formatos
de disco virtual que soporta son heredados de QEMU, ya que
utiliza un programa de QEMU modificado para poner en
marcha la mquina virtual. Los formatos soportados incluyen
imgenes en bruto (del ingls "raw images"), la qcow2 y
formatos de VMware.
LXC - Linux Containers (a travs de libvirt), se utiliza para
ejecutar mquinas virtuales basadas en Linux.
QEMU - Emulador rpido, por lo general slo se utiliza
para fines de desarrollo.
UML - User Mode Linux, por lo general slo se utiliza para
fines de desarrollo.
VMware vSphere 4.1 Update 1 y versiones posteriores,
ejecuta Linux y Windows basados en imgenes VMware a
travs de una conexin con un servidor vCenter o directamente
con un servidor ESXi.
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
Xen - XenServer, Plataforma de Nube Xen (XCP),
utilizado para ejecutar mquinas virtuales de Windows o
Linux. Es necesario instalar el servicio nova-compute en una
mquina virtual para-virtualizado.
PowerVM - virtualizacin de servidores con IBM
PowerVM, utilizado para ejecutar AIX, IBM i y Linux en la
tecnologa IBM POWER.
Hyper-V - virtualizacin de servidores con Hyper-V de
Microsoft, utilizado para ejecutar indows, Linux, y las
mquinas virtuales FreeBSD. Ejecuta nova-clculo de forma
nativa en la plataforma de virtualizacin de Windows.
Bare Metal - No es un hipervisor en el sentido tradicional,
este controlador dispone de hardware fsico a travs de
controladores configurables (por ejemplo PXE para el
despliegue de imgenes, e IPMI para la administracin de
energa) [69].
III. ESTUDIO COMPARADO DE LAS ARQUITECTURAS
RELEVADAS
A. Descripcin del Problema
A la fecha de creacin de este trabajo, el mercado de
tecnologas de la informacin cuenta con una amplia oferta de
plataformas de servicios de Cloud Computing comercializados
por mltiples proveedores. Muchas de las plataformas de estos
proveedores proponen servicios anlogos que pueden ser
explotados con diversos lenguajes de programacin y
plataformas de desarrollo. Es por ello que se considera
necesario realizar una comparacin, como producto resultante
de este trabajo de investigacin, acerca de los servicios y
caractersticas ofrecidos por los principales proveedores de las
tecnologas antedichas, en pos de colaborar al esclarecimiento
sobre qu plataforma puede ser conveniente para cada caso,
identificando adems las fortalezas y debilidades ms
relevantes de cada una de ellas, as como tambin las carencias
o prestaciones faltantes por parte de cada proveedor de
soluciones.
B. Caractersticas Consideradas
En la instancia de diseo del cuadro comparativo se
seleccionaron un conjunto de caractersticas que por diversas
razones fueron consideradas relevantes. A continuacin se
define cada una de ellas.
C. Definicin de las caractersticas evaluadas
Las caracteristicas evaluadas se muestran en la Tabla 3.
D. Matriz comparativa
En la Figura 5 se presenta la matriz comparativa de las
arquitecturas relevadas.
E. Estudio de la Tabla Comparativa
D.1. Escalabilidad automtica (AutoScaling)
Con respecto a la escalabilidad automtica, algunos
proveedores de servicios ofrecen capacidades ms
evolucionadas para definir los criterios de escalabilidad. Con
esto nos referimos tanto a la escalabilidad que incrementa los
recursos disponibles (el trmino popularmente utilizado en
ingls es scale up), como a la escalabilidad que decrementa
los recursos disponibles para las aplicaciones (el trmino
popularmente utilizado en ingls scale down).
229
 TABLA 3. CARACTERSTICAS CONSIDERADAS PARA EL ANLISIS DE LAS PLATAFORMAS EN LA NUBE.
Carc- Descripcin
terstica
Escalabilidad automtica Brinda la posibilidad de incrementar o reducir de manera automtica, utilizando un monitor provisto por la plataforma, la cantidad de
(auto-scaling) recursos asignado a un sistema o aplicacin.
Las imgenes o blueprints son mquinas virtuales que ya disponen de un sistema operativo y de los aplicativos o marcos de trabajo
Blueprints / Imgenes
(frameworks) instalados y pre-configurados, para que sea ms rpido comenzar a trabajar en la plataforma, permitiendo al usuario
para acelerar el
final focalizarse en la construccin o despliegue de sus aplicaciones. Un ejemplo popular de blueprint es llamado LAMP, imagen
aprovisionamiento
de mquina virtual conformada por Linux Apache MySQL y PHP.
Soporta Sistema Esta caracterstica permite evaluar la capacidad de implementar sistemas o aplicaciones de usuarios finales que operen bajo Sistemas
operativo Windows Operativos Windows, y en caso afirmativo, tambin definir cules de sus versiones son soportadas.
Soporta Sistema Esta caracterstica permite evaluar la capacidad de implementar sistemas o aplicaciones de usuarios finales que operen bajo Sistemas
operativo Linux Operativos Linux, y en caso afirmativo, tambin definir cules de sus versiones son soportadas.
Soporte para lenguajes Esta caracterstica permite definir cules son los lenguajes soportados por las distintas plataformas en anlisis
Soporte para Esta caracterstica define cules son los medios fsicos que ofrecen las plataformas analizadas para la persistencia de datos.
almacenamiento de datos
Esta caracterstica define cules son los soportes para colas brindados por las diferentes plataformas. Una cola es una estructura de
Soporte para Colas datos, caracterizada por ser una secuencia de elementos en la que la operacin de insercin push se realiza por un extremo y la
(queues) operacin de extraccin pop por el otro. Tambin se le llama estructura FIFO (del ingls First In First Out), debido a que el primer
elemento en entrar ser tambin el primero en salir.
Esta caracterstica permite evaluar cules son las opciones de servidores web (del ingls web server) ofrecidas por cada proveedor.
Un servidor web o servidor HTTP es un programa informtico que procesa una aplicacin del lado del servidor realizando
Servidor Web
conexiones bidireccionales y/o unidireccionales, y sncronas o asncronas con el cliente generando o cediendo una respuesta en
cualquier lenguaje o Aplicacin del lado del cliente.
Esta caracterstica permite evaluar cules son los hipervisores disponibles ofrecidos por cada plataforma. Un hipervisor (del ingls
Alternativas de
hypervisor) o monitor de mquina virtual (virtual machine monitor) es una plataforma que permite aplicar diversas tcnicas de
hipervisor
control de virtualizacin para utilizar al mismo tiempo diferentes sistemas operativos en una misma computadora.
Los caches distribuidos o datagrids son frecuentemente implementados por tablas de hash distribuidas. Las tablas de hash
distribuidas (en ingls, Distributed Hash Tables, DHT) son una clase de sistemas distribuidos descentralizados que proveen un
servicio de bsqueda similar al de las tablas de hash, donde pares (clave, valor) son almacenados en el DHT, y cualquier nodo
participante puede recuperar de forma eficiente el valor asociado con una clave dada. Esta clase de productos ofrecen el beneficio de
Cache In-Memory
mejorar los tiempos de respuesta para la bsqueda de datos, con respecto a los mecanismos de persistencia tradicionales, tales como
distribuido / DataGrid
base de datos relacionales (BDR), puesto que para acceder a un set de datos alojado en una BDR generalmente se debe establecer una
comunicacin TCP y luego acceder al dato realizando una lectura de disco, lo cual es menos eficiente que los caches distribuidos, a
los cuales generalmente se accede por protocolo TCP y luego se accede al dato almacenado en memoria RAM (Random Access
memory).
Las tecnologas Big Data (del idioma ingls grandes datos) hace referencia a los sistemas que manipulan grandes conjuntos de datos
(o data sets). Las dificultades ms habituales en estos casos se centran en la captura, el almacenado, bsqueda, comparticin, anlisis,
Soporte para
y visualizacin. La tendencia a manipular ingentes cantidades de datos se debe en muchos casos a la necesidad de incluir los datos
tecnologas BigData
del anlisis en un gran conjunto de datos relacionado, tal es el ejemplo de los anlisis de negocio, los datos de enfermedades
infecciosas, la lucha contra el crimen organizado, etc.

Ejemplos de estos proveedores ms evolucinoados son la
plataformas Amazon EC2 Cloudwatch, Windows Azure
Autoscaling application Block y VMware VCloud Director,
que otorgan la posibilidad de definir los criterios y o umbrales
que determinarn las reglas de escalabilidad que dispararn los
mecanismos necesarios para incrementar o decrementar la
cantidad de recursos de hardware virtualizados que sern
asignados a las aplicaciones, de manera que estas puedan
cumplir ajustndose dinmicamente a la demanda de sus
clientes. En contraposicin, otras plataformas como Google
Apps ofrecen escalabilidad automtica no controlada por el
arquitecto de aplicacin Cloud. En este caso, el arquitecto de
aplicacin cloud no podr definir los criterios de escalabilidad
para sus aplicaciones sino que este criterio se ver regido por
los principios ya definidos por Google Apps, el cual cuenta con
un modelo propio de escalabilidad que no puede ser ajustado u
optimizado de manera alguna por el usuario de la plataforma,
en funcin de sus necesidades particulares.
Con respecto a la autoescalabilidad de la plataforma
OpenShift, provista por HA Proxy, slo es posible definir una
cantidad mnima y mxima de Cartidges (bsicamente
instancias) que podrn ser utilizadas en la aplicacin durante
los procesos de escalabilidad (tanto hacia arriba como hacia
abajo) en funcin de la demanda de recursos de la aplicacin,
sin embargo, el arquitecto de una aplicacin que se ejecuta en
la plataforma OpenShift no cuenta con la posibilidad de definir
cules sern los umbrales que dispararn los mecanismos de
escalabilidad automtica.
En el caso de IBM SmartCloud, que implementa sus
mecanismos de autoescalabilidad con Smart Cloud Application
Workload Scale (SCAWS), ofrece la posibilidad de utilizar
plantillas predefinidas provistas por un sitio oficial de IBM que
facilitan la configuracin de escenarios de escalabilidad para
diferentes arquetipos de aplicaciones, como por ejemplo IBM
Mobile Application Platform Pattern Type, que optimiza las
caractersticas de escalabilidad automtica a los criterios
tpicos operacionales de aplicaciones Mviles. La plataforma
de IBM tambin brinda cierta flexibilidad para definir reglas de
escalabilidad.
Con respecto a la plataforma OpenStack, su propuesta de
solucin para la escalabilidad automtica est implementada en
Heat, el cual permite definir plantillas con criterios ms
avanzados, que permiten definir concretamente los umbrales
cuantificados en niveles porcentuales (por ejemplo de uso de
RAM) que sern considerados como criterios primarios para
aplicar la escalabilidad automtica. Heat ofrece adems la
posibilidad de eliminar automticamente las instancias que se
generaron al incrementarse la carga, cuando esta carga de
trabajo (workload) se encuentre por debajo del umbral
definido.

230 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
 Figura 5. Matriz Comparativa

Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. 231
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
D.2. BluePrints/Imgenes para acelerar el aprovisionamiento
Amazon con su plataforma EC2 tiene la mayor oferta de
imgenes para acelerar el aprovisionamiento de los
proveedores analizados, contando con casi 2000 plantillas de
mquinas virtuales con diferentes configuraciones.
Otro proveedor que brinda buenas soluciones en este
aspecto es Microsoft Azure, que otorga la posibilidad de
acelerar el aprovisionamiento de mquinas virtuales con
diferentes sistemas operativos y configuraciones listadas en
una galera, brindando adems la posibilidad de crear las
propias imgenes de mquinas virtuales personalizadas para
que se adecen perfectamene a las necesidades de sus clientes.
Aunque Microsoft Azure virtualiza sus entornos con su
hipervisor Hiper-V, otorga igualmente la posibilidad de
convertir mquinas virtuales de VMware de manera que se
puedan subir y utilizar en la plataforma Windows Azure,
facilitando considerablemente la migracin de aplicaciones
existentes a su plataforma.
Google App Engine, en cambio, no brinda la posibilidad de
acelerar el aprovisionamiento de entornos puesto que su
plataforma es Infraestructura como servicio (IaaS); esto
implica que App Engine no otorga la posibilidad de crear
mquinas virtuales propias ni tampoco utilizar otras existentes.
Existe un nuevo servicio de Google llamado Google App
Compute que otorga la posibilidad de crear mquinas virtuales
basadas en el sistema operativo Linux y tiende a otorgar
servicios de plataforma como servicio (PaaS), sin embargo,
esta plataforma an se est gestando y no ha alcanzado un
grado de madurez siquiera comparable con las plataformas que
en este estudio se tratan y analizan.
La plataforma abierta de Red Hat, OpenShift, permite
gestionar y acelerar el aprovisionamiento de mquinas virtuales
por medio de su producto RHC (Red Hat Client), y el uso de
lenguajes de scripting, mayoritariamente en lenguaje Bash,
bajo el sistema operativo Red Hat Linux.
VMware brinda una flexibilidad muy grande al permitir
acelerar el aprovisionamiento de entornos por medio de
VCloud Director y sus imgenes de mquinas virtuales basadas
en el virtualizador de VMware. Bajo estos lineamientos un
usuario de la plataforma VCloud, basada en CloudFoundry,
puede personalizar sus propias mquinas virtuales para que las
mismas se ajusten completamente a sus necesidades, instalando
los sistemas operativos que requiera (como por ejemplo
Microsoft Windows Server 2008, Red Hat Linux Enterprise,
Ubuntu, etc) y tambin el software de base necesario, tales
como plataformas de desarrollo Java, .net, o el paquete clsico
conocido por su acrnimo LAMP (Linux, Apache, MySQL y
PHP).
IBM SmartCloud brinda tambin las herramientas para que
sus usuarios puedan acelerar el aprovisionamiento de entornos
en su Plataforma como servicios, otorgando 10 tamaos de
instancias diferentes para sus mquinas virtuales de manera que
se puedan ajustar a los requerimientos de sus aplicaciones.
Asimismo, brinda 3 modelos de licenciamiento: mquinas
virtuales pre-configuradas con la modaliad de pago basado en
el uso, acceder a las imgenes utilizando licencias propias ya
adquiridas, o subir programas de software de IBM bajo la
modalidad traer software y licencias propias (del ingls
Bring Your Own Software and License).
Por ltimo, OpenStack brinda un modelo de
aprovisionamiento acelerado otorgando la posibilidad de contar
con ms de 1100 mquinas virtuales con diferentes
configuraciones (sistemas operativos y plataformas de
desarrollo). Algunas de estas imgenes fueron creadas por el
equipo de OpenStack y y el resto publicadas por los propios
usuarios de la plataforma, que decidieron compartirlas para
enriquecer la comunidad.
D.3. Soporte para lenguajes
El soporte brindando para diferentes lenguajes de
programacin es crucial al momento de seleccionar una
plataforma, puesto que es un factor limitante significativo en
cuanto a las posibilidades que un proveedor puede ofrecer, y
que sus clientes pueden explotar.
En este aspecto, Amazon EC2 ofrece un amplio abanico
que cubre los principales lenguajes y plataformas de desarrollo
del mercado actual. Este abanico se deriva del soporte y
compatibilidad de la plataforma con gran cantidad de versiones
de sistemas operativos cubriendo desde aplicaciones .net
escritas en C#, aplicaciones Java multiplataforma, aplicaciones
C++, aplicaciones Ruby, y tambin lenguajes interpretados
como Perl y Python.
Microsoft Windows Azure, por su parte, brinda soporte
para los lenguajes .Net (C#, Vb.net, J#, Asp.net, etc), Java
(tanto con mquinas virtuales con sistema operativo Microsoft
Windows 2012, como tambin con Sistemas operativos
basados en Kernel Linux, tales como Ubuntu u OpenSUSE),
Node.js para ejecutar cdigo javascript del lado del servidor
(por su expresin en ingls server side), y tambin Python.
Podran soportarse adems otros lenguajes y plataformas
utilizando imgenes de mquinas virtuales propias, por
ejemplo las VMware, convertidas a su equivalente Windows
Azure definida como disco duro virtual (por su acrnimo en
ingls VHD, de Virtual Hard Disc).
Las opciones que ofrece Google AppEngine para soporte
de lenguajes se encuentran limitadas exclusivamente a Python
y java, con la opcin adicional de Go, que an se encuentra en
fase experimental.
OpenShift mejora las opciones de lenguajes soportados por
App Engine, otorgando la posibilidad de implementar
aplicaciones desarrolladas en Java, Ruby, node.js, python, PHP
y Perl; sin embargo, dadas las restricciones de sistema
operativo que se derivan de que se trata de una plataforma
abierta, y al no soportar sistemas operativos basados en
Windows, no es posible implementar en OpenShift
aplicaciones Win32 u otras basadas en .Net Framework, con
lenguajes como C#, J#, Vb.net, Asp.net, etc.
Este hecho excluye a un sector del mercado que elige las
plataformas Microsoft como opcin para desarrollar sus
aplicaciones.
IBM SmartCloud limita las posibilidades de soporte nativo
en su plataforma para los lenguajes Java y PHP, aunque visto
que es posible hacer uso de imgenes de mquinas virtuales
soportadas por mltiples hipervisores, sera tambin factible
implementar aplicaciones desarrolladas en otros lenguajes tales
como aplicaciones .net (C#, J#, Asp.net, Vb.net, etc),
aplicaciones PHP, Python y otros lenguajes, incrementando su
potencial de lenguajes para mltiples plataformas, de manera
que permite cubrir un segmento ms amplio del mercado de
aplicaciones.
La plataforma de VMware brinda soporte nativo para los
lenguajes Java, C# y C++, maximizando la integracin de estas
aplicaciones con la Suite de productos que su plataforma
ofrece, por ejemplo para DataGrids distribudos en memoria

232 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
con el producto GemFire e implementaciones de Big Data, que
pueden interfacear con APIs nativas de estos lenguajes para
mayor performance. Asimismo, dadas las capacidades flexibles
de virtualizacin que VMware ofrece, sera tambin posible
implementar aplicaciones desarrolladas en otros lenguajes (por
ejemplo PHP o Ruby), e inclusive hacer uso de sus productos
de DataGrids mediante interfaces basadas en protocolos
interoperables como por ejemplo REST sobre HTTP.
OpenStack, por su parte, tambin ofrece soporte con APIs
nativas para gran diversidad de lenguajes de programacin.
Algunos de los lenguajes que pueden gozar de los beneficios
de esta plataforma son PHP, Python, Java, C#, Ruby. Esta
oferta es sumamente atractiva y abarcadora, puesto que cubre
los lenguajes ms populares y utilizados por las aplicaciones
tanto de escritorio como aquellas basadas en plataformas web e
interpretadas, maximizando las posiblidades de atraer nuevos
clientes.
D.4. Soporte para almacenamiento de datos
Los servicios de la plataforma Amazon EC2 se destacan
por sus alternativas de almaceamiento de datos, puesto que
cuenta con varias opciones disponibles que pueden ser
aprovechadas de manera independiente por sus clientes en
funcin de las necesidades puntuales que cada aplicacin tenga
que cubrir. Algunas de ellas son:
Amazon Simple Storage Service, que proporciona una
interfaz de servicios web (generalmente basadas en los
protocolos REST o SOAP sobre HTTP) que puede utilizarse
para almacenar y recuperar prcticamente cualquier cantidad
de datos desde cualquier parte de la Web. Hace uso de la
misma infraestructura (econmica, escalable, y segura) que
utiliza Amazon para tener en funcionamiento su propia red
internacional de sitios web. Este servicio tiene como fin
maximizar las ventajas del escalado y trasladar estas ventajas a
los desarrolladores. Otra opcin de almacenamiento de datos
ofrecida por Amazon EC2 consiste en Amazon Relational DB
Service, que ofrece servicios de bases de datos relacionales, las
cuales son altamente compatibles con la amplia mayora de las
aplicaciones ya existentes y con las tcnicas de persistencia de
datos ms populares del mercado (maximizando los recursos
humanos disponibles con conocimeintos de estas tcnicas y
bases de datos basadas en esta clase de tecnologa). Amazon
EC2 tambin ofrece el servicio Amazon SimpleDB, que es un
almacn de datos no relacionales de alta disponibilidad y
flexible que no requiere trabajo de administracin de bases de
datos por parte de los clientes de su plataforma. Los
desarrolladores simplemente almacenan elementos de datos y
los consultan mediante solicitudes de servicios Web (en
general utilizando APIs basdas en el protoclo REST o SOAP);
Amazon SimpleDB se encarga del resto.
Adems, Amazon ofrece tambin soporte para mltiples
versiones de SQL Server, que otorgan primordialmente la
posibilidad de integrar aplicaciones que persistan sus datos
utilizando las tecnologas de Microsoft SQL para cumplir su
propsito. Algunas aplicaciones que suelen hacer uso ms
frecuente de los motores de base de datos SQL Server, son
aquellas aplicaciones desarrolladas en tecnologas .Net y PHP.
Windows Azure en este aspecto ofrece 3 tipos de
almacenamiento de datos. Uno para dar soporte a SQL
Relacional, que permite que las aplicaciones ya desarrolladas
se puedan adaptar y migrar fcilmente a la nube sin necesidad
de modificar sus capas de acceso a datos (por los conectores y
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
consultas), y tampoco modificar el modelo de datos de la base
de datos ya disponible.
Para las aplicaciones nuevas o aquellas que deseen aplicar
tcnicas de reingeneira para aprovechar los beneficios de las
nuevas tecnologas tales como los productos NoSQL, Azure
ofrece almacenes de tablas NoSQL permitiendo el
almacenamiento de grandes cantidades de datos no
estructurados, que se pueden escalar automticamente para
satisfacer un rendimiento y volumen masivos de hasta 100
terabytes, accesibles prcticamente desde cualquier lugar a
travs de REST y las API administradas. La ltima opcin que
ofrece Microsoft Windows Azure para almacenamiento
consiste en Blobs no estructurados, que otorga la posibilidad de
almacenar grandes cantidades de texto no estructurado o datos
binarios tales como vdeo, audio e imgenes.
Google App Engine por su parte sugiere una nica
alternativa para dar solucin a la persistencia de datos,
consistente en una base de datos no relacional conocida como
Big Table. Si bien Google fue uno de los proveedores
pioneros en esta tecnologa, su mercado competitivo ha
avanzado a pasos agigantados y todos sus proveedores
competidores de servicios cloud ofrecen actualmente muchas
ms alternativas para dar solucin a la persistencia de datos. En
consecuencia, Google App Engine no soporta bases de datos
relacionales, lo cual dificulta y obstaculiza la migracin de
aplicaciones existentes tradicionales a su plataforma.
Para la plataforma OpenShift, por estar basada y pensada
para aplicaciones que corren sobre sistemas operativos Linux
(ms particularmente sobre distribuciones de Red Hat Linux),
no ofrece la posibilidad de peristir datos en bases de datos SQL
Server de Microsoft, pero s ofrece otras alternativas de
peristencia de datos relacionales basadas en los populares
motores MySQL, PostgresSQL y SQLite. Adems, OpenShift
ofrece tambin la posibilidad de persistencia de datos en un
motor de base de datos NoSQL muy popular del mercado
(MongoDB) que es una base de datos Open Source de tipo
documental con documentos de estilo JSON y esquemas
dinmicos.
La oferta de IBM SmartCloud para el almacenamiento de
datos es amplia. Otorga la posibilidad de utilizar almacenes de
bases de datos relacionales, como el motor IBM DB2, Oracle,
Microsoft SQL Server, Informix y Sybase. Con respecto a los
productos NoSQL, SmartCloud implementa almacenes de
datos basados en productos muy populares como por ejemplo
Hadoop.
En lo que al almacenamiento de datos se refiere, VMware
ha optado la estrategia de apuntar a los motores de persistencia
tradicionales que mayor segmento del mercado actual ocupan,
ofreciendo soporte nativo para bases de datos relacionales tales
como Oracle, Microsoft SQL Server, y PostgreSQL. Adems,
es posible persistir datos con otros productos que integran la
suite de VMware vFabric, tales como los almacenes de datos
propietarios de su datagrid GemFire. En adicin, para la lnea
de tecnologas de BigData, VMware brinda soporte para
mltiples distribuciones de Hadoop que permiten obtener los
beneficios de NoSQL.
Por ltimo, OpenStack brinda diferentes posibilidades de
almacenamiento de datos, tales como Object Storage
(persistencia de objetos implementada por el producto Swift),
Block Storage (peristencia de bloques implemenatada con el
producto Cinder) y tambin brinda soporte para distribuciones
233
de bases de datos relacionales MySQL, tales como Nova,
Glance, Cinder y Keystone.
D.5. Soporte para Colas y Servidores Web
En lneas generales, todos los proveedores de servicios
cloud ofrecen un nico producto para implementar tcnicas de
Colas.
En el caso de la plataforma Amazon EC2, cuenta con un
producto propietario cuyo nombre comercial es Amazon
Simple Queue Service.
Google App Engine tambin ofrece un producto propietario
comercializado como App Engine Task Queue.
OpenShift implementa soluciones para colas con IronMQ
que es un producto de colas pensado para aplicaciones que
corren en la nube, el cual basa sus comunicaciones en los
protocolos HTTP/Rest, brindando adems soporte para JSON.
IBM SmartCloud ofrece un producto de colas propietario
con el cual ya contaba en su suite WebSphere, y que es
comercializado como WebSphere Message Broker.
VMware y OpenStack, en cambio, proponen como
alternativa para dar solucin a las colas el producto Open
Source popularizado bajo el nomrbe de RabbitMQ, que se basa
en el protocolo estndar AMQP, que provee adems APIs para
Java y .Net.
Algo similar ocurre con la estrategia elegida por los
proveedores para dar solucin a las necesidades de servidores
Web: la mayora de los proveedores ofrecen una nica
alternativa para publicar aplicaciones web, tales son el caso de
Google App Engine, con Jetty Web Serever, Red Hat
OpenShift con Apache Server, o IBM SmartCloud con
WebSphere Application Server.
Otros casos como Amazon EC2 y Microsoft Windows
Azure ofrecen al menos dos alternativas para dar soporte a las
aplicaciones web, y esto se deriva de que estas plataformas
soportan mltiples lenguajes, algunos de los cuales que no
pueden compatibilizar sus ejecuciones en los mismos
servidores Web, como por ejemplo aplicaciones Web de
Microsoft (Asp.net) que requieren el servidor web Internet
Information Server, y aplicaciones web Java, que requieren
Servidores de tipo Apache/Tomcat.
D.6. Alternativas de Hipervisores
Esta caracterstica es crucial y determinante para el modelo
de negocio ofrecido por los proveedores de servicios cloud,
puesto que en funcin de las alternativas de virtualizacin que
estos ofrecen, se deriva la facilidad de portabilidad de
mquinas virtuales que contienen las aplicaciones ya existentes
en los datacenters (on premise) de sus potenciales clientes a sus
entornos Cloud. En muchos casos, aplicar reingeniera para
migrar las aplicaciones o instalarlas y adaptarlas en nuevas
plataformas puede demandar mucho tiempo y resultar costoso
en extremo. De all se desprende la relevancia de esta
caracterstica.
Amazon EC2, al igual que Google App Engine y
OpenShift, utiliza hipervisores basados en XEN y LXC (Linux
Containers)
IBM SmartCloud, en cambio, ofrece muy buenas
capacidades de virtualizacin, soportando mltiples
hipervisores que van desde VMware, Hyper-V hasta otros
basados en XEN.
Windows Azure, por su parte, trabaja con Windows Azure
hipervisor, que se trata de una versin de Hyper-V (el conocido
y tradicional hipervisor de Microsoft) ajustada y optimizada
234 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
para la virtualizacin en la nube. Adicionalmente, Microsoft
permite (como se mencion con anterioridad) la posibilidad de
migrar muqinas virtuales de VMware a formatos aceptados
por este virtualizador, de manera que brinda tambin una
alternativa de compatibilidad con esta tecnologa.
VMware VCloud permite trabajar con hipervisores ESX,
ESXi y tambin con el hipervisor de Microsoft Hyper-V.
Por ltimo, OpenStack ofrece el ms amplio abanico para
dar soluciones a la virtualizacin, soportando hipervisores
XEN, Hyper-V, KVM, QEMU, Contenedores Linux (LNC) y
muchos otros.
D.7. Cache In-Memory distribuido / Datagrid
Los cache In-Memory distribuidos y los datagrids juegan
un rol significativo a la hora de optimizar la performance de las
aplicaciones (y ms an cuando se trata de aplicaciones que
corrern en la nube, donde la escalabilidad y la performance
son un punto central), puesto que sustituyen los mecanismos de
persistencia y bsqueda de datos tradicionales que suelen estar
basados en hardware de bajo costo, pero tambin de baja
performance, como son los casos de los discos rgidos (storage)
magnticos. Estos mecanismos, al estar implemenatdos sobre
memorias de acceso aleatorio (del ingls Random Access
memory RAM-) son en general inclusive ms veloces que las
unidades de estado slido para obtener y persistir datos.
En el caso de Amazon EC2, ofrece gran flexibiliad
otorgando una alternativa abierta para la implementacin de
productos de Cache In-Memory y datagrids, pudiendo
mencionarse el soporte de productos tales como GemFire,
Oracle Coherence, Gigaspaces XAP, Hazlelcast, etc.
En el caso de Windows Azure, ofrece principalmente dos
alternativas para dar solucin al acceso rpido a los datos:
Memcached, el cual se trata de un producto Cache OpenSource
de tipo Clave valor (del ingls Key-value) muy popular para
caching distribuido, con gran adherencia en el mercado
(algunos de los clientes que usan este producto son Facebok,
Twitter, Wikipedia, YouTube, WordPress, etc.). Este producto
tiene sus propios protocolos (inicialmente trabajaba nicamente
con un protocolo de tipo texto y las ltimas versiones del
producto implementan un nuevo protoclo de tipo binario,
optimizando as el desempeo del mismo. Para hacer uso de
este producto, las aplicaciones deben implementar tcnicas de
caching de datos en sus capas de acceso a datos, es decir que su
implementacin y uso en Microsoft Azure no resulta
transparente para las aplicaciones que requieran optimizar su
desempeo por este camino.
La segunda opcin que ofrece Azure para caching
distribuido de datos es Windows Azure Caching, que se trata
de un producto propietario de Microsoft y que adems es
compatible con el protocolo de Memcached, de manera que las
aplicaciones que ya implementaban mecanismos de cache
basados en el protocolo de memcached en sus capas de acceso
a datos puedan comenzar a hacer uso de este producto
minimizando el costo de adaptacin de tecnologa.
Google App Engine tambin brinda la posibilidad de
utilizar Memcached para optimizar la performance de las
aplicaciones que corren en esta plataforma.
Con respecto a OpenShift, Red Hat cuenta con su propio
producto de cache distribuido conocido por el nombre
comercial Infinispan, que ya exista antes de que se inicie la era
cloud, y formaba parte de la suite de productos de JBoss. Este
cache es tambin de tipo Key-value y brinda soporte
transaccional, con el adicional de soporte para NoSQL.
En el caso de IBM SmartCloud, su estrategia de cache
distribuida est basada en un producto propietario
comercializado como WebSphere eXtreme Scale, que se puede
utilizar tanto en clouds privados como pblicos, obteniendo
una gran mejora de performance para las aplicaciones.
VMware para dar solucin a la necesidad de contar con un
producto de grid de datos distribuidos, y no perder competencia
de mercado con los otros proveedores, puesto que no contaba
con productos de este tipo, adquiri GemFire y lo integr a su
Suite de VFabric. GemFire es un potente cache que permite
distribuir la carga y procesamiento de datos en mltiples nodos,
en propsito de optimizar el rendimiento, permitiendo
transaccionar de manera asncrona con su propia base de datos,
o con cualquier otra base de datos (por ejemplo SQL Server,
Oracle, MySQL, etc.). Adems, GemFire tiene la
particularidad que puede trabajar inclusive con nodos que
pueden encontrarse distribuidos en diferentes datacenters. Este
mecanismo lo hace especialmente atractivo brindando modelos
de alta flexibilidad y performance para centros de recuperacin
del desastre (del ingls Disaster recovery datacenters).
REFERENCIAS
[1] Erl, T. 2005. Service-Oriented Architecture: Concepts,
Technology, and Design. Editorial Prentice Hall PTR. ISBN-10:
0-13-185858-0
[2] Newcomer E., Lomow G. Understanding SOA with web
services (independent technology guides). Addison-Wesley
Professional, 2004. ISBN-10: 8-13-171113-7
[3] Josuttis, N. 2007. SOA in Practice, The Art of Distributed
System Design. Editorial O'Reilly. ISBN-10: 0-596-52955-4
[4] Hasan J., Duran M. 2006. Expert Service-Oriented Architecture
in C# 2005, second edition. Editorial Apress. ISBN 1-59059-
701-X
[5] Stevens, Wayne P., Glenford J. Myers, and Larry L.
Constantine. "Structured design." IBM Systems Journal 13.2
(1974): 115-139. ISBN-10:0-13-288895-5
[6] Pulier, E., Taylor, H. 2006. Understanding Enterprise SOA.
Editorial Manning. ISBN 1-932394-59-1
[7] Carter, S. 2007. The New Language of Business. SOA & Web
2.0. Editorial IBM Press, Pearson plc. ISBN-10: 0-13-195654-
X.
[8] Karmarkar, Anish, et al. Web service contract design and
versioning for SOA. Prentice Hall, 2009. ISBN-10: 0-13-
613517-X
[9] Amazon.com Inc. 2013. Amazon Elastic Compute Cloud
(Amazon EC2). http://aws.amazon.com/es/ec2/#functionality.
Pgina vigente al 12/05/2013.
[10] Amazon.com Inc. 2013. Amazon Cloud Watch.
http://aws.amazon.com/es/cloudwatch/. Pgina vigente al
21/05/2013.
[11] Amazon.com Inc. 2013. Amazon Machine Images (AMIs).
https://aws.amazon.com/amis/. Pgina vigente al 21/05/2013.
[12] Amazon.com Inc. 2013. Amazon EC2 con Microsoft Windows
Server y SQL Server. http://aws.amazon.com/es/windows/.
Pgina vigente al 21/05/2013.
[13] Amazon.com Inc. 2013. AMI de Amazon Linux.
http://aws.amazon.com/es/amazon-linux-ami/. Pgina vigente al
21/05/2013.
[14] Amazon.com Inc. 2013. Amazon Simple Storage Service
(Amazon S3). http://aws.amazon.com/es/s3/. Pgina vigente al
20/05/2013.
Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
[15] Amazon.com Inc. 2013. Amazon Relational DB Service
(Amazon RDS). http://aws.amazon.com/es/rds/. Pgina vigente
al 20/05/2013.
[16] Amazon.com Inc. 2013. Amazon SimpleDB (Beta).
http://aws.amazon.com/es/simpledb/. Pgina vigente al 20/05/
2013.
[17] Amazon.com Inc. 2013. Amazon Amazon Simple Queue
Service (Amazon SQS). http://aws.amazon.com/es/sqs/. Pgina
vigente al 20/05/2013.
[18] Amazon.com Inc. 2013. Overview of Security Processes. The
Hipervisor. http://aws.amazon.com/articles/1697. Pgina vigente
al 21/05/2013.
[19] Microsoft Corp. 2013, Windows Azure. Qu es Windows
Azure.http://www.windowsazure.com/eses/home/features/what-
is-windows-azure/. Pgina vigente al 12/05/2013
[20] Microsoft Corp. 2013, Windows Azure. How to Use the
Autoscaling Application Block. http://www.windowsazure.com/
en-us/develop/net/how-to-guides/autoscaling/. Pgina vigente al
12/05/2013
[21] Microsoft Corp. 2013, Windows Azure. Mquinas Virtuales.
http://www.windowsazure.com/es-es/home/features/virtual-
machines/. Pgina vigente al 21/05/2013
[22] Krishnan, S. 2010. Programming Windows Azure. Editorial
O'Reilly Media. ISBN-10: 0-59-680197-1
[23] Microsoft Corp. 2013, Windows Azure. Administracin de
datos. http://www.windowsazure.com/es-es/home/features/data-
management/. Pgina vigente al 21/05/2013
[24] Microsoft Corp. 2013, Windows Azure. Base de datos SQL.
http://www.windowsazure.com/es-es/pricing/details/sql-datab
ase/. Pgina vigente al 21/05/2013
[25] Microsoft Corp. 2013, Windows Azure. What are Service Bus
Queues. http://www.windowsazure.com/en-us/develop/net/how-
to-guides/service-bus-queues/. Pgina vigente al 21/05/2013
[26] Google Inc. 2012. Why App Engine. https://developers.
google.com/appengine/whyappengine. Pgina vigente al
12/05/2013.
[27] Google Inc. 2012. Google App Engine the platform for your
next great idea. https://cloud.google.com/files/GoogleApp
Engine.pdf. Pgina vigente al 22/05/2013.
[28] Google Inc. 2012. What Is Google App Engine?.
https://developers.google.com/appengine/docs/whatisgoogleapp
engine. Pgina vigente al 12/05/2013
[29] Google Inc. 2012. Using the Datastore.
https://developers.google.com/appengine/docs/java/gettingstarte
d/usingdatastore. Pgina vigente al 22/05/2013
[30] Red Hat Inc. 2013. Open Shift. Open Shift All Versions User
Guide.https://access.redhat.com/site/documentation/en-US/Ope
nShift/2.0/pdf/User_Guide/OpenShift-2.0-User_Guide-en-
US.pdf. Pgina vigente al 25/05/2013
[31] Red Hat Inc. 2013. Open Shift. Enterprise Features and Benefits.
https://www.openshift.com/enterprise-paas/features-and-benefi
ts . Pgina vigente al 25/05/2013
[32] Red Hat Inc. 2013. Open Shift. OpenShift Online User guide.
https://access.redhat.com/site/documentation/en-
US/OpenShift/2.0/html-single/User_Guide/index.html. Pgina
vigente al 14/06/2013
[33] Red Hat Inc. 2013. Open Shift. Scale Your Applications on the
web. https://www.openshift.com/developers /scaling. Pgina
vigente al 25/05/2013
[34] Red Hat Inc. 2013. Open Shift. New OpenShift Cartridge
Format Part1. https://www.openshift.com/blogs/new-openshift-
cartridge-format-part-1. Pgina vigente al 29/05/2013
[35] Red Hat Inc. 2013. Open Shift. How to Install OpenShift
Enterprise PaaS. https://www.openshift.com/blogs/installing-
enterprise-paas-part-1. Pgina vigente al 29/05/2013
235
[36] Red Hat Inc. 2013, Managing Databases in the Cloud.
https://www.openshift.com/blogs/manipulate-your-paas-
database. Pgina vigente al 18/06/2013
[37] SQLite 2013. SQLite. http://www.sqlite.org/. Pgina vigente al
18/06/2013.
[38] MongoDB 2013. Mongo DB. http://www.mongodb.org/. Pgina
vigente al 18/06/2013
[39] Red Hat Inc. 2013i, IronMQ on OpenShift. https://www.
openshift.com/quickstarts/ironmq-on-openshift. Pgina vigente
al 18/06/2013
[40] IronMQ. 2013. IronMQ, The Message Queue for the Cloud.
http://www.iron.io/mq. Pgina vigente al 16/06/2013.
[41] Red Hat Inc. 2013. Open Shift. New OpenShift Cartridge
Format Part2. https://www.openshift.com/blogs/new-openshift-
cartridge-format-part-2. Pgina vigente al 29/05/2013
[42] IBM Corp. 2011. IBM SmartCloud Enterprise. Enterprise class
cloud managed infrastructure. http://www-935.ibm.com/
services/us/en/managed-cloud-hosting/. Pgina vigente al
15/06/2013
[43] IBM Corp. 2011. Deploy an app to the cloud at lunch hour and
still have time to eat. http://www.ibm.com/cloud-computing/
us/en/paas.html. Pgina vigente al 12/05/2013
[44] IBM Corp. 2011 IBM SmartCloud Enterprise. http://www.ibm.
com/developerworks/cloud/library/cl-cloudfaq.html. Pgina vi-
gente al 12/05/2013
[45] IBM Corp. 2011. IBM Scale Out Network Attached Storage.
http://www-03.ibm.com/systems/storage/network/sonas/. Pgina
vigente al 15/06/2013.
[46] IBM Corp. 2013. IBM Storwize V7000 and Storwize V7000
Unified Disk Systems. http://www-03.ibm.com/systems/
storage/disk/storwize_v7000/.Pgina vigente al 16/06/2013.
[47] IBM Corp. 2013. IBM XIV Storage System. http://www-
03.ibm.com/systems/storage/disk/xiv/overview.html. Pgina vi-
gente al 16/06/2013.
[48] IBM Corp. 2013. IBM Integration Bus. http://www-
03.ibm.com/software/products/us/en/integration-bus/. Pgina vi-
gente al 16/06/2013.
[49] IBM Corp. 2013. IBM Systems Director. http://www-
03.ibm.com/systems/software/director/index.html. Pgina
vigente al 16/06/2013.
[50] IBM Corp. 2013. WebSphere eXtreme Scale. http://www-
03.ibm.com/software/products/us/en/websphere-extreme-scale/.
Pgina vigente al 16/06/2013.
[51] VMware Inc. 2013d. VMware vCloud Suite.
http://www.vmware.com/es/products/datacenter-virtualization/
vcloud-suite/how-it-works.html. Pgina vigente al 16/06/2013
[52] VMware Inc. 2013e. VMware vCloud Suite. http://www.
vmware.com/files/es/pdf/products/vCloud/VMware-vCloud-
Suite-Datasheet.pdf. Pgina vigente al 16/06/2013
[53] VMware Inc. 2013f. Soluciones para computacin en nube.
http://www.vmware.com/mx/cloud-computing.html. Pgina vi-
gente al 16/06/2013
[54] VMware Inc. 2010a. Storage Considerations for VMware
vCloud Director. Pooling of Storage Resources.
http://www.vmware.com/files/pdf/techpaper/VMW_10Q3_WP_
vCloud_Director_Storage.pdf. Pgina vigente al 16/06/2013.
[55] VMware Inc. 2013a. VMware vFabric RabbitMQ.
MESSAGING THAT JUST WORKS. http://www.vmware.com/
products/application-platform/vfabric-rabbitmq.html. Pgina
vigente al 12/05/2013
[56] VMware Inc. 2013. VMware vCenter Multi-Hypervisor
Manager 1.1 Release Notes. http://www.vmware.com/
support/mhm/doc/vcenter-multi-hypervisor-manager-11-release-
notes.html#capabilities. Pgina vigente al 16/06/2013
236 Franco Bocchio, 2013. Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA.
Revista Latinoamericana de Ingeniera de Software, 1(5): 207-236, ISSN 2314-2642
[57] OpenStack 2013o. OpenStack. http://docs.openstack.org/
trunk/openstack-compute/starter/content/OpenStack-d1e94.html.
Pgina vigente al 18/06/2013.
[58] OpenStack 2013, Infraestructura de Cmputo (Nova).
http://docs.openstack.org/diablo/openstack-compute/starter/
content/Open_Stack_Compute_Infrastructure_Nova_-
d1e124.html. Pgina vigente al 18/06/2013
[59] OpenStack 2013, Infraestructura de Cmputo (Nova). Funciones
y caractersticas. http://docs.openstack.org/diablo/openstack-
compute/starter/content/Functions_and_Features-d1e132.html.
Pgina vigente al 18/06/2013
[60] OpenStack 2013, Infraestructura de Almacenamiento (Swift).
http://docs.openstack.org/diablo/openstack-compute/starter/
content/OpenStack_Storage_Infrastructure_Swift_-d1e271.html.
Pgina vigente al 18/06/2013
[61] OpenStack 2013, Infraestructura de Almacenamiento (Swift).
Funciones y caractersticas. http://docs.openstack.org/
diablo/openstack-
compute/starter/content/Functions_and_Features-d1e279.html.
Pgina vigente al 18/06/2013
[62] OpenStack 2013e, Servicios de Imagen (Glance).
http://docs.openstack.org/diablo/openstack-compute/starter/
content/OpenStack_Imaging_Service_Glance_-d1e329.html.
Pgina vigente al 18/06/2013
[63] OpenStack 2013. Hyper-V Virtualization Platform.
http://docs.openstack.org/trunk/openstack-compute/admin/ cont
ent/hyper-v-virtualization-platform.html. Pgina vigente al
18/06/2013.
[64] OpenStack 2013, Tool support for image creation.
http://docs.openstack.org/trunk/openstack-image/content/ch_cre
ating_images_automatically.html.Pgina vigente al 18/06/2013
[65] OpenStack 2013. What is RDO?. http://openstack.redhat.com/
Frequently_Asked_Questions#What_is_RDO.3F. Pgina vigen-
te al 18/06/2013.
[66] OpenStack 2013. OpenStack Storage. http://www.openstack.
org/software/openstack-storage/. Pgina vigente al 18/06/2013.
[67] OpenStack 2013. Message Queue (Rabbit MQ Server).
http://docs.openstack.org/essex/openstack-
compute/starter/content/Message_Queue_Rabbit_MQ_Server_-
d1e223.html. Pgina vigente al 18/06/2013.
[68] OpenStack 2013. Message Queue (Rabbit MQ Server). Features.
http://www.rabbitmq.com/features.html. Pgina vigente al
18/06/2013.
[69] OpenStack 2013. Selecting a Hypervisor. http://docs.openstack.
org/trunk/openstack-compute/admin/content/selecting-a-hyper-
visor.html. Pgina vigente al 18/06/2013.
[70] Microsoft Corp., 2003. Application Architecture for .NET:
Designing Applications and Services. http://www.microsoft.
com/en-us/download/details.aspx?id=20275. Pgina vigente al
16/06/2013
Franco Bocchio. Es Especialista en Ingeniera
en Sistemas de Informacin por la Universidad
Tecnolgica Nacional, en el ao 2013, y el ttulo
de Ingeniero en Informtica en la Universidad
FASTA, en el ao 2006. Actualmente ejerce
como arquitecto de soluciones de Tecnologas de
la informacin y sus intereses de investigacin
se focalizan en nuevas arquitecturas y
plataformas tecnolgicas.