REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE

Transcripción

1 REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE OCTUBRE 2013 VOLUMEN 1 NUMERO 5 ISSN PUBLICADO POR EL GISI-UNLa EN COOPERACIÓN POR LOS MIEMBROS DE LA RED DE INGENIERÍA DE SOFTWARE DE LATINOAMÉRICA ARTÍCULOS TÉCNICOS PSP VDC : Una Propuesta que Incorpora el Diseño por Contrato Verificado al Personal Software Process Silvana Moreno, Álvaro Tasistro, Diego Vallespir Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Eduardo Diez Estudio Comparativo de Plataformas Cloud Computing para Arquitecturas SOA Franco Bocchio

2 REVISTA LATINAMERICANA DE INGENIERIA DE SOFTWARE La Revista Latinoamericana de Ingenieria del Software es una publicación tecnica auspiciada por la Red de Ingeniería de Software de Latinoamérica (RedISLA). Busca: [a] difundir artículos técnicos, empíricos y teóricos, que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión; [b] dar a conocer de manera amplia y rápida los desarrollos científico-tecnológicos en la disciplina de la región latinoamericana; y [c] contribuir a la promoción de la cooperación institucional entre universidades y empresas de la Industria del Software. La línea editorial, sin ser excluyente, pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros; a través del intercambio de información científico y tecnológica, conocimientos, experiencias y soluciones que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software. Comité Editorial RAUL AGUILAR VERA (México) Cuerpo Academico de Ingenieria de Software Facultad de Matemáticas Universidad Autonoma de Yucatán PAOLA BRITOS (Argentina) Grupo de Ingeniería de Explotación de Información Laboratorio de Informática Aplicada Universidad Nacional de Río Negro RAMON GARCÍA-MARTINEZ (Argentina) Grupo de Investigación en Sistemas de Información Licenciatura en Sistemas Departamento de Desarrollo Productivo y Tecnológico Universidad Nacional de Lanús ALEJANDRO HOSSIAN (Argentina) Grupo de Investigación de Sistemas Inteligentes en Ingeniería Facultad Regional del Neuquén Universidad Tecnológica Nacional BELL MANRIQUE LOSADA (Colombia) Programa de Ingeniería de Sistemas Facultad de Ingeniería Universidad de Medellín CLAUDIO MENESES VILLEGAS (Chile) Departamento de Ingeniería de Sistemas y Computación Facultad de Ingeniería y Ciencias Geológicas Universidad Católica del Norte JONÁS MONTILVA C. (Venezuela) Facultad de Ingeniería Escuela de Ingeniería de Sistemas Universidad de Los Andes MARÍA FLORENCIA POLLO-CATTANEO (Argentina) Grupo de Estudio en Metodologías de Ingeniería de Software Facultad Regional Buenos Aires Universidad Tecnológica Nacional Contacto JOSÉ ANTONIO POW-SANG (Perú) Maestría en Informática Pontifica Universidad Católica del Perú DIEGO VALLESPIR (Uruguay) Instituto de Computación Universidad de la Republica FABIO ALBERTO VARGAS AGUDELO (Colombia) Dirección de Investigación Tecnológico de Antioquia CARLOS MARIO ZAPATA JARAMILLO (Colombia) Departamento de Ciencias de la Computación y de la Decisión Facultad de Minas Universidad Nacional de Colombia Dirigir correspondencia electrónica a: Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ rgarcia@unla.edu.ar alternativo: rgm1960@yahoo.com Página Web de la Revista: Página Web Institucional: Dirigir correspondencia postal a: Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ Licenciatura en Sistemas. Departamento de Desarrollo Productivo y Tecnológico Universidad Nacional de Lanus Calle 29 de Septiembre No (1826) Remedios de Escalada, Lanús. Provincia de Buenos Aires. ARGENTINA. Normas para Autores Cesión de Derechos de Autor Los autores toman conocimiento y aceptan que al enviar una contribución a la Revista Latinoamericana de Ingenieria del Software, ceden los derechos de autor para su publicación electrónica y difusión via web por la Revista. Los demas derechos quedan en posesión de los Autores. Políticas de revisión, evaluación y formato del envío de manuscritos La Revista Latinoamericana de Ingenieria del Software recibe artículos inéditos, producto del trabajo de investigación y reflexión de investigadores en Ingenieria de Software. Los artículos deben presentarse redactados en el castellano en el formato editorial de la Revista. El incumplimiento del formato editorial en la presentación de un artículo es motivo de retiro del mismo del proceso de evaluación. Dado que es una publicación electrónica no se imponen limites sobre la cantidad de paginas de las contribuciones enviadas. También se pueden enviar comunicaciones cortas que den cuenta de resultados parciales de investigaciones en progreso. Las contribuciones recibidas están sujetas a la evaluación de pares. Los pares que evaluaran cada contribución son seleccionados por el Comité Editorial. El autor que envíe la contribución 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 evaluación y posterior comunicación. Del proceso de evaluación, 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 versión del articulo y su plazo de envio; ó [c] rechazado, en cuyo caso será devuelto al autor remitente fundando el motivo del rechazo. Temática de los artículos La Revista Latinoamericana de Ingeniería del Software busca artículos empíricos y teóricos que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión. La línea editorial pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas multimediales vinculados a la televisión digital, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros. Se privilegiarán artículos que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software. Política de Acceso Abierto La Revista Latinoamericana de Ingeniería de Software: Sostiene su compromiso con las políticas de Acceso Abierto a la información científica, al considerar que tanto las publicaciones científicas como las investigaciones financiadas con fondos públicos 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 científicas se encuentran disponibles a texto completo libre y gratuito en Internet, sin embargos temporales, y cuyos costos de producción editorial no son transferidos a los autores. No retiene los derechos de reproducción o copia (copyright), por lo que los autores podrán disponer de las versiones finales de publicación, para difundirlas en repositorios institucionales, blogs personales o cualquier otro medio electrónico, con la sola condición de hacer mención a la fuente original de publicación, en este caso Revista Latinoamericana de Ingeniería de Software. Lista de Comprobación de Preparación de Envíos Como parte del proceso de envío, se les requiere a los autores que indiquen que su envío cumpla con todos los siguientes elementos, y que acepten que envíos que no cumplan con estas indicaciones pueden ser devueltos al autor: 1. La contribución 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 años, así como a trabajos empíricos, para cualquier tipo de artículo (empírico o teórico). 3. Características artículos empíricos (análisis cuantitativo de datos): Se privilegian artículos empíricos con metodologías experimentales y cuasi experimentales, con pruebas estadísticas robustas y explicitación del cumplimiento de los supuestos de las pruebas estadísticas usadas. 4. Características artículos empíricos (análisis cualitativo de datos): Se privilegian artículos empíricos con estrategias de triangulación teórica-empírica, definición explícita de categorías orientadoras, modelo teórico de análisis, y análisis de datos asistido por computadora. 5. Características artículos de revisión: Para el caso de artículos de revisión, se evaluará que los mismos hayan sido desarrollados bajo el formato de meta análisis, la cantidad de referencias deben superar las 50, y deben explicitarse los criterios de búsqueda, bases consultadas y pertinencia disciplinar del artículo. 6. El artículo (en formato word y pdf) se enviará adjunto a un correo electrónico dirigido al contacto de la Revista en el que deberá constar la siguiente información: dirección postal del autor, dirección de correo electrónico para contacto editorial, número de teléfono y fax, declaración de que el artículo es original, no ha sido previamente publicado ni está siendo evaluado por otra revista o publicación. También se debe informar de la existencia de otras publicaciones similares escritas por el autor y mencionar la versión de la aplicación de los archivos remitidos (versión del editor de texto y del conversor a archivo pdf) para la publicación digital del artículo. 7. Loa Autores aceptan que el no cumplimiento de los puntos anteriores es causal de No Evaluación del articulo enviado. Compromiso de los Autores de Artículos Aceptados La Revista Latinoamericana de Ingeniería del Software busca ser una revista técnica de calidad, en cuyo desarrollo estén involucrados los investigadores y profesionales latinoamericanos de la disciplina. En este contexto, los Autores de artículos aceptados asumen ante la Revista y la Comunidad Latinoamericana de Ingeniería del Software el compromiso de desempeñarse como pares evaluadores de nuevas contribuciones.

3 PSP VDC : Una Propuesta que Incorpora el Diseño por Contrato Verificado al Personal Software Process Silvana Moreno Facultad de Ingeniería Universidad de la República Montevideo, Uruguay smoreno@fing.edu.uy Álvaro Tasistro Escuela de Ingeniería Universidad ORT Uruguay Montevideo, Uruguay tasistro@ort.edu.uy Diego Vallespir Facultad de Ingeniería Universidad de la República Montevideo, Uruguay dvallesp@fing.edu.uy Resumen El desarrollo de software se ha vuelto una actividad muy importante en el mundo actual. Existen números 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 ejecución. Este trabajo propone un nuevo proceso de desarrollo de software denominado PSP VDC que combina el enfoque del Personal Software Process (PSP) y del Diseño por Contrato Verificado (VDbC) con el objetivo de mejorar la calidad de los productos con respecto al PSP. Además se presenta una revisión sistemática de la literatura que busca conocer las adaptaciones al PSP que hayan sido documentadas, en particular aquellas que incorporan métodos formales. Términos Clave métodos formales, diseño por contrato verificado, personal software process, revisión sistemática. I. INTRODUCCION La construcción de software confiable es uno de los desafíos de la Ingeniería de Software. El tamaño, la complejidad de las aplicaciones de software, las tasas apresuradas de entregas de proyectos, las características 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 corrección de las aplicaciones, así como una pérdida de confianza en el mismo. La búsqueda de desarrollar software cero defectos ha dado lugar a un gran número de procesos y metodologías de desarrollo. El Personal Software Process (PSP) es uno de estos procesos. El PSP aplica disciplina de proceso y gestión cuantitativa al trabajo individual del ingeniero de software. Promueve la utilización de prácticas específicas 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 métodos formales también buscan construir software cero defectos. Estos métodos son un conjunto de técnicas y herramientas para especificar, desarrollar y verificar sistemas software mediante el uso de lenguaje matemático formalizado. Consisten en demostrar matemáticamente que los programas producidos cumplen sus especificaciones. El diseño por contrato (DbC) es una técnica para el diseño de los componentes de un sistema de software, mediante su especificación en un lenguaje formal, generalmente en la forma de pre- y post-condiciones escritas en Lógica de Primer Orden. Cuando las técnicas y herramientas incorporadas permiten demostrar que se cumplen las especificaciones establecidas, estamos en presencia de un método formal, generalmente llamado Verified Design by Contract (VDbC). En este artículo se presenta una adaptación del PSP que incorpora VDbC con el objetivo de mejorar, en comparación con el uso del PSP sin VDbC, la calidad de los productos desarrollados. Se denomina a esta propuesta PSP VDC. Esperamos de esta forma aportar en la búsqueda de procesos que ayuden a desarrollar productos de software muy cercanos a cero defectos. La estructura del artículo es la siguiente: primero se presentan las nociones básicas del diseño por contrato y el PSP (secciones II y III). Luego en la sección IV se presenta una revisión sistemática de la literatura realizada con el propósito de conocer las adaptaciones existentes al PSP que incorporan métodos formales. En la sección V se presenta el PSP VDC y la sección VI presenta algunas medidas de calidad del PSP VDC. Finalmente, se indican las conclusiones obtenidas (sección VII). II. DISEÑO POR CONTRATO Los métodos formales son un conjunto de técnicas para especificar, desarrollar y verificar sistemas de software mediante el uso del lenguaje matemático. Consisten en demostrar matemáticamente que los programas producidos cumplen sus especificaciones. El Diseño por Contratos (DBC) es un método propuesto por Bertrand Meyer, e inspirado en las ternas de Hoare, para especificar el comportamiento de módulos de software [4], [5]. La idea principal detrás 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 método definido por la clase, y en cambio la clase da como garantías a los clientes ciertas propiedades que se cumplen luego de finalizada la ejecución del método invocado. Ciertas implementaciones del DbC permiten que los contratos sean verificables en tiempo de ejecución. Los contratos son incluidos en el código del programa en una determinada sintaxis, y se traducen a código ejecutable por el compilador. Por lo tanto, cualquier violación del contrato que se produce mientras se ejecuta el programa puede ser detectado inmediatamente. Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

4 Los contratos de software se especifican mediante la utilización de expresiones lógicas 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 orientación a objetos las precondiciones y poscondiciones normalmente se definen a nivel de los métodos de las clases. Una precondición 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 poscondición da como garantías al cliente ciertas propiedades que se cumplen después de la llamada al método. En definitiva, especifica lo que se cumple luego de que se ejecuta el método. Visto desde el lado del proveedor, la poscondición es lo que éste debe asegurar que se cumpla, siempre y cuando la precondición se respete al momento de invocar el servicio. El Java Modeling Language, abreviado JML y en español «Lenguaje de Modelado para Java» es un lenguaje de especificación para programas Java. Las especificaciones JML describen formalmente el comportamiento de clases y métodos; se escriben como comentarios de anotación Java en el código fuente, que luego pueden compilarse con cualquier compilador de Java [6]. Añadir especificaciones JML a un programa ayuda a comprender qué función debe realizar un método o una clase. También ayuda a encontrar defectos en los programas, puesto que se puede comprobar si un método cumple con su especificación cada vez que se ejecuta. Existen herramientas que permiten compilar la especificación formal para ciertos lenguajes de especificación. Para el JML existe el compilador JMLC, este es una extensión de un compilador Java y compila los programas Java con especificaciones JML. En el código generado se agregan instrucciones ejecutables que chequean en tiempo de ejecución si los métodos cumplen con sus especificaciones. En caso de que una especificación no se cumpla, se interrumpe la ejecución del programa y se notifica cuál es la especificación 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 cláusulas específicas para indicar las precondiciones y las poscondiciones de un método: requires y ensures. Estas cláusulas deben ir situadas justo antes de la declaración del método. Además, el JML añade un conjunto de operadores que hace más cómodo en muchos casos construir aserciones complejas. Entre estos operadores se incluyen los cuantificadores más comunes (\forall, \exists, \sum, \product, \max, \min, etc) que hacen del JML un lenguaje similar al lenguaje de predicados de lógica. También el JML define dos seudo variables que pueden ser utilizadas en las poscondiciones de los métodos; \result: valor devuelto por el método y \old(e): valor de la expresión E al comenzar la ejecución del método. Presentamos a continuación una forma de especificar utilizando JML el método merge. Dicho método recibe como parámetros dos vectores de enteros ordenados de menor a mayor. El método retorna otro vector con esos elementos ordenados de menor a mayor. Además, los vectores de entrada no deben ser alterados, es decir, sus valores se mantienen incambiados al salir del método. La firma del método es la siguiente: public int[] getmerge(int[] a, int[] b) Al invocar al método se deben pasar dos vectores ordenados de menor a mayor, lo que nos indica una precondición que se debe cumplir. Para cumplir con dicha precondición es necesario que para todos los elementos del vector se cumpla que el elemento que está en la posición i del vector sea menor o igual al elemento que se encuentra en la posición i+1. Una forma de especificar formalmente dicha precondición se muestra en las siguientes dos aserciones. /*@ requires (\forall int i; i >= 0 && i < a.length-1; a[i] <= /*@ requires (\forall int j; j >= 0 && j < b.length-1; b[j] <= El cuantificador \forall sirve para recorrer el vector desde una posición y en determinado rango, haciendo cumplir determinada condición. 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 precondición 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 método se debe cumplir que los vectores de entrada no fueron alterados. Esto se especifica como una poscondición 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 posición después de llamar al método 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] == /*@ ensures (\forall int j; j >= 0 && j <= b.length-1; b[j] == Cabe aclarar, que en ambos casos se podría 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 método. Veamos ahora las condiciones que se deben cumplir en lo que respecta al vector esperado como resultado del método. Como se mencionó anteriormente el vector devuelto debe contener de forma ordenada los mismos elementos que los vectores pasados por parámetro. 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] <= 154 Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

5 Una forma de especificar informalmente que el vector devuelto contenga los mismos elementos de los vectores pasados por parámetro 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 + 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: Cada ingeniero es diferente, para ser más eficiente, debe planificar su trabajo basándose 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 más efectivo evitar los defectos que detectarlos y corregirlos. Trabajar bien es siempre la forma más rápida y económica 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 están 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 través 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. /*@ 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 especificación completa para el método getmerge se muestra de forma más clara en la figura 2. La especificación de contratos ejecutables permite introducir pruebas en el propio código 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 técnica 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 metodología de desarrollo de software creada por el Instituto de Ingeniería del Software (SEI). Está dirigido a los ingenieros, permitiendo mejorar la forma en la que construyen software. Considera aspectos como la planificación, calidad, estimación de costos y productividad. El PSP fue diseñado para ayudar a los ingenieros a seguir un proceso disciplinado de ingeniería del software, enseñándoles 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 pequeños de menos de líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos [2], [3]. Los principios del PSP son: Fig. 1. Fases del PSP Para cada fase el ingeniero recoge la información del tiempo empleado en la fase y los defectos inyectados y removidos. La información 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 descripción de los defectos que deben registrarse para cada tipo. El PSP propone una vista de cuatro dimensiones para lograr un diseño completo. En la vista interna-estática se especifica la lógica interna del programa, normalmente el pseudo código. La vista interna-dinámica corresponde a las posibles maquinas de estado, es decir, los estados, las transiciones y acciones entre estados que puede tener el programa. Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

6 156 TABLA I. TIPOS DE DEFECTOS DEL PSP Tipo Nombre Descripción 10 Documentación Comentarios o mensajes 20 Sintaxis Ortografía, puntuación, tipos, formato de instrucciones 30 Componentes o configuración Administración de cambios, control de versiones, bibliotecas 40 Asignación Declaración, nombres duplicados, alcance, límites 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 Función o lógicos Defectos por lógica, apuntadores, ciclos, recursión, cálculos, funciones 90 Sistema Configuración, sincronización, memoria 100 Ambiente Problemas de diseño, compilación, prueba, u otros con los sistemas de desarrollo La vista externa-estática corresponde a la estructura de clases y la vista externa-dinámica define las interacciones entre el sistema y el usuario (diagramas de casos de uso, diagrama de secuencia del sistema, etc). La información recabada en cada una de estas vistas es definida en cuatro templates como se muestra en la tabla II. TABLA II. TEMPLATES DE DISEÑO DEL PSP Interna Externa Estática Logic Specfication Template Function Specfication Template Dinámica State Machine Template Operational Specification Template El PSP se enseña mediante un curso. Durante el mismo, los ingenieros construyen programas de software (ejercicios) mientras aprenden progresivamente a planificar, desarrollar y seguir las prácticas del PSP. En el primer ejercicio, se comienza con un proceso simple (el proceso base, llamado PSP 0); a medida que se avanza en el proceso se agregan nuevas fases como Design Review y Code Review, así como también Fig. 2. Especificación método getmerge formas de estimar tiempos y tamaño. Los nombres de los procesos y los elementos que se van incorporando durante el curso se muestran en la figura 3. El nivel 2.1 es el proceso completo del PSP. Fig. 3. Niveles del PSP IV. REVISIÓN SISTEMÁTICA Es de nuestro interés conocer las adaptaciones al PSP que hayan sido documentadas, en particular nos interesa conocer las adaptaciones que incorporan métodos formales. Presentamos en esta sección una revisión sistemática que busca conocer la literatura existente sobre adaptaciones al PSP. Una revisión sistemática de la literatura es un medio de identificación, evaluación e interpretación de toda la información que se disponga relativa a una pregunta de investigación, área temática o fenómeno de interés [7]. La revisión sistemática realizada responde a dos preguntas de investigación: Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

7 (1) Se han realizado adaptaciones al PSP? (2) Las adaptaciones propuestas al PSP incorporan métodos formales? Cómo lo hacen? Para responder a estas preguntamos definimos un protocolo que especifica los métodos que se utilizan para llevar a cabo la revisión sistemática. Se define la cadena de búsqueda 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 sinónimos de la palabra adaptar, es decir las diferentes formas de presentar un cambio al PSP y la última parte se refiere al uso de métodos formales. Las búsquedas fueron realizadas en bibliografía en idioma inglés, por ende la cadena de búsqueda es en inglés: ( personal software process ) and ((adapting or extending or over or incorporating) or ( formal methods or design by contract )) Las bibliotecas digitales utilizadas para la búsqueda de artículos fueron SCOPUS, Springer, IEEE Xplore y EBSCO. Estos buscadores abarcan las principales colecciones de revistas y actas de conferencias de ingeniería de software. Además, se realizó una búsqueda 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 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, capítulos, secciones y publicaciones en general referentes a PSP y TSP. Esta búsqueda permite encontrar trabajos realizados con respecto al tema de interés que posiblemente no hayan sido indexados en las bibliotecas digitales. Cada artículo encontrado en la búsqueda es evaluado para decidir si debe o no incluirse teniendo en cuenta el título, las palabras claves y el resumen. Aquellos artículos que cumplan al menos una de las siguientes condiciones serán excluidos: No se centran en el Personal Software Process Capítulos de libros o libros Duplicados en diferentes fuentes No escritos en inglés No propongan una adaptación al PSP o no incorporen métodos formales al mismo Debido a que la cantidad de artículos que se espera encontrar es muy baja optamos por no realizar un control de la calidad de los artículos. La síntesis de datos consistirá en agrupar a los artículos en base a las dos preguntas de investigación planteadas, es decir, si es un artículo que adapta a PSP mediante la incorporación de métodos formales, si es un artículo que adapta a PSP en cualquier otro aspecto o si es un artículo que utiliza métodos formales con PSP pero sin adaptarlo. Al aplicar la cadena de búsqueda en la base de IEEE se obtienen 31 resultados. En esta base se filtra la búsqueda 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 PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN Para SCOPUS se agrega el filtro de excluir los artículos pertenecientes a las aéreas Life Sciences y Health Sciences obteniendo 20 resultados. Por último en la base de Springer se filtran sólo artículos, de la disciplina Computer Science y en inglés, obteniendo 20 resultados. En A Bibliography of the Personal Software Process (PSP) and the Team Software Process (TSP) se encuentra 1 artículo que adapta PSP utilizando métodos formales. Este artículo también fue encontrado con EBSCO e IEEE. En los Simposios de TSP se encontró 1 artículo que no fue encontrado por ninguna otra fuente así como una presentación (es decir, copias de diapostitivas). Ambos son del Simposio 2012, el artículo combina métodos formales con PSP y la presentación incorpora al PSP técnicas basadas en modelos. Algunos artículos fueron publicados en más de una revista/conferencia y/o están repetidos en más de un buscador, por lo que se tienen en cuenta una sola vez a estos artículos resultando: EBSCO 34 artículos Springer 19 artículos Scopus 18 artículos IEEE 29 artículos Simposio TSP artículos Simposio TSP presentación. Finalmente al aplicar los criterios de inclusión/exclusión para los resultados de cada buscador el resultado es: Scopus 2 artículos IEEE 1 artículo Simposio TSP artículo Simposio TSP presentación Tres de los cinco trabajos encontrados adaptan el PSP para incorporar métodos formales. Babar y Potter proponen un nuevo proceso denominado B- PSP que incorpora el método formal B al proceso de desarrollo personal [8]. Suzumori, Kaiya y Kaijiri proponen la combinación del método 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 adaptación el PSP incorporando técnicas basadas en modelos. La propuesta de adaptación 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 cómo 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 utilización de dos checklists de diseño y dos checklists de código, uno para cada rol. 157

8 La presentación del Simposio TSP propone una adaptación al PSP incorporando técnicas de integración basadas en modelos. El proceso propuesto modifica la fase de diseño para desarrollar un modelo de diseño 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 revisión de diseño incorpora la comprobación del modelo mediante una herramienta de análisis estático. Por último las fases de código y Unit Test incorporan la generación de código parcial y la generación de los test en base a los modelos respectivamente. Estas dos últimas adaptaciones no serán explicadas en mayor profundidad ya que no hacen uso de los métodos formales. A. Propuesta B-PSP [8] Los autores de la propuesta B-PSP combinan los enfoques de métodos 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 básica y la dependencia entre machines, generando las obligaciones de pruebas y brindando animación. Durante la fase de Auto Proof se realiza una demostración interactiva de la prueba mediante el B toolkit. B-PSP propone además la generación de código automáticamente, 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 introducción de defectos y evitarlas en el futuro. Al igual que PSP se recogen los datos de tiempo y esfuerzo; en esta propuesta se registran además las líneas de especificación formal (LOS) y la cantidad de pruebas (# Proof). B. Propuesta VDM over PSP [9] La propuesta VDM over PSP propone combinar el método formal VDM y PSP con el objetivo de mejorar la gestión de la calidad. Esta gestión considera dos aspectos: la prevención de defectos y la eliminación de defectos. Para la prevención de defectos en VDM over PSP se utilizan checklist y guidelines de revisión al igual que en PSP, mientras que la estrategia para eliminar defectos es agregar actividades que permitan logar una mayor calidad en el diseño. 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 VDM over PSP agrega y modifica varias fases al PSP, específicamente modifica la fase de diseño para incorporar la especificación formal en el lenguaje VDM-SL. Luego de la especificación formal se realiza la revisión de diseño 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 búsqueda 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 dinámica. En esta última fase no aplican técnicas de verificación 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 técnicas 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. Además de VDM over PSP0, el usuario utiliza VDM-SL para especificar tipos de datos, pre-condiciones, descripciones de funciones implícitas e invariantes de cada tipo de datos. VDM over PSP2: se introducen las especificaciones lógicas en VDM-SL. Además de VDM over PSP1, el usuario especifica la especificación interna de cada función. 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 basándose 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 diseño para aumentar la confianza en el diseño, el uso de los métodos formales con sus lenguajes de especificación formal y sus herramientas serán eficaces en la reducción de los defectos. VDM-PSP incorpora el método formal VDM que dispone de varios lenguajes de especificación formal y la VDM toolkit que permite el chequeo de sintaxis, chequeo de tipos, la 158 Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

9 utilización del intérprete y la generación de obligaciones de pruebas. La propuesta planteada mantiene la mismas fases que PSP, modificando la fase de diseño para incorporar la especificación formal utilizando alguno de los lenguajes que provee VDM (por ejemplo, VDM ++) y la fase de revisión de diseño para incorporar la herramienta VDM toolkit. No queda clara en la propuesta en qué fase se realiza la generación de las obligaciones de la prueba. Planning Design Design review Code Code review Compile Unit Test Postmortem Fig. 6. Fases de VDM-PSP La revisión sistemática realizada permite conocer la existencia de las adaptaciones realizadas al PSP que incorporan métodos formales. Los trabajos encontrados presentan diferentes formas de incorporar métodos formales al PSP, agregando nuevas fases, modificando fases o simplemente introduciendo actividades al PSP (manteniendo sus fases). Sin embargo, ninguno de los trabajos encontrados incorpora el enfoque de Diseño por Contrato (DbC). Este método formal tiene sus características propias que difieren tanto de B como de VDM. Por esto, es necesaria una adaptación particular al PSP de forma de poder usar el DbC en conjunto con el PSP. V. EL PSP VDC El PSP VDC es una adaptación al PSP que incorpora el enfoque de diseño por contrato verificado. El objetivo de esta adaptación es mejorar la calidad (defectos/kloc) del producto de software desarrollado, en comparación con el PSP. La figura 7 muestra el agregado de estas dos nuevas fases. Fig. 7. Incorporando las fases de Formal Specification y Proof El PSP propone revisiones personales como mecanismo efectivo y rápido de remoción de defectos. Específicamente, propone la revisión del diseño y la revisión del código. Durante estas revisiones el ingeniero revisa el trabajo realizado siguiendo una check list en busca de defectos. En PSP VDC la nueva fase de Formal Specification puede incurrir a la inyección de defectos. Siguiendo la misma idea de PSP de intentar remover la mayor cantidad de defectos de forma temprana se propone una fase de revisión de la especificación formal. La fase Formal Specification Review se realiza a continuación de la especificación formal y su objetivo es revisar, con la ayuda de una check list, la especificación recientemente construida. Luego de construida y revisada la especificación formal se propone una fase de compilación de la especificación formal. Durante esta fase se compila la especificación formal utilizando herramientas permitiendo generar código ejecutable además de remover defectos. En la figura 8 se presenta el agregado de estas fases. A. Incorporando VDbC al PSP Para incorporar VDbC se deben realizar las actividades de Especificar Formalmente y Demostrar Formalmente la correctitud del código con respecto a dicha Especificación. 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 PSP VDC 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 diseño y realizada la revisión del mismo. Durante esta fase se especifican los métodos de las clases anteriormente diseñados y revisados. Llevar a cabo la especificación en una nueva fase permite conocer el esfuerzo (tiempo) dedicado exclusivamente a especificar y conocer los defectos que se inyectan y remueven al realizar esta actividad. La fase de Proof es propuesta luego de la compilación de código. Durante esta fase se realiza la demostración de la correctitud del código con respecto a la especificación formal. Al igual que en la fase de Formal Specification el proponer una nueva fase para la verificación permite conocer los tiempos y defectos específicamente asociados a la verificación formal. Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN Fig. 8. Incorporando las fases de Formal Specification review y compile B. Desde Diseño a Codificación Un proceso de desarrollo de software consiste de un conjunto ordenado de pasos a seguir para lograr un producto de software que resuelva un problema específico. El PSP define a través de las fases de Design, Design Review, Code, Code Review, Compile, Unit Testing y Postmortem un proceso disciplinado donde las salidas de una fase son la entrada directa a la fase inmediatamente posterior. 159

10 En el PSP, una de las actividades a realizar durante la fase de Design es el pseudo código. El pseudo código brinda una descripción en alto nivel del programa. En el contexto del PSP VDC consideramos que la especificación formal de los métodos de las clases debe realizarse antes que el pseudo código, por lo que eliminamos la actividad de pseudo código de la fase de diseño e incorporamos una fase nueva de pseudo código a posteriori de la revisión de la especificación formal. De esta forma mantenemos la idea de un proceso de desarrollo de software bien definido donde la especificación formal realizada es tomada como entrada para realizar el pseudo código y luego éste pseudo código es entrada para la codificación. Luego de la nueva fase de pseudo codigo en PSP VDC se propone una fase de revisión del pseudo código manteniendo los lineamientos de PSP en lo que refiere a la detección temprana de defectos. El agregado de estas nuevas fases se presenta en la figura 9. cual podríamos pensar (analizar costo-beneficio) en eliminar las fases de Test Case Construct y Unit Test del PSP VDC. Fig. 10. Incorporando la fase de Test Case Construct D. Las Fases del PSPVDC El PSP VDC incorpora nuevas fases y modifica otras como fuimos describiendo en las secciones anteriores. La figura 11 ilustra todas las fases del PSP VDC ; las cuales se describen a continuación. Planning Las actividades a realizar en esta fase son las mismas que en PSP; obtener los requerimientos, estimar el tamaño del producto, estimar el esfuerzo y estimar los defectos. Fig. 9. Incorporando las fases de Pseudo Code y Pseudo Code Review C. Construcción de los Casos de Prueba En el PSP la actividad de construcción de los casos de prueba no está claramente definida en los scripts. Durante los cursos del PSP algunos instructores optan por realizar la construcción 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 diseñar y ejecutar las pruebas, pudiendo estar contenido como tiempo parcial de Diseño más tiempo de Unit Test o exclusivamente como tiempo de Unit Test. En el PSP VDC nos interesa tener claramente diferenciado el tiempo dedicado a la construcción de los casos de pruebas ya que ayudará a conocer y mejorar el proceso. Por lo tanto, decidimos agregar al PSP VDC una nueva fase dedicada a la construcción de los casos de prueba. Esta fase se realiza inmediatamente después de la fase de Design Review. Los casos de prueba buscan probar la especificación informal del programa a construir utilizando el diseño para poder construir las pruebas. La figura 10 muestra el agregado de la fase de Test Case Construct al PSP VDC. Luego de analizar los resultados experimentales de aplicar PSP VDC se podría mostrar (o no) que la inclusión de VDbC reduce significativamente los defectos que llegan a UT, con lo Design Durante el diseño se define la estructura del programa, así como las clases, métodos, interfaces, componentes e interacciones entre ellos. El PSP propone cuatro vistas y templates para mantener la información de un buen diseño. Una de estas cuatro vistas es la interna-estática en la cual se define el pseudo código del programa. En PSP VDC el pseudo código se pospone a una fase posterior, por lo que se elimina de la fase de diseño la utilización del Logic Template utilizado en PSP para el pseudo código. Además, durante el diseño en PSP se incluye el diseño de los casos de prueba. En PSP VDC se propone realizar esta actividad en una fase posterior dedicada específicamente a generar los casos de prueba. El motivo de esta separación es nuestro interés por disponer del tiempo dedicado exclusivamente a diseñar y el tiempo dedicado exclusivamente a construir los casos de prueba. Design Review La revisión de diseño 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 revisión de diseño. Durante esta fase se construye el conjunto de casos de prueba a utilizar para probar el programa. Disponer de la información del tiempo 160 Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

11 dedicado a construir los casos de prueba y a realizar las pruebas unitarias nos permitirá evaluar el beneficio de mantener estas fases en el proceso o eliminarlas. Formal Specification Durante esta fase se especifican formalmente los contratos (Design by Contract). Las pre- y post- condiciones de los métodos y el invariante de la clase son especificados en un lenguaje formal. Postmortem Por último, durante Postmortem el ingeniero analiza su proceso, prestando atención a los errores o dificultades en la aplicación del proceso para mejorar a futuro. Formal Specification Review La revisión de la especificación formal tiene el propósito de detectar lo defectos inyectados durante la especificación formal. Se propone la utilización de una checklist para que el ingeniero revise manualmente la especificación formal en busca de posibles defectos. Formal Specification Compile La compilación consiste en el chequeo automático (utilizando una herramienta) de la sintaxis de la especificación formal. Pseudo Code Durante esta fase se escribe el pseudo código de los métodos 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 código utilizando como entrada a esta fase la salida de las fases anteriores (la especificación formal revisada y compilada correctamente). Pseudo Code Review En esta fase se revisa el pseudo código 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 diseño construido utilizando un lenguaje de programación, luego se realiza una revisión manual y por último se compila el código utilizando una herramienta. Proof La idea general de esta fase es complementar el código con una prueba formal. El objetivo es que la prueba provea evidencia de la corrección del código con respecto a las especificaciones formales (Diseño 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 PSP VDC optamos por mantener la fase de Unit Test aunque se realice una demostración formal. La demostración formal nos brinda evidencia de la correctitud del código con respecto a la especificación formal, pero nada garantiza que la especificación 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 PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN Fig. 11. Fases de PSP VDC PSP VDC es guiado por un conjunto de scripts que permiten seguir el proceso de forma disciplinada y facilitan la recolección de datos. En la figura 12 se presenta el Process Script y en la figura 13 el Development Script de PSP VDC. VI. CALIDAD EN PSP VDC La calidad en PSP incluye: estimar el número total de defectos inyectados y removidos estimar el número de defectos inyectados y removidos por fase estimar el tiempo requerido por fase Se presenta en esta sección las modificaciones al PSP para planificar la calidad en PSP VDC. Para estimar el número total de defectos inyectados, PSP utiliza la estimación del tamaño del programa y datos históricos a cerca de los defectos inyectados por KLOC. Para la estimación del número de defectos inyectados y removidos por fase, PSP realiza una distribución del total estimado basándose en datos históricos. En PSP VDC se deben de tener en cuenta las nuevas fases para las estimaciones de tiempo requerido por fase y el número de defectos. Inicialmente en PSP VDC no se disponen de datos históricos, por lo que la estimación inicial se realiza aplicando juicio de expertos. Después de realizar varios estudios, los datos acumulados estarán 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 inyección, y aprender a evitar que ocurran nuevamente. El PSP propone revisiones como un método 161

12 recomendado para la eliminación de defectos, ya que es aún más 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 relación al número total de defectos que llegan a la fase. Es una medida usualmente utilizada para conocer la efectividad de las revisiones de diseño y código así como la compilación y el testing. En PSP VDC 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 compilación. En PSP VDC ajustamos el cálculo teniendo en cuenta las nuevas fases que preceden a la fase de compilación. 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 número 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 número 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, evaluación y prevención. 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 evaluación (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 prevención (prevention cost) es el tiempo dedicado a la identificación y resolución de las causas de los defectos. Siguiendo la misma idea, en el PSP VDC el costo por fallo corresponde al tiempo dedicado a las fases de Code, Compile, Formal Specification Compile, Proof, y Testing. El costo de evaluación, 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 están asociados a una baja cantidad de defectos en testing y por lo tanto una alta calidad del producto. En PSP VDC, modificamos el indicador incorporando el tiempo empleado en la fase de Formal Specification Review y Pseudo Code Review. La forma de calcularlo es: % Appraisal COQ Design Review Time + Code Review Time FSR Time + PCR Time = 100 Total Development 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 PSP VDC modificamos el indicador con el propósito de incorporar el tiempo dedicado en las fases de Formal Specification Compile (FSC) y el tiempo empleado en la fase de Proof. El nuevo cálculo es: Code CompileTime + Test Time + FSC Time + Proof Time % FailureCOQ = 100 Total Development Time Una medida útil del COQ es la tasa entre los costos de evaluación y fallo (A/FR). Dicho indicador es modificado de forma implícita 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 PSP VDC luego de realizar estudios empíricos 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 común 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 búsqueda de formas de desarrollar software con bajo número de defectos ha dado lugar al desarrollo de un variado número de procesos y métodos. El cometido de dichos procesos es construir software de calidad, en el plazo estipulado y dentro de los costos previstos. En este artículo presentamos un nuevo proceso de desarrollo de software que combina los enfoques del proceso de desarrollo personal (PSP) y la técnica de diseño por contrato verificado (VDbC) Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

13 Purpose Entry Criteria To guide the development of module-level programs - 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 - 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. 2 Development - 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. 3 Postmortem 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 PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

14 Purpose Entry Criteria To guide the development of small programs - 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 - 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. 2 Design Review 3 Test Case Construct 4 Formal Specification 5 Formal Specification Review 6 Formal Specification Compile - 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. 7 Pseudo Code - 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. 8 Pseudo Code Review - 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. 9 Code - 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 Review - Follow the Code Review script and checklist and review the code. - Fix all defects found. - Record defects in the Defect Recording log. 164 Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

15 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 PSP VDC 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. Además, se presenta una revisión sistemática de la literatura que resume la información existente sobre adaptaciones realizadas al PSP y particularmente aquellas que incorporan métodos formales. Conocer las diferentes adaptaciones realizadas al PSP que incorporar métodos formales brinda conocimiento acerca de las formas posibles de combinar el enfoque de PSP y métodos formales. Nuestro trabajo a futuro consiste en realizar experimentos controlados que nos permitan comparar la calidad y productividad del PSP y del PSP VDC. Se deberá realizar una buena planificación teniendo en cuenta el armado de los cursos de PSP, PSP VDC, métodos formales y de técnicas de verificación de programas, además se deberá capacitar a los sujetos en la aplicación de los procesos y herramientas de soporte. El análisis de resultados de los experimentos nos permitirá conocer cómo funciona el PSP VDC en la práctica y así poder mejorarlo. REFERENCES [1] Ian Sommerville. Ingeniería del Software 7a edición. University of Lancaster. ISBN , 2005 [2] Watts S. Humphrey. PSP: A Self-Improvement Process for Software Engineers. Addison-Wesley Professional; March [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): [5] Hoare, C.A.R. An Axiomatic Basis for Computer Programming, Communications of the ACM 12, 10 (1969): [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 [8] Abdul Babar, John Potter. Adapting the Personal Software Process (PSP) to Formal Methods. Australian Software Engineering Conference (ASWEC'05), 2005, pp [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, [13] Vallespir, Diego and Nichols, William. Analysis of Design Defects Injection and Removal in PSP, Proceedings of the TSP Symposium 2011: A Dedication to Excellence. Atlanta, GA, Sept [14] Vallespir, Diego and Nichols, William. An Analysis of Code Defect Injection and Removal in PSP, TSP Symposium 2012 Proceedings (CMU/SEI-2012-SR ). Software Engineering Institute, Carnegie Mellon University, cfm [15] Gilb, Tom and Graham, Dorothy. Software Inspection. Addison- Wesley, 1994 (ISBN ). Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

16 Silvana Moreno. Es Magister en Informática por la Universidad de la República, Facultad de Ingeniería. Es Profesora Asistente del Área de Ingeniería de Software en la Universidad de la República. Sus intereses en investigación son los procesos de desarrollo de software y su combinación con los métodos formales y cómo se pueden combinar estos enfoques para aumentar la calidad de los productos. Álvaro Tasistro. Es Doctor en Ciencia de la Computación por la Universidad de Gotemburgo. Actualmente dirige la Cátedra de Teoría de la Computación y el grupo de investigación en Computación Teórica de la Escuela de Ingeniería de la Universidad ORT Uruguay. Sus áreas de interés son la Lógica y la Teoría de la Programación. Diego Vallespir. Es Profesor Adjunto de la Facultad de Ingeniería de la Universidad de la República (UdelaR), Uruguay, es Director del Centro de Posgrados y Actualización Profesional en Informática de la UdelaR, es Director del Grupo de Investigación en Ingeniería de Software de la UdelaR. Es Ingeniero en Computación, Magister en Informática y Doctor en Informática por la Facultad de Ingeniería, UdelaR. Tiene varios artículos publicados en conferencias internacionales. Sus áreas de interés en investigación son ingeniería de software empírica, procesos de desarrollo de software y pruebas de software. Su hobby es divertirse. 166 Silvana Moreno, Alvaro Tasistro, Diego Vallespir PSPVDC: Una propuesta que incorpora el Diseño por Contrato Verificado al Personal Software Process Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

17 Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Eduardo Diez Laboratorio de Investigación y Desarrollo en Aseguramiento de Calidad de Software Grupo Investigación en Sistemas de Información Departamento Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Remedios de Escalada, Buenos Aires, Argentina. ediez@unla.edu.ar Resumen La función de aseguramiento de la calidad del software (SQA) se debe basar en un planificado y sistemático diseño de acciones y métodos, requeridos para garantizar la calidad del mismo. En el presente trabajo, se presenta un diseño de acciones y métodos que constituyen un enfoque práctico para el desempeño de la función de SQA en una organización, adaptado especialmente a la metodología IDEAL para el desarrollo de sistemas basados en el conocimiento. Este enfoque no pretende ser exclusivo y en ningún caso limita o inhibe la aplicación de otras acciones, métodos o modelos, sino que podrá ser su complemento, adaptándolo convenientemente. El enfoque o modelo de aseguramiento de la calidad del software que tiene las siguientes características: el modelo de aseguramiento de calidad de software sugerido es una interfaz a una metodología, ideal en este caso, de desarrollo de software, el modelo que aquí se presenta no es una metodología en sí misma, sino que debe acoplarse a una metodología de desarrollo para poder implementarse, esta interfaz está compuesta por módulos independientes, donde cada uno de ellos se asocia a ciertos procesos de la metodología ideal. Palabras Claves Aseguramiento de la calidad del software, sistemas basados en el conocimiento, metodología ideal. I. INTRODUCCION La calidad es una cualidad esencial de cualquier producto, generado por una organización, 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 construía el producto. La primera función de control y de aseguramiento de la calidad formal fue introducida por los laboratorios Bell en 1916 y se extendió rápidamente por todo el mundo de las manufacturas. Hoy en día, cada empresa tiene un mecanismo que asegura la calidad de sus productos, de hecho, durante la pasada década se ha usado ampliamente como táctica de mercado, la declaración explícita de mensajes que ponían de manifiesto la calidad ofrecida por las empresas. La evolución del aseguramiento de la calidad en el desarrollo de software ha sido paralela a la evolución de la calidad en la fabricación de hardware. Durante los primeros años de la informática (los años 50 y 60), la calidad era responsabilidad únicamente del programador. Durante los años 70 se introdujeron estándares de aseguramiento de la calidad para el software en los contratos militares de desarrollo de software y se extendieron rápidamente en los desarrollos de software del mundo comercial. La función de aseguramiento de la calidad del software (SQA) se debe basar en un planificado y sistemático diseño de acciones y métodos, 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 organización, tales como ingenieros de software, líderes de proyecto, clientes, comerciales y personas que trabajan dentro del equipo de SQA (una conformación del mismo se presentará en capítulos 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 estándares preestablecidos? Se han aplicado las técnicas y métodos apropiados para el desarrollo del software? Para responder a éstas y otras cuestiones, en el presente trabajo, se presenta un diseño de acciones y métodos que constituyen un enfoque práctico para el desempeño de la función de SQA en una organización, adaptado especialmente a la metodología IDEAL para el desarrollo de sistemas basados en el conocimiento. Este enfoque no pretende ser exclusivo y en ningún caso limita o inhibe la aplicación de otras acciones, métodos o modelos, sino que podrá ser su complemento, adaptándolo convenientemente. En la sección II se establecen los Conceptos Básicos, describiendo brevemente los conceptos de calidad, control y aseguramiento de la misma y presentando el alcance de la función de SQA en una organización. En la sección III se esboza el Modelo General, es decir, el diseño de acciones y métodos que constituyen un enfoque práctico para el desempeño de la función de SQA en una organización. También de presenta el modelo de mejora continua del mismo. En la sección IV se describen los Módulos del Modelo, se presentan para cada uno de ellos las acciones a desempeñar, su objetivo, sus entradas, salidas, lista de verificación, métricas y participantes involucrados. En la sección V se describe las principales Técnicas y Herramientas, a utilizar en los módulos del modelo descrito. En la sección VI se describe el Nivel de Servicio Esperado, a través de un acuerdo de nivel de servicio recomendado. En la sección VII se detalla el Equipo de SQA sugerido, indicando su estructura y responsabilidades. En la sección VIII se establecen las Conclusiones del presente Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

18 trabajo, señalando los beneficios y problemas esperados en la aplicación de la función de SQA en una organización. También se establecen las bases para un análisis costo-beneficio. Por último se detalla la Bibliografía utilizada para la confección del presente trabajo, ya sea referenciada o consultada. II. CONCEPTOS BÁSICOS En la presente sección se establecen los Conceptos Básicos, describiendo brevemente los conceptos de calidad, control y aseguramiento de la misma y presentando el alcance de la función de SQA en una organización. A. Paradigma de la calidad El paradigma de la calidad es aplicable a todas las actividades que se llevan a cabo en una organización. Se puede definir en términos generales a la calidad como: La calidad es la suma de todos aquellos aspectos o características de un producto o servicio, que influyen en su capacidad para satisfacer las necesidades de los usuarios. Por otro lado, con respecto a la satisfacción del usuario, se puede decir que: La satisfacción 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: Orientación a los aspectos o características de un producto o servicio que influyan en su capacidad para satisfacer necesidades dadas, más que a la adecuación a estándares o a especificaciones preestablecidas. La perspectiva del proceso: Focalización en el proceso más que en el producto. Orientado a datos: Basado en la recolección, análisis y comparación de datos. Focalización en el cliente o usuario: La obtención de la satisfacción del cliente o usuario es el objetivo final de todo proceso. Eliminación de defectos: Priorización de técnicas de prevención de defectos sobre técnicas de detección y corrección. Gestión para la calidad: La adopción del paradigma requiere del compromiso de la alta dirección. En primer término, 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 sólo desataban acciones correctivas para eliminar los defectos del producto. A estas actividades se las suele catalogar como correctivas, tardías 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 aproximación eficaz a la calidad, contiene una combinación de actividades de aseguramiento de la calidad y de actividades de control de la misma y que estas se complementan fácilmente. B. Calidad del Software Particularmente, en el caso del software, existen muchas definiciones distintas en la bibliografía, sin embargo, en lo que a este trabajo respecta, tomaremos la definición de R. Pressman [1]: La calidad del software se define como la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares y procesos de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente. No hay duda de que la anterior definición puede ser modificada o ampliada. De hecho, no tendría fin una discusión sobre una definición definitiva de la calidad del software. Para los propósitos de este enfoque, la anterior definición 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 estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software o del conocimiento. En caso de no seguirse esos criterios, casi siempre habrá falta de calidad. 3) Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software se debilita. Queda claro a partir de la definición de calidad del software, que ésta es siempre relativa a los requisitos o necesidades que se desea satisfacer. Por eso la evaluación de la calidad del software siempre va a implicar la comparación entre los requisitos y el producto generado. B.1. Puntos de vista de la calidad del software En la ingeniería del software o del conocimiento, la visión 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 ingeniero Fig. 1. Puntos de vista de la calidad del software Punto de vista del gerente de proyecto Dependiendo del punto de vista, se priorizarán 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 operación. 168 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

19 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 gestión 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 presentarán sólo a modo descriptivo, algunos factores de calidad que se han propuesto. McCall y sus colegas [2] han propuesto los siguientes: Corrección. El grado en que un programa satisface sus especificaciones y consigue los objetivos de la misión 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 precisión requerida (Hay que decir que se han propuesto otras definiciones de fiabilidad más completas). Responde a la pregunta: Lo hace en forma fiable todo el tiempo? Eficiencia. La cantidad de recursos de computadora y de código 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á diseñado para ser usado? Facilidad de mantenimiento. El esfuerzo requerido para localizar y arreglar un error en un programa (Se trata de una definición 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 función 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-operación. El esfuerzo requerido para acoplar un sistema a otro. Responde a la pregunta: Podré hacerlo interactuar con otros sistemas? Es difícil, y en algunos casos imposible, desarrollar medidas directas de los anteriores factores de calidad. Por tanto, cada factor se descompone en atributos o criterios, más fácilmente medibles. Cabe aclarar que cada uno de estos atributos puede corresponder a más de un factor de calidad. Facilidad de auditoría. La facilidad con que se puede comprobar la conformidad con los estándares. Exactitud. La precisión de los cálculos y del control. Normalización de las comunicaciones. El grado en que se usan el ancho de banda, los protocolos y las interfaces estándar. Completitud. El grado en que se ha conseguido la total implementación de las funciones requeridas. Concisión. Lo compacto que es el programa en términos de líneas de código. Consistencia. El uso de un diseño uniforme y de técnicas de documentación a lo largo del proyecto de desarrollo del software. Estandarización en los datos. El uso de estructuras de datos y de tipos estándar a lo largo de todo el programa. Tolerancia de errores. El daño que se produce cuando el programa encuentra un error. Eficiencia en la ejecución. El rendimiento en tiempo de ejecución de un programa. Facilidad de expansión. El grado en que se puede ampliar el diseño arquitectónico, de datos o procedimental. Generalidad. La amplitud de aplicación potencial de los componentes del programa. Independencia del hardware. El grado en que el software es independiente del hardware sobre el que opera. Instrumentación. 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 operación. La facilidad de operación de un programa. Seguridad. La disponibilidad de mecanismos que controlen o protejan los programas o los datos. Autodocumentación. El grado en que el código fuente proporciona documentación 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 características no estándar del lenguaje de programación, de las características del sistema operativo y de otras restricciones del entorno. Facilidad de traza. La posibilidad de seguir la pista a la representación del diseño o de los componentes reales del programa hacia atrás, hacia los requisitos. Formación. 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 evaluación del conjunto de características y de posibilidades del programa, la generalidad de las funciones que se entregan y la seguridad de todo el sistema. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

20 La facilidad de uso se calcula considerando los factores humanos, la estética global, la consistencia y la documentación. 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 evaluación 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 término más común facilidad de mantenimiento), además de la facilidad de prueba, la compatibilidad, la posibilidad de configuración (posibilidad de organizar y controlar elementos de la configuración & 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 además fórmulas, matrices, pesos ponderados que permiten cuantificar cada uno de los factores presentados. Más allá de eso, los siguientes puntos deben quedar claros. 1) Los modelos aquí presentados son sólo una muestra de los disponibles, hay varios más 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 selección, se debe tener en cuenta lo siguiente: Las características particulares de la aplicación a desarrollar o de su entorno. Así por ejemplo si la aplicación se desarrolla para un entorno en el que el hardware evoluciona rápidamente, 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 análisis costobeneficio. 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 sólo pueden ser medidos indirectamente. En cualquiera de los dos casos la cuantificación es obligatoria. Respondiendo a otro de los principio del paradigma de la calidad (orientación a datos), las comparaciones se deben basar sobre datos y mediciones concretas y objetivas, no sobre opiniones o subjetividades. C. Alcance de la función de SQA La calidad del software no es algo en lo que se empieza a pensar una vez que se ha generado el código. Según R Pressman [1] el aseguramiento de la calidad del software (SQA) es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería software y engloba: 1) Un enfoque de gestión de la calidad. 2) Tecnología de ingeniería del software o del conocimiento efectiva (métodos y herramientas). 3) Revisiones técnicas formales que se aplican durante cada paso de la ingeniería del software o del conocimiento. 4) Una estrategia de prueba en múltiples niveles. 5) El control de la documentación del software y de los cambios realizados. 6) Un procedimiento que asegure un ajuste a los estándares de desarrollo del software (cuando sea posible). 7) Mecanismos de medición y de información. Las anteriores involucran tanto a los ingenieros de software como al equipo de SQA. Los ingenieros de software deben aplicar métodos técnicos y mediciones sólidas, conducir revisiones técnicas 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 propósito proveer a la gerencia la visibilidad apropiada del proceso que está siendo usado y de los productos siendo desarrollados. El propósito involucra: Revisar y auditar los productos de software y actividades para asegurar que obedecen a los procedimientos y estándares aplicables. Proveer al gerente del proyecto de software y a otras gerencias, según 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 resolución. 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 planificación del proyecto y es revisado por todas las partes interesadas. Las actividades de aseguramiento de la calidad a desempeñar por el equipo de ingenieros de software y el equipo de SQA son regidas por este plan. El plan identifica: Evaluaciones a realizar. Auditorías y revisiones a realizar. Estándares aplicables al proyecto. Procedimientos para reporte y seguimiento de errores. Documentos a ser producidos por el equipo de SQA. Retro-alimentación a proveer al equipo del proyecto de software. Participar en el desarrollo de la descripción del proceso de software del proyecto: El equipo de software selecciona un proceso de software para el proyecto, el equipo de SQA revisa la descripción del proceso, verificando que cumpla con las políticas de la organización, estándares de software internos y estándares impuestos externamente, entre otros. Revisar las actividades de ingeniería 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 desviación 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 periódicamente informa los resultados de su trabajo al gerente del proyecto. 170 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

21 Asegurar que las desviaciones detectadas sean documentadas y manejadas de acuerdo a procedimientos documentados: Las desviaciones pueden encontrase en el plan de proyecto, descripciones del proceso, estándares aplicables o productos de trabajo técnico. Registrar cualquier incumplimiento y reportarlo a la alta gerencia: A los incumplimientos se les debe hacer seguimiento hasta que sean resueltos. El equipo de SQA participa también en la tarea de recolectar y analizar métricas de software como así también en establecer y revisar procedimientos, planes y estándares. III. MODELO GENERAL En la presente sección se esboza el Modelo General, es decir, el diseño de acciones y métodos que constituyen un enfoque práctico para el desempeño de la función de SQA en una organización. También se presenta el modelo de mejora continua del mismo. A. Modelo de aseguramiento de calidad sugerido Una metodología de desarrollo de software (ya sea para software convencional o para sistemas basados en el conocimiento) establece una forma consistente de ejecutar las actividades relacionadas con el software dentro de una organización. Toda metodología describe: Elementos: Cubren un conjunto de actividades bien definidas, relacionadas y agrupadas. Arquitectura: Establece el orden, las interfaces, las interdependencias y otras relaciones entre los elementos. Adicionalmente, la metodología podría describir estándares, métodos y herramientas. La metodología de desarrollo es la que provee continuidad en el proceso de software de una organización y es una referencia para métricas y mejoras de dicho proceso. Sobre la base del concepto de metodología y de los conceptos básicos ya definidos en el capítulo anterior, se propone un enfoque o modelo de aseguramiento de la calidad del software que tiene las siguientes características: El modelo de aseguramiento de calidad de software sugerido es una interfaz a una metodología de desarrollo de software. En particular, para el presente trabajo, se utilizará la metodología IDEAL. El modelo que aquí se presenta no es una metodología en sí misma, sino que debe acoplarse a una metodología de desarrollo para poder implementarse. Esta interfaz está compuesta por módulos independientes, donde cada uno de ellos se asocia a ciertos procesos de la metodología IDEAL. La interfaz cuenta también con un módulo de ejecución recurrente, en donde, para todas y cada uno de las entradas a cada uno de los otros módulos, se verifica la conformidad de las mismas con la metodología, estándares y normas aplicables que estén vigentes en la organización. El modelo de aseguramiento de la calidad del software sugerido no es dependiente de la metodología de desarrollo utilizada en una organización, sino que se adapta a ella. Sobre la base de los procesos de la metodología de desarrollo, sus precedencias, sus ciclos de ejecución, y por supuesto de las características 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 ejecución de las mismas. En la figura 2 se muestra la relación entre el modelo general de aseguramiento de la calidad del software y la metodología IDEAL. Metodología de Desarrollo del Software de la Organización Identificación de la tarea Desarrollo de los prototipos Ejecución de la construcción del sistema integrado Actuación para conseguir el mantenimiento perfectivo Lograr una adecuada transferencia tecnológica Interfaz de Aseguramiento de la Calidad del Software Planificación Requerimientos Análisis Diseño Codificación Verificación del Sistema Validación del Sistema Instalación Metodología, Estándares y Normas de la Organización Fig. 2. Relación entre el modelo general y la metodología de desarrollo B. Aplicación del Modelo El modelo aquí presentado, es un modelo genérico cuya flexibilidad permite su adaptación a cada proyecto en particular. De esta forma, se podrán seleccionar los segmentos del mismo que cubran las necesidades de cada proyecto, evitando la realización 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 adaptación del modelo genérico o plan general de aseguramiento de la calidad del software, a todo tipo de proyectos, se formaliza a través de los planes específicos de aseguramiento de la calidad del software para cada proyecto. El plan específico de aseguramiento de la calidad, para un proyecto en particular, será entonces, la adaptación del plan general a las características particulares de ese proyecto. En la figura 3 se muestra la relación entre el plan general de aseguramiento de la calidad del software y cada uno de los planes específicos. C. Módulos del modelo En el capítulo siguiente se describirá cada uno de los módulos del modelo general de aseguramiento de la calidad propuesto, indicando para cada uno de ellos los siguientes: Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

22 Objetivo: Descripción del propósito del módulo, 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 aplicación del mismo. En la figura 4 se muestra el modelo de actualización y mejora continua del plan general de aseguramiento de la calidad del software y de los planes específicos de aseguramiento de la calidad del software de cada proyecto, así como la adaptación del plan general, y la ejecución y verificación de los planes específicos. Plan General de Aseguramiento de la Calidad del Software Fig. 3. Relación entre el plan general y los planes específicos Entrada: Documentos y/o información necesaria para completar el módulo. El nombre de los documentos es genérico, sin embargo este nombre debe ser adaptado al nombre del producto resultante, del proceso lógico correspondiente, en la metodología utilizada. Proceso: Descripción de las tareas y acciones que debe ejecutar el integrante del equipo de SQA para dar por cumplido el módulo. Salida: Productos que deben ser generados al final del módulo. Lista de verificación: Checklist que utilizan los integrantes del equipo de SQA para verificar que ha cumplido el módulo correctamente. Las lista de verificación se definen en tablas, los campos de esas tablas se explican en la tabla I. Paso 4 Actualización del Plan General Plan Específico de Aseguramiento de la Calidad del Software Paso 1 Adaptación del Plan General a cada Proyecto particular TABLA I. EXPLICACIÓN DE LOS CAMPOS QUE FORMAN PARTE DE LAS TABLAS QUE DEFINEN LAS LISTAS DE VERIFICACIÓN Paso 3 Actualización del Plan Específico Paso 2 Ejecución del Plan Específico CAMPOS Número Ítem Respuesta Comentarios EXPLICACIÓN D. Actualización del plan Un número que identifica secuencialmente los ítems de control de calidad, el resultado positivo indicaría que ese paso ha sido realizado correctamente. Ítem específico de control de calidad que es usado para medir la efectividad de ejecución de este paso. El analista de calidad deberá indicar en esta columna si ha realizado el ítem referenciado. La respuesta puede ser: SI, NO o N/A si la misma no es aplicable al proyecto en cuestión. Esta columna es utilizada para clarificar la respuesta de SI, NO o N/A para los ítems indicados. Generalmente la columna de comentarios sólo se completa en las respuestas por NO; las respuestas por NO deberán ser investigadas y se deberá tomar una determinación respecto a si este ítem deberá ser completado antes de considerar este paso completo. D.1. Modelo de mejora continua del plan El modelo o plan general de aseguramiento de la calidad del software aquí presentado no mantiene un estado estacionario o estático, sino que es dinámico y sujeto a Productos resultantes de la Ejecución Fig. 4. Modelo de actualización y mejora continua D.2. Detalle del modelo de mejora continua del plan A continuación se detalla el modelo de mejora continua del plan general de aseguramiento de la calidad como así también de los planes específicos correspondientes a cada proyecto particular. Adicionalmente, y sólo para contextualizar los pasos correspondientes a la mejora continua, se detallan brevemente los pasos correspondientes a la adaptación del plan general, y la ejecución y verificación de los planes específicos: Paso 1: Entrada: Plan general de aseguramiento de la calidad de software. Acción: Adaptación del plan general de aseguramiento de la calidad de software a cada proyecto particular. Salida: Plan específico de aseguramiento de la calidad de software para un proyecto particular Paso 2: 172 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

23 Entrada: Plan específico de aseguramiento de la calidad de software, para un proyecto particular. Acción: Ejecución del plan específico de aseguramiento de la calidad de software. Salida: Productos resultantes de la ejecución del plan específico de aseguramiento de la calidad de software. Paso 3: Entrada: Productos resultantes de la ejecución del plan específico de aseguramiento de la calidad de software. Acción: Análisis de la calidad de los productos resultantes de la ejecución del plan específico. Generación de recomendaciones y acciones a realizar, con su correspondiente justificación, para mejorar el plan específico de aseguramiento de la calidad de software. Salida: Plan específico de aseguramiento de la calidad de software, para un proyecto particular, actualizado. Paso 4: Entrada: Actualizaciones realizadas al plan específico de aseguramiento de la calidad de software, para un proyecto particular. Acción: Análisis de las actualizaciones realizadas al plan específico de aseguramiento de la calidad del software, con sus correspondientes justificaciones. Actualización del plan general de aseguramiento de la calidad del software. Salida: Plan general de aseguramiento de la calidad del software actualizado. IV. MÓDULOS DEL MODELO En el presente capítulo se describen los Módulos del Modelo, se presentan para cada uno de ellos las acciones a desempeñar, su objetivo, sus entradas, salidas, lista de verificación, métricas y participantes involucrados. A. Planificación A.1. Objetivo Determinar qué recursos estarán disponibles para producir y mantener el software asociado al proyecto. Determinar cuándo y cómo 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. Estimación del proyecto y método utilizado para realizarla. Descripción del proceso de desarrollo a utilizar en el proyecto. A.3. Proceso En la figura 5 se detalla gráficamente, el proceso a desarrollar durante este módulo: A.3.1.Verificación de la Estimación del Proyecto Muchos proyectos de software son esencialmente innovadores, pero una ineficaz estimación del sistema, puede llevar a un exceso de costos. Estimar costos de software es un proceso complicado porque el desarrollo del proyecto es influenciado por un largo número de variables, muchas de ellas son subjetivas, no cuantificables e interrelacionadas en forma compleja. Fig. 5. Proceso del módulo de planificación Una estimación inapropiada de costos puede dañar más a la calidad del proyecto de software que a cualquier otro factor. Si la estimación es incorrecta, el equipo de proyecto hará lo imposible para coincidir con la estimación. Todo esto provoca un aumento de costos de mantenimiento, insatisfacción del cliente, esfuerzo adicional en el área del cliente para compensar la debilidad del sistema, y desanimar al personal del proyecto. La verificación puede aumentar la validez de la estimación. La estimación del software es un proceso de tres partes como se describe a continuación: Validar la sensatez del modelo de estimación. 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 capítulo de Técnicas y Herramientas. A.3.2. Verificación del Estado del Proyecto Para conocer el estado del proyecto se sugiere un sistema simple de acumulación 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 medición 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 medición durante el desarrollo del software, provee un método objetivo, preciso y eficiente de recolección y reporte del rendimiento de la información en el campo de la ingeniería que a menudo carece de visibilidad. El método utiliza información basada en ítems de entregables de software y es obtenida como parte del proceso de desarrollo. Los resultados son fáciles 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 capítulo de Técnicas y Herramientas. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

24 A.4. Salidas Informe de estimación del proyecto Informe de estado del proyecto A.5. Lista de Verificación (Checklist) En la tabla I se presenta la lista de verificación: TABLA II. LISTA DE VERIFICACIÓN DEL MÓDULO DE PLANIFICACIÓN # Ítem La gerencia del proyecto, esta de acuerdo en tener un equipo 1 de aseguramiento de la calidad y evaluación de la estimación y estado del plan de desarrollo? 2 El equipo de aseguramiento de la calidad conoce la estimación del progreso utilizada para el proyecto? 3 El equipo de aseguramiento de la calidad conoce el método para realizar los informes de estado del proyecto? 4 El equipo de aseguramiento de la calidad entiende el método utilizado para estimar y calcular? El equipo de aseguramiento de la calidad ha realizado una 5 buena verificación para determinar la validez de las estimaciones realizadas? Si el equipo de aseguramiento de la calidad está en 6 desacuerdo con la validez de las estimaciones realizadas. Existe un procedimiento razonable para manejar tales diferencias? 7 El equipo del proyecto posee un sistema de reportes razonable para informar el estado del mismo? El equipo de aseguramiento de la calidad ha establecido que 8 pueden utilizarse los informes de estado de proyecto como guía para la toma de decisiones? Existe algún procedimiento a seguir, si los informes de estado 9 indican que el proyecto está por encima o por debajo de las estimaciones? El equipo de aseguramiento de la calidad ha tenido en cuenta 10 los factores más importantes en la evaluación de la estimación realizada (Ejemplo: tamaño del software, etc.)? 11 El equipo de proyecto ha recibido una copia del estado del mismo? 12 El equipo de aseguramiento de la calidad tiene conocimiento de cómo se efectúa la planificación? 13 El equipo de aseguramiento de la calidad tiene conocimiento de cómo se efectúa la estimación del proyecto? El equipo del proyecto tiene conocimiento del proceso de 14 desarrollo utilizado para construir el software especificado por el proyecto? 15 El plan de proyecto está completo? 16 La estimación del proyecto está totalmente documentada? 17 El proceso de desarrollo está totalmente documentado? 18 El método de estimación utilizado para el proyecto, es razonable respecto de las características del mismo? 19 La estimación efectuada es razonable como para completar el proyecto según lo especificado en el plan? 20 El equipo del proyecto tiene un método definido para determinar e informar el estado del mismo El equipo de aseguramiento de la calidad, está de acuerdo 21 con que el estado informado coincide con el estado actual del proyecto? A.6. Métricas Eficacia de la estimación de la duración: Eficacia de la estimación del esfuerzo A.7. Involucrados A.7.1. Equipo de Ingeniería Gerente de proyecto. SI Respuesta NO N/A Comentarios Duración actual del proyecto Duración estimada del proyecto Esfuerzo actual del proyecto Esfuerzo estimado del proyecto A.7.2. Equipo de Aseguramiento de la Calidad del Software Líder de aseguramiento de la calidad del software. B. Requerimientos B.1. Objetivo Determinar si los requerimientos expresan las necesidades del usuario. Verificar la separación de los requerimientos entre obligatorios y opcionales. Verificar que cada requerimiento: Esté debidamente documentado, reflejando las necesidades del usuario. Se encuentre dentro del alcance definido del sistema en cuestión. Se encuentre dentro de los límites del presupuesto para el sistema en cuestión. Se encuentre bien definido (en forma completa), de manera de evitar cambios posteriores. Determinar que los requerimientos documentados puedan ser implementables (pasibles de ser analizados, diseñados, codificados) y verificables (pasibles de ser verificados y validados) en fases posteriores. B.2. Entradas Minutas de reunión con el usuario. Documento de especificación de requerimientos del usuario. B.3. Proceso En la figura 6 se detalla gráficamente, el proceso a desarrollar durante este módulo. Minutas de Reunión con el Usuario Definición de los requerimientos del Proyecto HACER 1 Paso Preparar la Matriz de Riesgo 2 Paso Realizar un Análisis de Factores a Verificar 3 Paso Conducir un "Walkthrough" REHACER VERIFICAR Requerimiento preciso y completo Fig. 6. Proceso del módulo de requerimientos Reportes de la Verificación B.3.1. Preparar la Matriz de Riesgo La Matriz de Riesgo es una herramienta diseñada para evaluar el control en los sistemas de información. Uno de los mayores beneficios de la matriz de riesgo es, no sólo la identificación de los mismos, sino también qué es lo que el sistema debe hacer para ó con cada uno de ellos. En principio, la matriz de riesgo es una herramienta de diseño, pero puede ser usada como herramienta de verificación. En forma ideal la matriz de riesgo comienza en la fase de requerimientos, se desarrolla en la fase de análisis y se termina NO SI 174 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

25 en la fase de diseño. La ejecución de la matriz de riesgo es un proceso de cinco pasos, los cuales se encuentran detallados en el capítulo de Técnicas y Herramientas. B.3.2. Realizar un Análisis 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 verificación para cada factor a considerar (son 15), cubriendo cada fase del proceso de desarrollo. Para cada factor hay un programa de verificación que tiene en cuenta ciertas consideraciones las cuales se encuentran detalladas en el capítulo de Técnicas y Herramientas. El programa de verificación enumera aquellos criterios, que aseguran al equipo de aseguramiento de la calidad, que la magnitud de esa preocupación es mínima. A estos criterios debe responder el equipo de aseguramiento de la calidad. También se debe realizar una verificación suficiente para evaluar si el equipo de proyecto ha manejado adecuadamente cada criterio de verificación. Los factores a verificar en la etapa de requerimientos son: Requerimientos compatibles con la metodología (Factor de prueba: Metodología) Funcionalidad de las especificaciones definidas (Factor de prueba: Precisión) Usabilidad de las especificaciones (Factor de prueba: Facilidad de uso) Mantenimiento de las especificaciones (Factor de prueba: Mantenibilidad) Necesidades de portabilidad (Factor de prueba: Portabilidad) Interfaces del sistema (Factor de prueba: Acoplamiento) Criterios de performance (Factor de prueba: Performance) Necesidades operativas (Factor de prueba: Facilidad de operación) Tolerancia (Factor de prueba: Fiabilidad) Reglas de autorización (Factor de prueba: Autorización) Requerimientos de integridad de archivos (Factor de prueba: Integridad de archivos) Recuperación ante fallas en los requerimientos (Factor de prueba: Auditoría) Impacto de fallas (Factor de prueba: Continuidad de procesamiento) Nivel de servicio deseado (Factor de prueba: Nivel de Servicio) Permisos y accesos (Factor de prueba: Seguridad) B.3.3. Conducir un Walkthrough de Requerimientos De los procesos de revisión, la inspección o recorrido (walkthrough) de requerimientos es el menos estructurado y el más propenso a la creatividad. Por lo tanto éste se convierte en un proceso de revisión que complementa los objetivos de la fase de requerimientos. El objeto de este proceso de revisión es crear una situación en la cual un grupo de gente con las habilidades adecuadas pueda ayudar al equipo en el desarrollo de las soluciones del proyecto. El walkthrough intenta usar la experiencia y juicio del equipo de revisión como un soporte en el proceso de desarrollo. Este método se implementa como un proceso de cinco pasos ejecutados en secuencia, los cuales se encuentran detallados en el capítulo de Técnicas y Herramientas, que son: Establecer reglas básicas Seleccionar el equipo / Notificar a los participantes Presentación del proyecto Preguntas / recomendaciones Reporte final El tiempo destinado a cada paso dependerá del tamaño de la aplicación que se esté revisando y el grado de asistencia deseado del equipo de walkthrough. B.4. Salidas Matriz de riesgo Análisis de factores de verificación. Informe de la inspección ( walkthrough ) confeccionado. Resumen de la inspección ( walkthrough ) confeccionado. B.5. Lista de Verificación (Checklist) En la tabla III se presenta la lista de verificación. TABLA III. LISTA DE VERIFICACIÓN DEL MÓDULO DE REQUERIMIENTOS # Ítem 1 Los requerimientos definidos son verificables? 2 El usuario está de acuerdo con el requerimiento definido? 3 Los desarrolladores entienden los requerimientos? 4 El requerimiento definido coincide con los objetivos del proyecto? 5 Se identificaron los riesgos del proyecto? 6 Se siguió un proceso razonable en la definición del requerimiento? El proceso de control de requerimientos, es 7 adecuado para minimizar los riesgos del proyecto? Durante el proceso de control de 8 requerimientos, se ha llevado a cabo un walktrough? B.6. Métricas Estabilidad de los requerimientos: Completitud de los requerimientos: Tasa de efectividad de la verificación: B.7. Involucrados B.7.1. Equipo de Ingeniería Gerente de proyecto. Grupo de análisis de requerimientos. Respuesta SI NO N/A Comentarios Cantidad de requerimientos iniciales Cantidad total de requerimientos Cantidad de nuevos requerimientos agregados Cantidad total de requerimientos Cantidad de ítems cubiertos Cantidad total de ítems B.7.2. Equipo de Aseguramiento de la Calidad del Software Líder de aseguramiento de la calidad del software. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

26 Analistas de aseguramiento de la calidad del software Senior y/o Semi-senior. C. Análisis C.1. Objetivo Describir la funcionalidad del producto que va a ser entregado. Definir el ambiente en el que va a operar. Definir la confiabilidad y el compromiso de mantenimiento. Identificar las necesidades de soporte u operación, como hardware, software, etc. Definir para cada requerimiento, qué prueba se va a ejecutar para asegurar que se cumpla con el mismo. C.2. Entradas Documento de especificación de requerimientos revisado Documento de especificación funcional. C.3. Proceso En la figura C se detalla gráficamente, el proceso a desarrollar durante este módulo. Fig. 7. Proceso del módulo de análisis C.3.1. Analizar la Especificación Funcional La especificación funcional, debe ser vista como un proceso de representación, a fin de poder llegar a una exitosa implementación de software. Algunos principios para especificar, podrían ser: Separar requerimientos funcionales de implementación. Desarrollar un modelo del comportamiento deseado del sistema, que comprenda datos y la respuesta funcional del sistema a los estímulos del ambiente. Establecer un contexto en el cual el software opera especificando la forma en la cual otros componentes del sistema interactúan con el software. Desarrollar un ambiente en el cual el sistema opere y reaccione a los estímulos del mismo. Crear un modelo cognitivo en lugar de un diseño o un modelo de implementación. El modelo cognitivo describe el sistema como es percibido por los usuarios de esa comunidad. Reconocer que una especificación tendrá varios niveles de detalle. Se verificará que la especificación funcional cumpla, con al menos, los siguientes lineamientos: El formato de la representación y contenido debería ser relevante para el problema. Debe llevarse a cabo, un desarrollo general para los contenidos de las especificaciones. La información contenida en la especificación debe ir de lo general a lo particular (estar anidada). Las representaciones deberían revelar capas de información a fin de permitir al lector que pueda moverse al nivel de detalle que sea requerido. Se deben indicar esquemas de numeración dentro de los diagramas utilizados, indicando el nivel de detalle que se presenta. Es importante presentar la misma información a diferentes niveles de abstracción para ayudar a su entendimiento. Los formatos diferentes de diagramas a utilizar y otras formas de notación, deberán ser restringidas al mínimo en número y consistentes en su uso. La información confusa e inconsistente, sea tanto simbólica o gráfica, perjudica el entendimiento y propicia errores. La especificación funcional, debe ser verificable. Se verificará que la especificación funcional cumpla, con al menos, el siguiente contenido: I. Introducción a. Resumen del Sistema b. Descripción del producto c. Entregables II. Ambiente a. Usuarios b. Servicios c. Físico d. Seguridad III. Descripción de la información a. Representación del contenido de la información b. Representación del flujo de la información i. Flujo de datos ii. Flujo de control IV. Descripción funcional a. Partición funcional b. Descripción funcional i. Narrativa de proceso general ii. Restricciones / Limitaciones iii. Requerimientos de rendimiento iv. Restricciones de diseño v. Diagramas de soporte c. Descripción de control i. Especificación de control ii. Restricciones de para el diseño V. Descripción de situación a. Estado del sistema b. Eventos y acciones VI. Validación y criterios a. Límites y restricciones b. Clases de pruebas requeridas c. Respuesta esperada del software d. Consideraciones especiales VII. Cronograma VIII. Apéndices 176 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

27 C.3.2. Conducir una Inspección Formal La revisión de una especificación funcional es conducida por el desarrollador y el cliente. Dado que las especificaciones forman el punto fundamental y a partir del cual se realizará el diseño y subsecuentemente las actividades de la ingeniería del software o de conocimiento, se deberán extremar los cuidados para conducir esta revisión. La revisión en una primera instancia es conducida en un nivel macro. En este nivel, los inspectores intentan garantizar que la especificación esté completa, consistente y exacta. Se tendrán en cuenta los siguientes lineamientos para una revisión detallada: Detectar y remplazar términos vagos. En el caso de listas de elementos, asegurar que hayan sido incluidos todos. Cuando se especifiquen rangos (numéricos, etc.) asegurarse que no contengan valores asumidos sin ser definidos expresamente Estar alerta de verbos y pronombres ambiguos. Identificar afirmaciones que no incluyan certeza. Cuando una estructura es descripta en palabras, asegurar que se realice un diagrama para ayudar a comprenderla. Cuando sea necesario realizar un cálculo especificado, asegurar que se presente al menos dos ejemplos del mismo. Con respecto a los cambios en los requerimientos, una vez que los mismos han sido finalizados, el usuario deberá notar que cada uno de ellos es una ampliación del alcance del software y por ende, un cambio en la especificación funcional. Esto incrementará el costo del proyecto y/ o extenderá el tiempo establecido para su finalización. Aún cuando se realicen las mejores revisiones, cierto número de problemas en la especificación persiste. La especificación es difícil de verificar, por ende las inconsistencias u omisiones pueden pasar desapercibidas. Durante la revisión, pueden ser recomendados más cambios en la especificación funcional. Puede ser extremadamente difícil estimar el impacto global del cambio, esto es, cómo un cambio en una función afecta a los requerimientos en otra función. Esto último deber ser tenido muy en cuenta a la hora de impactar dicho cambio. C.4. Salidas Informe de la Inspección Resumen de la Inspección C.5. Lista de Verificación (Checklist) En la tabla IV se presenta la lista de verificación. C.6. Métricas Estabilidad de los requerimientos: Estabilidad de la funcionalidad: Cantidad de requerimientos modificados Cantidad total de requerimientos establecidos Cantidad de funciones modificadas Cantidad total de funciones establecidas Correctitud de la funcionalidad: Completitud de la funcionalidad: Eficiencia en la detección de defectos: Eficiencia en la remoción de defectos: Tasa de efectividad de la verificación: Cantidad de funciones corregidas Cantidad total de funciones establecidas Cantidad de nuevas funciones agregadas Cantidad total de funciones establecidas Cantidad de defectos detectados hasta análisis Cantidad total de defectos Cantidad de defectos removidos hasta análisis Cantidad total de defectos Cantidad de ítems cubiertos Cantidad total de ítems TABLA IV. LISTA DE VERIFICACIÓN DEL MÓDULO DE ANÁLISIS # Ítem Los objetivos y metas del sistema se mantienen 1 consistentes con las políticas de software de la organización? La estructura y el flujo de la información, está 2 adecuadamente definida por el área a la cual compete el problema? Son claros los diagramas? Pueden ser 3 explícitos sin necesidad de ser descriptos o narrados? Las funciones principales del sistema, están 4 dentro del alcance? Cada una de ellas ha sido adecuadamente definida? Es consistente el comportamiento del sistema 5 con la información que debe procesar y las funciones que debe desarrollar? 6 Las limitaciones del sistema son realistas? 7 Ha sido considerado el riesgo tecnológico del desarrollo? 8 Se han considerado requerimientos alternativos de software? Ha sido detallado el criterio de verificación y 9 validación? Los mismos, son adecuados para determinar el éxito del sistema? Existen inconsistencias, omisiones o 10 redundancias en el modelo de información del sistema? 11 El usuario final ha estado involucrado? 12 El usuario revisó el prototipo y/o manual del usuario? 13 Han sido debidamente planificadas las estimaciones de esfuerzo? C.7. Involucrados C.7.1.Equipo de Ingeniería Gerente de proyecto. Grupo de análisis de requerimientos. Grupo de análisis funcional. Respuesta SI NO N/A Comentarios C.7.2. Equipo de Aseguramiento de la Calidad del Software Líder de aseguramiento de la calidad del software. Analistas de aseguramiento de la calidad del software Senior y/o Semi-senior. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

28 D. Diseño D.1. Objetivo Establecer los factores que conducen a un diseño correcto y preciso Conducir revisiones de diseño. Conducir inspecciones de los entregables del diseño D.2. Entradas Comprensión del diseño por parte del equipo de aseguramiento de la calidad Entregables derivados del diseño: 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. Especificación de los procedimientos de operación manual. Política de resguardo de la información. Documento de diseño de alto nivel (Lógico) Documento de diseño de detalle (Físico y lógico) D.3. Proceso En la figura 8 se detalla gráficamente, el proceso a desarrollar durante este módulo: Fig. 8. Proceso del módulo de diseño 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 correlación 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, también 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 correlación histórica 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 elección antes que los votos sean contados. Estos tipos de predicciones en sistemas de computación son bien conocidos, pero no han sido bien utilizados hasta que el concepto de ranking fue desarrollado. Por ejemplo, sabemos que hay una correlación positiva entre la participación del usuario y el sistema de computación: cuanto más involucrado este el usuario, mayor probabilidad de que el sistema sea exitoso. También sabemos que habrá problemas con el sistema de computación que empuja las actuales corrientes de tecnología. Por ejemplo, el primer sistema en usar la nueva tecnología puede ser identificada como un sistema de alto riesgo, porque la mayoría de los inconvenientes ocurrirá durante la implementación. Los criterios que se utilizan bajo el concepto de ranking, se describen en el capítulo de Técnicas y Herramientas Al concluir el ranking, el resultado puede ser usado en cualquiera de las siguientes formas: Estimar la extensión de la verificación: A mayor riesgo, la gerencia del proyecto puede requerir más verificaciones. Sabiendo que la aplicación 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 módulos a verificar: Dependiendo de la sofisticación del instrumento con el que se obtuvo el ranking, puede identificarse módulos específicos para la verificación. Por ejemplo, si la lógica computacional se sabe que es de alto riesgo, la verificación debería evaluar exhaustivamente la exactitud de este proceso. Identificar la composición del equipo de verificación: Los tipos de riesgos asociados con el sistema ayudan a determinar la composición del equipo de test. Por ejemplo, si los riesgos tratan más con la tecnología que con la lógica, el equipo de test debería incluir individuos con conocimientos profundos en esa tecnología. Al ranking de riesgo se llega a través de un desarrollo matemático, como se muestra en el capítulo de Técnicas y Herramientas. D.3.2. Análisis de Factores El encargado de dirigir la verificación podrá seleccionar los factores de interés apropiados, para ajustar la verificación, teniendo en cuenta los siguientes objetivos generales para la fase de diseño: Desarrollar una solución al problema de negocio planteado. Determinar el rol de la tecnología para resolver el problema. Desarrollar especificaciones para los segmentos manuales y automatizados del sistema. Cumplir con el plan de acción, procedimientos, estándares y regulaciones. Definir los controles que reducirán riesgos de la aplicación, llevándolos a un nivel aceptable. 178 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

29 Completar el proyecto dentro de las restricciones del presupuesto, personal y cronograma establecidos. Los factores que deben analizarse durante la fase de diseño se describen a continuación, y puede encontrarse más detalle en el capítulo de Técnicas y Herramientas: Los factores a verificar en la Fase de Diseño son: Controles de integridad de datos. Reglas de autorización. Controles de integridad de archivos. Pistas de auditoria. Plan de contingencia. Método para alcanzar el nivel de servicio requerido. Procedimientos de acceso. Diseño acorde con la metodología establecida. Diseño acorde con los requerimientos establecidos. Facilidad de uso. Mantenibilidad del diseño. Portabilidad del diseño. Interfaces de diseño. Diseño acorde con criterios establecidos. Necesidades de operación. D.3.3. Conducción de la Revisión del Diseño La revisión de diseño será estructurada usando la misma información básica que la utilizada para llevar a cabo el ranking. El objetivo es identificar de antemano aquellos atributos del diseño que se correlacionan con los problemas del sistema. Entonces durante la revisión del diseño, se investigarán dichos atributos para determinar si el equipo de proyecto los ha tratado apropiadamente. La revisión del diseño deberá ser conducida por un grupo de individuos con conocimientos en el proceso de diseño. El grupo tendrá la responsabilidad de revisar la integridad y racionabilidad de la aplicación. No es necesario que el grupo conozca la aplicación específicamente pero sí debe conocer la metodología de la organización. La revisión de diseño normalmente es formal y altamente estructurada. Los miembros del equipo intentan determinar si todas las tareas se han realizado apropiadamente. Al final de la revisión de diseño, el equipo emite un reporte indicando sus hallazgos y recomendaciones acerca del proyecto. El equipo de revisión de diseño comprende los siguientes miembros: Personal del proyecto. Equipo de revisión independiente. La siguiente es la lista con los pasos de una revisión de diseño, la descripción detallada está en el capítulo de Técnicas y Herramientas: Seleccionar el equipo de revisión. Entrenar los miembros del equipo de revisión. Notificar al equipo de proyecto. Asignar tiempos adecuados. Documentar los datos de la revisión. Revisar los datos con el equipo de proyecto. Desarrollar recomendaciones de revisión. Revisar recomendaciones con el equipo de proyecto. Preparar un reporte final. Una o más revisiones pueden llevarse a cabo durante la fase de diseño. La cantidad de revisiones dependerá de la importancia del proyecto y del lapso de tiempo en la fase de diseño. Así podrán llevarse a cabo revisiones del diseño de alto nivel y del diseño detallado. Cada defecto descubierto durante la revisión del diseño de alto nivel debe documentarse. Se confeccionará un reporte de defectos. Los defectos deben documentarse, categorizarse, registrarse, presentarse al equipo de proyecto para corregir, y referenciarlo al documento específico en el cual el defecto fue notado. Un ejemplo del formulario para registrar estos defectos, puede encontrarse en el capítulo de Técnicas y Herramientas. D.3.4. Conducción de la Inspección de los Entregables de Diseño La Inspección es un proceso por el cual los productos completos pero no verificados, son evaluados para saber si los cambios especificados fueron implementados correctamente. Para lograr esto, los inspectores examinan los productos antes del cambio, las especificaciones de cambio, y los productos luego del cambio para determinar los resultados. Buscan tres tipos de defectos: Incorrectos (el cambio no se ha hecho correctamente), faltantes (algo que debería haberse cambiado, no se cambió), y adicionales (algo fue cambiado o agregado sin la intención de hacerlo). D.4. Salidas Informe de la inspección. Resumen de la inspección. D.5. Lista de Verificación (Checklist) En la tabla 4.4 se presenta la lista de verificación. D.6. Métricas Eficiencia en la detección de defectos: Eficiencia en la remoción de defectos: Tasa de efectividad de la verificación: Estabilidad del diseño: D.7. Involucrados D.7.1. Equipo de Ingeniería Gerente de proyecto. Grupo de diseño de alto nivel (o lógico). Grupo de diseño de detalle (o físico). Grupo de administración de base de datos. Grupo de analistas desarrolladores. Cantidad de defectos detectados hasta diseño Cantidad total de defectos hasta diseño Cantidad de defectos removidos hasta diseño Cantidad total de defectos hasta diseño Cantidad de ítems cubiertos Cantidad total de ítems Cantidad de cambios introducidas en el diseño Cantidad total de cambios en el proyecto Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

30 D.7.2. Equipo de Aseguramiento de la Calidad del Software Líder de Aseguramiento de la Calidad del Software Analistas de aseguramiento de la calidad del software Senior y/o Semi-senior. E. Codificación E.1. Objetivo El principal objetivo de esta prueba es asegurar que las especificaciones de diseño hayan sido correctamente implementadas. E.2. Entradas Los entregables que funcionan como entrada al proceso de verificación de codificación son los siguientes: # Ítem Han preparado los inspectores una lista de defectos? Se ha programado la inspección convenientemente para todos los inspectores? Han concurrido todos los inspectores a la reunión de inspección? Estuvieron de acuerdo todos los inspectores con la lista de defectos? Fueron identificados los defectos durante la reunión de revisión registrados y entregados al autor? El autor estuvo de acuerdo acerca de realizar las correcciones necesarias? Se ha desarrollado un proceso razonable para determinar si esos defectos han sido corregidos satisfactoriamente? La certificación del moderador ha sido tomada en cuenta para el producto / entregable inspeccionado? Respuesta SI NO N/A Comenta rios TABLA V. LISTA DE VERIFICACIÓN DEL MÓDULO DE DISEÑO # Ítem El equipo de aseguramiento de la calidad tiene buenos conocimientos acerca del proceso de diseño? Si se han utilizado herramientas automatizadas en la creación del diseño, las conocen los miembros del equipo de aseguramiento de la calidad? Han recibido los miembros del equipo de aseguramiento de la calidad todos los entregables de la fase necesarios para llevar a cabo las verificaciones correspondientes? Los usuarios están de acuerdo con que el diseño representa la realidad? El equipo de proyecto cree que el diseño representa la realidad? Han identificado los miembros del equipo de aseguramiento de la calidad los factores de éxito, tanto positivos como negativos, que pudieran afectar el éxito del diseño? Han utilizado los miembros del equipo de aseguramiento de la calidad, tales factores en la puntuación de las probabilidades de éxito? Entienden los miembros del equipo de aseguramiento de la calidad los factores relacionados con el diseño? Han analizado los miembros del equipo de aseguramiento de la calidad los factores de test del diseño para evaluar el potencial impacto sobre el éxito del mismo? Ha sido instruido el equipo de Revisión acerca de lo que representa el éxito del Diseño? La Gerencia apoya el uso del proceso de revisión del diseño? El proceso de revisión del diseño fue conducido en un momento apropiado? Son razonables los ítems identificados en el proceso de revisión del diseño? Están de acuerdo los miembros del equipo de aseguramiento de la calidad que los ítems identificados necesitan ser verificados? La Gerencia apoya la ejecución de inspecciones en el proyecto? Se ha provisto del tiempo suficiente en el cronograma del proyecto para realizar inspecciones? Han sido instruidos los responsables del proyecto acerca de la importancia de la participación en las inspecciones? La Gerencia ve las inspecciones como una parte integral del proceso, en lugar de tomarlo como una auditoría al desempeño de los participantes? Han sido planificados los procesos de Inspección? Han sido identificados los inspectores y asignado sus roles específicos? Han sido entrenados los inspectores para cumplir con su rol? Se les ha dado a los inspectores los materiales necesarios para cumplir con la inspección? Se les ha dado a los inspectores tiempo adecuado para realizar las tareas habituales que le permitirán cumplir con la preparación y la reunión para el proceso de inspección? Se han preparado adecuadamente los inspectores para la inspección? Respuesta SI NO N/A Comenta rios Especificaciones de programas. Documentación de programas. Listado de código. Programas ejecutables. Diagramas de flujo de los programas. Instrucciones para el operador. E.3. Proceso En la figura 9 se detalla gráficamente, el proceso a desarrollar durante este módulo: Fig. 9. Proceso del módulo de codificación E.3.1. Depuración de Programas Se utilizan tres metodologías para la detección y eliminación de los errores en la codificación: Depuración de errores sintácticos. Depuración de errores estructurales. Depuración de errores funcionales. El detalle de cada una de ellas está en el capítulo de Técnicas y Herramientas. 180 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

31 E.3.2. Análisis de Factores de Codificación A continuación, se detallan los factores a analizar. El detalle de cada uno de ellos está en el capítulo de Técnicas y Herramientas: Implementación del control de integridad de información. Implementación de reglas de autorización. Implementación de control de integridad de archivos. Implementación de auditorías de rastreo. Plan de contingencia escrito. Consecución del nivel de servicio deseado para el sistema. Implementación de procedimientos de seguridad. Cumplimiento del programa con la metodología a adoptar. Programa acorde al diseño (Correctitud). Programa acorde al diseño (Facilidad de uso). Mantenimiento del programa. Programa acorde al diseño (Portabilidad). Programa acorde al diseño (Acoplamiento). Desarrollo de procedimientos operativos. Criterio de ejecución del programa (Performance). E.3.3. Conducción de Revisiones de Pares Se utiliza la revisión por pares, para evaluar la estructura y funcionalidad del programa. La revisión por pares detecta errores sintácticos, más por observación personal que por el resultado directo del Walktrough. E.4. Salidas Dos son las salidas de este proceso La eliminación de todos los errores de codificación utilizando pruebas estáticas. Listado de errores encontrados. E.5. Lista de Verificación (Checklist) En la tabla VI se presenta la lista de verificación: TABLA VI. LISTA DE VERIFICACIÓN DEL MÓDULO DE CODIFICACIÓN # Ítem Es considerada una responsabilidad del programador la 1 verificación y la validación de los programas? El programador entiende la diferencia entre testing estático y 2 dinámico? El programa podría ser sometido a testing estático como 3 medio primario para remover defectos? El programador entiende el proceso que generará el código 4 del programa? 5 El programador entiende y usa la técnica de debugging? El programador entiende los conceptos implicados, y los 6 tendrá presentes en la verificación de la programación? El programador es verificado usando revisión por pares o 7 inspección de código? El programa será sometido a un test completo antes de 8 ingresar a un nivel superior de test? Todos los defectos no cubiertos están registrados en 9 detalle? Todos los defectos no cubiertos fueron corregidos antes de 10 ingresar al siguiente nivel de verificación? Respuesta SI NO N/A Comen tarios Eficiencia en la remoción de defectos: Tasa de efectividad de la verificación: E.7. Involucrados E.7.1. Equipo de Ingeniería Gerente de proyecto. Grupo de programación. Cantidad de defectos removidos Cantidad total de defectos Cantidad de ítems cubiertos Cantidad total de ítems E.7.2 Equipo de Aseguramiento de la Calidad del Software Líder de Aseguramiento de la Calidad del Software Analistas de aseguramiento de la calidad del software Senior y/o Semi-senior. F. Verificación del Sistema F.1. Objetivo El objetivo es determinar si el software funcionará correctamente cuando se ejecute. Para ello: Se verificará que se haya probado la ejecución del software en un ambiente separado (test), siendo aproximadamente el mismo entorno operacional en que será ejecutado luego (producción). Las pruebas serán verificadas, una vez terminada su ejecución y aprobación interna. Cualquier desviación de los resultados esperados será reportada. Dependiendo de la severidad y naturaleza de dichos problemas, podrían llegar a realizarse solicitudes de cambios al sistema antes de su puesta en producción. F.2. Entradas Planes de pruebas: Pruebas en línea ( On-Line ) Pruebas por lotes ( Batch ) Pruebas de interfaces. Pruebas de regresión. Pruebas de integración. Pruebas de stress. Datos de prueba. Resultados de las pruebas. F.3. Proceso En la figura 10 se detalla gráficamente, el proceso a desarrollar durante este módulo: E.6. Métricas Densidad de defectos por componente: Eficiencia en la detección de defectos: Cantidad de defectos Tamaño del componente Cantidad de defectos detectados Cantidad total de defectos Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

32 Fig. 10. Proceso del módulo de verificación F.3.1. Verificar la Construcción de Datos / Scripts de Prueba El concepto de construcción de datos de prueba es, simplemente, la creación de un proceso representativo de la realidad usando transacciones ficticias. De dichos datos, se tomará una muestra representativa para llevar a cabo una verificación de los mismos. La correcta selección de dicha muestra es la clave para el éxito de esta tarea. Dentro de esta tarea debe abarcarse la verificación de los siguientes: Diseño de archivos de prueba Estos archivos deben involucrar transacciones normales, transacciones con datos inválidos, y transacciones que puedan hacer incurrir al sistema en alguna situación de excepción. Ingreso de los datos de prueba Después que las transacciones de prueba estén definidas, se deben introducir en el sistema todos los datos necesarios para que las mismas puedan ser procesadas. Análisis de los resultados esperados Antes de procesar alguna transacción, el equipo de proyecto debe establecer el resultado esperado para cada transacción 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 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 límites se vean excedidos. Estas pruebas suelen involucrar grandes volúmenes 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 máxima expresión tratando de sobrepasar sus límites. Documentar las limitaciones. Realizar la prueba de volumen. Creación de casos de prueba Determinar el nivel de la prueba: Unitaria, concurrencia, integración, regresión 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 Ejecución de la Prueba Para lograr una prueba efectiva, se debe usar un plan de pruebas creado previamente. Esta etapa es la culminación de un trabajo previo preparado para esta fase. Si esto no ocurre, la prueba podría resultar poco efectiva y antieconómica. Durante esta fase, el equipo de aseguramiento de la calidad, llevará a cabo tanto la verificación de los planes de prueba, como la verificación de la ejecución de los mismos. Todo esto se realizará, tomando muestras representativas de los planes y sus respectivas ejecuciones. Se verificará también, que los siguientes tipos de prueba hayan sido llevados a cabo por el equipo de proyecto durante esta fase: Prueba manual, de regresión y funcional La prueba manual asegura que las personas que interactúen con el sistema van a poder realizar las operaciones propuestas; la prueba de regresión es la verificación 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 autorización En esta prueba deben verificarse las reglas de autorizaciones (permisos) para ejecutar las distintas transacciones de la aplicación. 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 función de pistas de auditoria, debe ser probada para asegurarse que para cualquier transacción, pueda realizársele un seguimiento desde su inicio hasta su fin, para lograr una correcta reconstrucción de la misma cuando sea necesario. 182 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

33 Prueba de recuperación 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 volúmenes 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 metodología Todo tipo de prueba, deberá ser llevado a cabo de acuerdo a las políticas, estándares y procedimientos establecidos en la metodología de la organización. Esta última debería especificar el plan de prueba requerido para cada tipo de prueba, las técnicas y herramientas de prueba recomendadas, así como el tipo de documentación requerida a lo largo de la prueba misma. La metodología debería especificar el modo de determinar cuándo una prueba fue exitosa o no. Prueba funcional Esta prueba verifica el correcto cumplimiento de los requerimientos del usuario. Prueba de operación El éxito de esta etapa dependerá fuertemente de la habilidad de las personas que utilicen el sistema, además es importante que esta prueba se haga en un ambiente lo más parecido posible al de producción. Inspecciones En esta prueba lo que se hace es evaluar el código del sistema para verificar ciertas reglas que lo harán fácil de mantener ante supuestas modificaciones. Dichas reglas, deberán estar explicadas dentro de los estándares de la organización. Prueba de desastre En esta prueba lo que se hace es provocar problemas en el ambiente real de la aplicación ya que es la única manera de ver realmente cómo se comporta el sistema ante situaciones inesperadas. Prueba funcional y de regresión Esta fase de la prueba debe verificar la comunicación con los sistemas relacionados. Donde, la prueba funcional verifica la interconexión de la nueva funcionalidad, y la prueba de regresión 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 verificación. De no poder realizarse porque el ambiente necesario para llevarla a cabo sería muy costoso, se dejará para ser medido en producción. Prueba de facilidad de operación 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 ningún tipo de instrucciones a los usuarios, para que pueda reproducirse el normal desarrollo de las transacciones, tal como sería en el ambiente de producción. F.3.3. Verificar el Registro de los Resultados de la Prueba Ya que documentar un problema, es el primer paso para la corrección del mismo, es necesario llevar adelante una verificación del registro de los resultados de la prueba. Esto se llevará a cabo, tomando muestras representativas de tales resultados, para su análisis posterior. Se verificará que estén descriptos al menos, los siguientes aspectos, para todos los problemas encontrados en las pruebas: Declaración del problema: Establecer cuál es el problema. Criterio: Establecer cómo debería 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 documentación de los problemas, es aconsejable seguir estos tres pasos: Documentar el desvío: Esencialmente el usuario compara lo que es con lo que debería ser, y cuando es identificada una desviación en este sentido, corresponde comenzar a desarrollar la declaración del problema. Documentar el/ los efecto/s: Aquí debe evaluarse lo que el problema significa para el sistema. La atención 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 condición. En algunos casos la causa puede ser obvia a través de los hechos. Pero en otros, puede ser necesaria una investigación para encontrarla. F.4. Salidas Muestra de planes de prueba verificados. Muestra de transacciones de prueba verificadas. Muestra de resultados de la ejecución de dichas transacciones verificados. Desvío de los resultados esperados documentados. F.5. Lista de Verificación (Checklist) En la tabla VII se presenta la lista de verificación: TABLA VII. LISTA DE VERIFICACIÓN DEL MÓDULO DE VERIFICACIÓN # Ítem 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 ejecución? Se estableció un ambiente de prueba apropiado para 3 realizar la prueba del software? Se entrenó analistas de calidad en las herramientas de 4 verificación que serán utilizadas durante esta etapa? 5 Se fijó un tiempo adecuado para esta etapa? 6 Se fijaron los recursos adecuados para esta etapa? Los métodos para crear datos de prueba son 7 apropiados para el sistema? Fueron creados los datos de prueba necesarios para 8 probar adecuadamente el software? Fueron programadas todas las técnicas de verificación 9 indicadas en el plan de prueba para ser ejecutadas durante este paso? (Ej. Prueba de regresión) Fueron determinados los resultados esperados de las 10 pruebas? Se ha establecido el proceso por el cual se determina 11 el desvío entre los resultados esperados y los actuales? Se han documentado los resultados esperados y los 12 actuales cuando existe una diferencia entre ellos? Respuesta SI NO N/A Comentarios Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

34 # Ítem Se determinó el potencial impacto de una desviación? (Ej. Problema en la verificación) Se ha establecido un procedimiento para asegurar las acciones / resolución apropiada de los defectos? F.6. Métricas Eficiencia en la detección de defectos: Eficiencia en la remoción de defectos: Tasa de efectividad de la verificación: Antigüedad media de defectos pendientes: Antigüedad media de defectos cerrados: F.7. Involucrados Respuesta SI NO N/A Comentarios Cantidad de defectos detectados hasta verificación Cantidad total de defectos hasta verificación Cantidad de defectos removidos hasta verificación Cantidad total de defectos hasta verificación Cantidad de ítems cubiertos Cantidad total de ítems Total de antigüedad de defectos pendientes al fin de un período Cantidad total de defectos pendientes al fin de un período Total de antigüedad de defectos cerrados al fin de un período Cantidad total de defectos cerrados al fin de un período G.2. Entradas Las entradas dependen del alcance asignado a la validación del sistema (prueba de aceptación). Estas suelen ser: Software probado: Una vez realizada la verificación de las piezas de software se comienza con la prueba de aceptación. Plan de Prueba de Aceptación: Pruebas en Línea ( On-Line ). Pruebas por Lotes ( Batch ). Pruebas de Interfaces. Pruebas de Integración. Pruebas de stress. Pruebas de conectividad. Pruebas de servidores. Lista de defectos no resueltos: Quizás no sea prudente esperar hasta que todos los defectos reportados sean corregidos antes de empezar las pruebas de aceptación. En este caso, los encargados de efectuar las pruebas de aceptación reciben una lista no resuelta de defectos, la cual les permitirá conocer los procesos incorrectos y así enfocar la atención en los criterios principales de aceptación antes de la prueba. G.3. Proceso En la figura 11 se detalla gráficamente, el proceso a desarrollar durante este módulo. G.3.1. Verificar los Criterios de Aceptación Definidos El usuario deberá definir el o los criterios que el software deberá cumplir para ser aceptado. F.7.1. Equipo de Ingeniería Gerente de proyecto. Representante del grupo de análisis de requerimientos. Representante del grupo de análisis funcional. Representante del grupo de diseño. Representante del grupo de analistas desarrolladores. Grupo de testeo. F.7.2. Equipo de Aseguramiento de la Calidad del Software Líder de Aseguramiento de la Calidad del Software Analistas de aseguramiento de la calidad del software Senior y/o Semi-senior. G. Validación del Sistema G.1. Objetivo Describir los procedimientos para identificar los criterios de aceptación para el ciclo de vida de los productos y para validarlos. La aceptación final no solo tiene en cuenta que el producto de software resuelva adecuadamente los requerimientos de los usuarios, sino también, reconocer que el proceso de desarrollo fue adecuado. Como parte del proceso de ciclo de vida, la aceptación del software permite: Detección temprana de los problemas del software. Preparación apropiada de los medios para realizar la prueba. Consideración temprana de las necesidades del usuario durante el desarrollo del software. Fig. 11. Proceso del módulo de validación Los requerimientos de aceptación que el sistema debe cumplir, pueden ser divididos en las siguientes cuatro categorías: Requerimientos Funcionales: Referido a las reglas de negocio que el sistema debe ejecutar. 184 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

35 Requerimientos de Performance: Referido a los tiempos y recursos de operación. Requerimientos de Interfaz: Referido a la relación humano / máquina, máquina / módulo. Requerimientos globales de Calidad del Software: Referidos a la obtención de los límites para los factores o los atributos tales como la fiabilidad, comprobabilidad, exactitud, y usabilidad. Estos criterios deberían estar enunciados y documentados durante la fase de requerimientos, para ser refinados y detallados en las fases siguientes. Se procederá a solicitar la recopilación de estos requerimientos, luego el equipo de aseguramiento de la calidad, procederá a verificarlos. Se debería determinar con el usuario, el grado de criticidad de los requerimientos para los ítems cuyas categorías se presentan en la tabla VIII. G.3.2. Verificar el Desarrollo del Plan de Aceptación El primer paso para completar la aceptación del software es el desarrollo simultáneo de un plan de aceptación, un plan de proyecto y de los requerimientos del software que aseguran que las necesidades del usuario están representadas correcta y completamente. Este desarrollo simultáneo proveerá una visión general que asegurará que todo los recursos necesarios, estarán incluidos en el plan de proyecto. En la tabla IX se detallan los puntos a verificar dentro de un plan de aceptación típico. TABLA VIII. ÍTEMS DE REQUERIMIENTOS PARA DETERMINAR SU CRITICIDAD Categoría Funcionalidad Performance Interfaz Calidad global del software Ítems Consistencia interna de documentos, código, y entre las fases. Trazabilidad (posibilidad de seguimiento) de la funcionalidad. Verificación adecuada de la lógica. Preservación de funcionalidad en el ambiente productivo. Análisis de factibilidad de requerimientos de performance. Herramientas de simulación. Análisis de desempeño en el ambiente productivo. Documentación de la interfaz. Complejidad de la interfaz. Planes de prueba e integración de la interfaz. Ergonomía de la interfaz. Prueba de la interfaz en el ambiente productivo. Cuantificación de medidas de calidad. Criterios para la aceptación de los productos de software. Suficiencia de documentación y normas de desarrollo de sistemas. Criterios de Calidad para la Prueba Operacional. TABLA IX. PUNTOS A VERIFICAR DENTRO DE UN PLAN DE ACEPTACIÓN TÍPICO Contenido Descripción del proyecto Descripción Tipo de sistema. Ciclo de vida definido por la metodología de la organización. Usuarios del sistema. Principales tareas que debe satisfacer el sistema. Principales interfaces externas del sistema. Contenido Responsabilidades del usuario Procedimientos administrativos Descripción de aceptación Descripción Uso normal esperado. Potenciales usos indebidos. Riesgos. Restricciones. Estándares y Normas. Organización y responsabilidades para las actividades de aceptación del sistema. Recursos y cronograma de requerimientos. Requerimientos del recurso. Requerimientos para soporte automatizado, datos especiales, y entrenamiento. Normas, estándares y convenciones. Actualización y revisión de los planes de aceptación. Informes de anomalías. Control de cambios. Resguardo de información. Objetivos para el proyecto. Resumen de criterios de aceptación. Principales actividades de aceptación y revisiones. Requerimientos de información. Tipos de decisiones de aceptación. Responsabilidad de las decisiones de aceptación. G.3.3. Verificar la Ejecución del Plan de Aceptación El objetivo de este paso es, verificar el cumplimiento de los criterios de aceptación, en el producto entregado. Esto se puede llevar a cabo a través de revisiones, que involucran verificar productos provisorios y entregables desarrollados parcialmente, a lo largo del proceso de desarrollo. El criterio de aceptación del sistema, debería estar especificado formalmente en el plan del proyecto. El plan identifica los productos a ser verificados, el criterio específico de aprobación/rechazo, las revisiones, y los tipos de verificación que se harán durante el ciclo de vida completo. Las decisiones de aceptación necesitan una estructura sobre la cual operar, algunos componentes son: contratos, criterios de aceptación y mecanismos formales. La aceptación del software deberá referirse a un criterio específico que los productos deben tener para ser aceptados. El principal medio para alcanzar la aceptación en el desarrollo de los sistemas de software, es mantener una revisión periódica de la documentación y productos de software. Cuando la decisión de aceptación requiere cambios, se hace necesaria otra revisión para asegurarse de que los cambios solicitados hayan sido configurados e implementados en forma correcta, y que el efecto en cualquier otra parte sea aceptable. Las actividades de aceptación, pueden incluir la verificación de las piezas de software. La verificación de aceptación del software, se vuelve formal, cuando durante el ciclo de vida del desarrollo, el usuario acepta o rechaza el mismo. Esto es como un requerimiento contractual entre el usuario y el equipo del proyecto. El rechazo, generalmente, significa que se deberá realizar un trabajo adicional en el sistema a fin de hacerlo aceptable para el usuario. La prueba de aceptación final, es la última oportunidad que tiene el usuario para examinar la funcionalidad, interfaz, performance y aspectos de calidad antes de la revisión final de aceptación. En ese momento, el sistema deberá incluir el software a entregar, toda la documentación de usuario y las versiones finales de otros entregables del sistema. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

36 G.3.4. Revisar la Decisión de Aceptación La aceptación de un sistema generalmente significa que el proyecto se ha completado, con la excepción de alguna contingencia. Las decisiones de aceptación pueden involucrar alguna de las siguientes situaciones: Los cambios solicitados son aceptados antes de pasar a desarrollar la próxima actividad. Algunos cambios, deben ser aceptados y llevados a cabo antes de continuar con el desarrollo del producto, y otros, pueden ser postergados hasta la próxima revisión del producto. El desarrollo puede continuar y los cambios podrán ser aceptados en la próxima revisión. No hay cambios solicitados y el desarrollo puede continuar. Cada una de estas situaciones, será verificada por el equipo de aseguramiento de la calidad, teniendo en cuenta los defectos no resueltos, el cronograma del proyecto, el estado actual del mismo, los recursos involucrados, etc. G.4. Salidas Informe de la decisión de Aceptación. G.5. Lista de Verificación (Checklist) En la tabla X se presenta la lista de verificación. TABLA X. LISTA DE VERIFICACIÓN DEL MÓDULO DE VALIDACIÓN # Ítem 1 Se incorporó la prueba de aceptación al plan general de pruebas? La prueba de aceptación está enfocada como un 2 proceso del proyecto en lugar de un paso aislado al final del testing? Fueron seleccionados los usuarios correctos para 3 determinar los criterios de aceptación para el software y/o componentes de hardware? 4 El grupo que define los criterios de aceptación, es representativo de los usos del sistema a ser probado? 5 Esos individuos aceptan la responsabilidad de identificar los criterios de aceptación? Los criterios de aceptación fueron identificados 6 tempranamente como para lograr influir en el planteo e implementación de la solución? 7 Se ha desarrollado y escrito el plan de aceptación? 8 El plan de aceptación es consistente con los criterios de aceptación? Se están verificando los productos intermedios por parte 9 de los testeadores, antes de ser utilizados para la siguiente tarea de implementación? 10 Se han seleccionado las técnicas de prueba apropiadas para el test de aceptación? 11 Los testeadores tienen el nivel de conocimiento necesario para realizar dicha tarea? 12 Se afectaron los recursos necesarios para la realización de la prueba de aceptación? 13 Se destinó el tiempo necesario para la realización de la prueba de aceptación? 14 Se han publicado las opiniones internas de la prueba de aceptación? 15 Fue buena la reacción del equipo del proyecto en lo que concierne a los testeadores en la prueba de aceptación? 16 Se ha tomado la decisión final de aceptación del sistema? 17 Se han identificado los criterios de aceptación críticos? Los requerimientos fueron escritos con el detalle 18 suficiente, de forma tal de poder obtener a partir de ellos las interfaces? 19 Están los responsables de cada interfaz, descritos en el diagrama? 20 Se ha definido un caso de prueba para cada uno de los límites que posee el sistema? 21 Los usuarios del sistema están de acuerdo con los casos definidos? Los consideran completos? 22 Se definieron tanto las condiciones normales como las fallidas a probar? 23 Los usuarios están de acuerdo con que los casos de prueba cubren todos los probables escenarios? Respuesta SI NO N/A Comentarios G.6. Métricas Eficiencia en la detección de defectos: Eficiencia en la remoción de defectos: Tasa de efectividad de la verificación: Estabilidad de las criterios de aceptación: Estabilidad de la aceptación: G.7. Involucrados Cantidad de defectos detectados hasta validación Cantidad total de defectos hasta validación Cantidad de defectos removidos hasta validación Cantidad total de defectos hasta validación Cantidad de ítems cubiertos Cantidad total de ítems Cantidad de criterios iniciales Cantidad total de criterios Cantidad de cambios durante la aceptación Cantidad total de cambios G.7.1. Equipo de Ingeniería Gerente de proyecto. Representante del grupo de análisis de requerimientos. Representante del grupo de análisis funcional. Representante del grupo de diseño. Representante del grupo de analistas desarrolladores. Grupo de testeo. Usuario final. G.7.2. Equipo de Aseguramiento de la Calidad del Software Líder de Aseguramiento de la Calidad del Software Analistas de aseguramiento de la calidad del software Senior y/o Semi-senior. H. Instalación H.1. Objetivo Realizar una verificación completa de la fase de instalación para nuevos sistemas y/o cambio de versiones. La verificación, incluye, para cada criterio de instalación identificado, una evaluación recomendada y las técnicas y herramientas sugeridas para llevarla a cabo. H.2. Entradas Plan de instalación. Diagrama de flujo de la Instalación. Documentos y listados de instalación (sólo si es requerida una instalación especial). Resultados de la verificación de instalaciones especiales. Documentación de pasaje del sistema a producción. Instrucciones para los nuevos operadores. Instrucciones y procedimientos para los nuevos usuarios. Resultado del proceso de instalación. H.3. Proceso En la figura 12 se detalla gráficamente, el proceso a desarrollar durante este módulo: 186 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

37 H.3.2. Verificación de la Instalación de Cambios de Software El objetivo principal es instalar el cambio requerido en el tiempo adecuado. A continuación se detallan los objetivos específicos de la instalación de cambios: Poner a la aplicación modificada en producción. Evaluar la eficiencia de los cambios. Monitorear la exactitud de los cambios. Mantener actualizadas con las últimas versiones disponibles, los ambientes de prueba y producción. Son tres las sub-tareas a verificar en la instalación de cambios de software. Fig. 12. Proceso del módulo de instalación H.3.1. Verificación de la Instalación de Nuevo Software La fase de instalación posee dos dificultades para el equipo de aseguramiento de la calidad. La primera es que la instalación es un proceso separado del resto del desarrollo de la aplicación. Estas funciones no están relacionadas con las necesidades del usuario, pero sí con las de instalar en producción una aplicación completa y verificada. La segunda dificultad es que la instalación ocurre en un lapso de tiempo muy corto. Es común que la instalación dure unas horas. Por lo tanto la verificación debe ser bien planeada y ejecutada. Es importante que los resultados de la verificación estén disponibles antes de la instalación completa del sistema. El objetivo de la verificación es determinar si la instalación fue exitosa, por lo tanto los resultados deben estar disponibles lo antes posible. Esto significa que los resultados a obtener de la verificación deben estar explicitados antes de que la verificación comience. Los 15 factores a tener en cuenta en la verificación de la instalación son: Integridad y exactitud de la instalación. Prohibición de modificación de datos durante la instalación. Integridad de archivos de producción. Registro de pistas de auditoría de instalación. Integridad del sistema/versión anterior asegurado (continuidad de procesamiento). Recuperación ante fallas de la instalación. Control de acceso durante la instalación. Instalación acorde a la metodología. Instalación en producción de los programas indicados en la fecha asignada. Puesta a disposición de instrucciones de instalación. Documentación completa (Mantenibilidad). Documentación completa (Portabilidad). Interfaces. Monitoreo de la performance. Procedimientos operativos. a) Verificar si es adecuado el plan de recuperación ante fallas Existen varios aspectos de los cambios que impactan en el proceso de recuperación ante fallas: Agregado de una nueva función. Cambio en un JCL (Job Control Language). Uso adicional de programas utilitarios. Cambios en períodos de resguardo. Cambios en los programas. Introducción de un formulario nuevo o revisado. Los analistas de calidad deben evaluar el impacto en el plan de recuperación, cambio por cambio. Si determinan que el cambio afecta a la recuperación, se debe actualizar el plan. b) Verificar que el cambio correcto, fue puesto en producción El pasaje de la modificación, desde del ambiente de prueba a producción lo debe hacer el dueño del software, previa aprobación del usuario. El ambiente de producción debería ser capaz de controlar los programas de acuerdo con la fecha de puesta en producción. Cada versión del programa en producción debería ser identificada (etiquetada) de acuerdo a si entra o sale de producción. Debe estar disponible para cada programa un historial de los cambios, y así poder proveer pistas de auditoría. Para verificar que se introdujo el cambio correcto en producción se verificará lo siguiente: Que los cambios en los programas hayan sido documentados: El objetivo es contar con un historial, para proveer pistas de auditoría que indiquen cuándo 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 producción. El dueño del software decide cuándo una versión va a ser pasada a producción. Esta aprobación 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 autorización. Se debe elaborar un formulario que autorice la eliminación 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, después de recibir la debida autorización. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

38 H.3.3. Seguimiento en Producción Los sistemas aplicativos son propensos a tener problemas inmediatamente después de introducir una nueva versión. Por eso es necesario monitorear las salidas del aplicativo, una vez instalada la nueva versión en producción. El personal asignado al mantenimiento de software y el usuario deberán proveer pistas, acerca de dónde ellos creen que podrían ocurrir problemas. El tipo de indicios incluye: Investigación de transacciones. Clientes. Reportes. Archivos. Performance. Estos indicios deben ser documentados mediante el uso de un formulario. H.3.4. Documentar los Problemas Los problemas detectados durante el monitoreo de los cambios, deben ser documentados. Además se debe evaluar el riesgo asociado a ese problema. El reporte de un problema causado por un cambio en el sistema, permite asociar tal problema a lo específico del cambio. Este reporte debe ser enviado al analista de mantenimiento de software para su análisis y posterior corrección. H.4. Salidas Reporte de recuperación ante fallas. Reporte de historia de cambios al software. Reporte de puestas en producción. Reporte de autorización de eliminación de versiones innecesarias. Reporte de notificación de monitoreo de cambios de software. Reporte de problemas causados por cambios de Software. H.5. Lista de Verificación (Checklist) En la tabla XI se presenta la lista de verificación. H.6. Métricas Eficiencia en la detección de defectos: Eficiencia en la remoción de defectos: Tasa de efectividad de la verificación: H.7. Involucrados H.7.1. Equipo de Ingeniería Gerente de proyecto. Grupo de mantenimiento de software. Grupo de instalación de software. Cantidad de defectos detectados hasta instalación Cantidad total de defectos hasta instalación Cantidad de defectos removidos hasta instalación Cantidad total de defectos hasta instalación Cantidad de ítems cubiertos Cantidad total de ítems Grupo de operaciones. H.7.2. Equipo de Aseguramiento de la Calidad del Software Líder de Aseguramiento de la Calidad del Software TABLA XI. LISTA DE VERIFICACIÓN DEL MÓDULO DE INSTALACIÓN # Ítem Cada cambio es revisado para cada impacto sobre el plan de reinicio/recuperación? Si el cambio impacta a la recuperación, es calculado nuevamente el tiempo de no servicio? Si el cambio impacta a la recuperación, es estimado nuevamente el riesgo del tiempo de no servicio? Los cambios necesarios para el proceso de recuperación son documentados? La notificación de los cambios de la versión de producción fueron documentados? Los cambios de los sistemas de aplicación de control de cambio de aplicación son controlados por una numeración? Existen procedimientos para eliminar versiones antiguas de las bibliotecas de objetos? Existen solicitudes de eliminación para que producción sea autorizado para eliminar programas? Están establecidos procedimientos para asegurar que la versión de los programas sea pasada al ambiente de producción en la fecha correcta? Si esto afecta a procedimientos de operación, Están notificados los operadores del día en que la nueva versión se pase a producción? Están establecidos los procedimientos para monitorear los cambios de los sistemas de aplicación? Las personas que monitorean reciben notificación de que el sistema de aplicación fue cambiado? 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 aplicación reciben una guía de que acciones tomar si el problema ocurre? Los problemas detectados, inmediatamente después de que el cambio del sistema ocurrió, son documentados en un formulario especial para poder vincularlos a un cambio en particular? Se solicita, a las personas que documentan problemas, que documenten el impacto a nivel organizacional que puede implicar el problema? La información acerca de la instalación de cambios de software es recopilada y documentada? El servicio de la dirección realiza revisiones y utiliza la retroalimentación de los datos? El servicio de la dirección periódicamente revisa la efectividad de la instalación de cambios de software? Respuesta SI NO N/A Comentarios Analistas de aseguramiento de la calidad del software Senior y/o Semi-senior. I. Metodología, Estándares y Procedimientos I.1. Objetivo La verificación de productos, deberá ajustarse a la organización. Esto incluye ajustar el vocabulario y los términos utilizados en la verificación para que sean los mismos que los utilizados en la organización para describir los componentes del sistema, documentos y productos. I.2 Entradas Metodología de desarrollo de la organización. Estándares de la organización. Procedimientos de la organización. Productos que ingresan a cada una de las fases definidas en el presente modelo. I.3 Proceso En la figura 14 se detalla gráficamente, el proceso a desarrollar durante este módulo. 188 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

39 I.3.1. Verificar el Cumplimiento de los Estándares de Documentación La formalidad, extensión y nivel de detalle de la documentación a preparar dependerán de las prácticas de la organización y del tamaño, complejidad y riesgo del proyecto. Fig. 13. Proceso del módulo de metodología, estándares y procedimientos Lo que es adecuado para un proyecto puede ser inadecuado para otro. Para verificar la documentación, se procederá a comprobar si está completa, es adecuada y cumple con las normas y estándares corporativos. Esta tarea intenta evaluar el apego a los procedimientos y estándares definidos por la metodología de la organización, evaluando los criterios así establecidos y determinando si el nivel y el alcance de la documentación cumplen con lo requerido. En el caso que la metodología de la organización, establezca pautadamente la documentación necesaria para cada tipo de proyecto según su criticidad, se procederá a verificar si la documentación cumple con cada una de esas pautas. I.3.2. Verificar la Integridad de la Documentación Para evaluar la integridad de la documentación, se usarán los criterios definidos al respecto, en la metodología de la organización. El equipo de aseguramiento de la calidad de software deberá determinar si cada documento cumple con esos criterios. Si la documentación 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 capítulo de Técnicas y Herramientas, nombrándose a continuación cada uno de ellos: Contenido de la documentación. Usuarios del documento. Redundancia. Flexibilidad. Tamaño del documento. Combinación de diferentes tipos de documentos. Formato. Secuencia de contenido. Títulos de secciones/párrafos. Expansión de los párrafos. Diagramas de flujo y tablas de decisión. Formularios. Es aconsejable llevar a cabo una o más verificaciones de adecuación de la documentación a los estándares de la organización. Tales verificaciones requieren que una persona capaz, no asociada al proyecto, haga una simulación de cambio al sistema basado en la documentación actual y el requerimiento de cambio (no deben cambiarse ni la documentación real ni los programas). Después que la persona haga el cambio, alguien familiarizado con el proyecto debe evaluar si se ha hecho correctamente. Esta verificación revelará si: La documentación es entendible para las personas ajenas al proyecto Una persona ajena puede utilizar la documentación para hacer un cambio correctamente, y lo puede hacer de manera eficiente y efectiva. I.3.3. Verificar el grado de actualización de la Documentación La documentación que no esté actualizada no será útil. Si la metodología de la organización ya establece algún método para verificar el grado de actualización de la documentación, dicho método será usado por el grupo de verificación durante la misma. Caso contrario, se propone que el equipo de verificación de la documentación utilice cualesquiera de las siguientes cuatro técnicas de verificación (que se detallarán se detallan en el capítulo de Técnicas y Herramientas) para validar la actualización de la documentación: Utilizar la documentación existente para llevar a cabo un cambio en la aplicación Comparar el código fuente de los programas con la documentación Verificar que la documentación esté vigente Verificar la actualización de los documentos con el usuario final Las anteriores técnicas podrán aplicarse sobre los documentos completos o sobre partes de los mismos o sobre una muestra de la documentación del proyecto. I.4. Salidas Reporte de documentación verificada I.5 Lista de Verificación (Checklist) En la tabla XII se presenta la lista de verificación. I.6. Métricas Documentación vigente: Revisión de documentos: Cantidad de documentación vigente no actualizada Cantidad total de documentación vigente Cantidad de documentos revisados Cantidad de documentos a revisar Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

40 I.7. Involucrados I.7.1. Equipo de Ingeniería Gerente de proyecto Responsables de elaboración de documentos Grupo de Metodología, Estándares y Procedimientos TABLA XII. LISTA DE VERIFICACIÓN DEL MÓDULO DE METODOLOGÍA, ESTÁNDARES Y PROCEDIMIENTOS # Ítem 1 Existen estándares para la documentación del sistema? Los miembros del equipo de prueba están informados sobre las 2 intenciones y contenidos de esos estándares? Los estándares son adaptables a sistemas de varios tamaños, de manera que el tamaño del proyecto no sea directamente proporcional con 3 al tamaño del documento? Se les entregó al equipo de aseguramiento de la calidad una copia completa de la documentación del sistema correspondiente a esta 4 verificación? El equipo de aseguramiento de la Calidad ha medido las necesidades de la documentación de acuerdo a los criterios establecidos por la 5 metodología de la organización? El equipo de aseguramiento de la calidad ha determinado qué 6 documentos deben revisarse? Las personas del proyecto están de acuerdo con las sugerencias del equipo de aseguramiento de la calidad en cuanto a las revisiones de la 7 documentación? El equipo de aseguramiento de la calidad determinó la completitud de los documentos usando los criterios detallados en la metodología de la 8 organización? El equipo de aseguramiento de la calidad ha utilizado el proceso de Inspección para determinar la completitud de la documentación del 9 sistema? El equipo de Aseguramiento de la Calidad de Software ha determinado 10 el grado de actualización de la documentación del proyecto? El equipo de aseguramiento de la calidad ha desarrollado un documento detallando las deficiencias de la documentación respecto de los 11 estándares de la organización? 12 Se ha asegurado el equipo de aseguramiento de la calidad de que las deficiencias descritas están documentadas? Respuesta SI NO N/A Comentarios I.7.2. Equipo de Aseguramiento de la Calidad del Software Líder de Aseguramiento de la Calidad del Software Analistas de aseguramiento de la calidad del software Senior y/o Semi-senior. V. TÉCNICAS Y HERRAMIENTAS En el presente capítulo se presentan y describen brevemente las principales Técnicas y Herramientas identificadas en los módulos del modelo general de aseguramiento de la calidad. También se presenta, sólo a modo de ejemplo, un conjunto de productos entregables que se obtienen al aplicar éstas técnicas y herramientas. Lo que se pretende mostrar con estos productos, son los datos que se deberían registrar, más allá del formato, el soporte electrónico o detalles de implementación. A. Estimación del Proyecto A.1. Verificar la Validez de la Estimación de los Costos de Software Una estimación inapropiada de costos puede dañar más a la calidad del Proyecto de Software que a cualquier otro factor, por eso, la verificación puede aumentar la validez de la estimación. La estimación del software es un proceso de tres partes como se describe a continuación: Validar el modelo de estimación. Validar que el modelo incluya todos los factores necesarios. Verificar la efectividad del modelo de estimación de costos. A.1.1. Validar el Modelo de Estimación La organización necesita usar un modelo para realizar las estimaciones. El objetivo de este punto es validar la sensatez del modelo de estimación. Esta verificación deberá desafiar el modelo usando las siguientes 14 características deseables para la estimación de costos. Estas características buscan determinar los puntos débiles del modelo: El alcance del modelo debe estar bien definido. El modelo debería ser ampliamente aplicado. El modelo debe ser fácil de usar. El modelo debe ser capaz de usar información actual, cuando esté disponible. El modelo debe permitir el uso de datos históricos y ajustarlos para una organización en particular y un tipo de software. El modelo debe ser verificado contra un número histórico razonable de proyectos. El modelo debe requerir sólo entradas basadas en las propiedades del proyecto, las cuales están bien definidas y pueden ser establecidas con un grado de certeza razonable al momento en que la estimación 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 parámetros del proyecto que fueron establecidos teniendo un marcado efecto en el costo y no debe requerir entrada de parámetros no correlacionados con costos. El modelo debe incluir estimaciones de cómo y cuándo 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 análisis de sensibilidad, para que el responsable de la estimación pueda ver la variación de los parámetros seleccionados. El modelo debe incluir alguna estimación 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 organización 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 estimación. 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 dónde afecta el factor significativamente en el costo actual de construir el software. A continuación se describen los factores influyentes en el costo del software: 190 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

41 Tamaño del software. Porcentaje de diseño y/o código nuevo. Complejidad del sistema de software. Dificultad de diseño y codificación. Calidad. Lenguajes a usar. Clasificación de nivel de seguridad del proyecto. Tipo de máquina a utilizar (tecnología). Utilización de hardware. Volatilidad del requerimiento A continuación se describen los factores influyentes, que dependen de la organización: Cronograma del proyecto. Personal. Ambiente de desarrollo. Recursos no atribuibles directamente a aspectos técnicos del proyecto. Recursos de computación. Honorarios. Inflación. A.1.3. Verificar la Exactitud del Modelo de Estimación de Costos Se proponen las siguientes cuatro verificaciones para validar las estimaciones producidas por el modelo de estimación de costos de software: 1) Recalcular lo estimado: El analista de calidad puede validar el proceso de estimación ejecutando el modelo de estimación. El propósito de esto es: Validar que los datos de entrada fueron ingresados correctamente. Validar que los datos de entrada fueron razonables. Validar que la ecuación matemática fue calculada correctamente. 2) Comparar estimaciones realizadas con proyectos típicos: El analista de calidad puede determinar cuánto tiempo lleva desarrollar proyectos del mismo tamaño y complejidad. El cálculo realizado por el sistema de estimación, es luego comparado con costos actuales de proyectos típicos. Si existiera una diferencia el analista de calidad puede evaluar más en detalle, la validación de la estimación. 3) Razonabilidad de la estimación: Esta verificación es similar a la del punto anterior, se utiliza la experiencia pasada. El analista de calidad documenta los factores que influyen sobre la estimación de costos, documenta el cálculo producido por el sistema de estimación y luego valida la razonabilidad de esa estimación teniendo en cuenta experiencias anteriores. Es recomendable un mínimo de tres experiencias consultadas a los Gerentes de proyecto. En caso en que uno o más no sienta que es razonable la estimación, la misma deberá ser rechazada. 4) Redundancia en estimaciones de costo de software: El Analista de calidad debe recalcular la estimación usando otro modelo de estimación de costo. Si la diferencia es pequeña, la estimación será confiable. Caso contrario se tendría que realizar una investigación adicional. A continuación, se detallan las fuentes de los modelos de estimación de software: Desarrollos internos (propios) de la organización. Modelos de estimación incluidos en metodologías de desarrollo de sistemas. Paquetes de software para desarrollo de estimaciones de software. Uso de puntos de función para la estimación de costos de software B. Estado del Proyecto: Sistema de Acumulación de Puntos La creciente complejidad de los sistemas, combinado con los requerimientos para diseños estructurados y modulares, ha aumentado la cantidad de elementos de software desarrollados y entregados. El aumento de elementos, más los tradicionales hitos usados para medir el progreso han hecho subjetivo y a menudo poco confiable el seguimiento del desarrollo del software y la predicción del consumo progresivo del tiempo. Se ha utilizado exitosamente un sistema para seguir el progreso del desarrollo de software a través de un esquema de puntos ganados. Los puntos están asignados en cada paso en el ciclo de desarrollo del software de la organización. Los pasos son hitos en los cuales un producto generado es aceptado. Al aceptar los productos se ganan los puntos que poseen asociados. La proporción de puntos ganados sobre el total de puntos posibles se recopila y así se determina el progreso logrado. Luego, se generan informes, tabulando la información en una variedad de reportes gerenciales. El sistema así implementado es flexible y altamente automatizado. Los puntos acumulados son rápidamente verificados, objetivos, y basados en el estado actual del desarrollo del proyecto. Cálculos simples o comparaciones de los puntos acumulados proveen una medida precisa del progreso, del desvío en el cronograma y la predicción de progresos futuros. B.1. Cómo Utilizar el Sistema de Puntos El sistema de acumulación de puntos, propuesto por W. Perry [5], es una extensión del sistema de "hitos". En su forma más 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 ilustración, se desarrollarán 5 componentes y 4 hitos definirán el proceso de desarrollo. Los hitos pueden representar diseños revisados y aceptados, código 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 revisión de diseño, inspección de código, prueba de verificación, 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 cómo es un reporte simple de estado. Este esquema simplificado funciona bien para un conjunto homogéneo de componentes donde todos tienen similar complejidad y cada hito representa una cantidad de trabajo similar. A través de la introducción de "pesos" en los factores, pueden manejarse fácilmente, los componentes de complejidad diversa o los hitos que representan esfuerzos disímiles para completarlos. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

42 TABLA XIII. REPORTE SIMPLE DE ESTADO REPORTE DEL ESTADO DEL SISTEMA ÍTEM DISEÑO CODIFICACIÓN VERIFICACIÓN ENTREGA PUNTOS GANADOS Componente A Componente B 1 1 Componente C 1 1 Componente D Componente E TOTALES PORCENTAJE 9/20 = 45= % El motor del sistema es un archivo de datos y algunos reportes simples. El archivo de datos es simplemente una colección de registros, uno por cada ítem que debe seguirse, que contiene campos para indicar si se ha alcanzado algún hito. Usualmente es ventajoso incluir campos para la descripción de los ítems, analista responsable, identificación del trabajo, entre otros. El mantenimiento o actualización del archivo puede ser tan efectivo como modificar registros con un editor de línea o tan complejo como crear un programa interactivo para ese propósito. 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 más sofisticados, un programa puede determinar que ha ocurrido un hito (compilación sin errores o prueba exitosa) y automáticamente 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 más grandes pueden necesitar varios reportes para subsistemas diferentes o reportes resumen que enfaticen los cambios ocurridos. B.2. Utilización del Sistema de Puntos como Método de Prueba El método 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 evaluación 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. Nótese que si hay una diferencia significativa en la estimación 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 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. B.2.2. Planeamiento de la Prueba El método de puntos para el seguimiento del progreso indica cuándo 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á destinado a asistir al equipo de proyecto, indicándole cuando los programas/subsistemas estarán disponibles para verificar. B.2.3. Reportar el Estado de la Prueba El sistema de puntos también indica cuándo está hecha la prueba y cuando se liberan los módulos a producción. La información 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 diseñada para identificar y evaluar riesgos y determinar qué es lo que el sistema debe hacer con cada uno de ellos. A continuación 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 diseño. La implementación de esta herramienta es un proceso de cinco pasos. Los pasos deben ser ejecutados en la siguiente secuencia: C.1 Identificación del Equipo de Evaluación 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 diseño para reducir los riesgos a un nivel mínimo 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 específicamente con el propósito de confeccionar la matriz de riesgo. El grupo debería contar con entre 3 y 6 miembros, y al menos poseer las siguientes habilidades: Conocimiento sobre el uso de la aplicación. Entender el concepto de riesgo. Habilidad para identificar controles. Estar familiarizado con ambos, riesgos de la aplicación y de los servicios de información. Entender el concepto de servicio de información y sistema de diseño. Los candidatos en el grupo de riesgo deberán 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. Identificación de Riesgos El primer objetivo del grupo evaluador de riesgos, es identificar los riesgos enfocándose en la aplicación, pero no en 192 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

43 los riesgos ambientales. El equipo evaluador de riesgo, puede utilizar uno de los dos métodos siguientes para la identificación del riesgo: C.2.1. Análisis de Escenarios de Riesgos En este método el equipo de riesgo delibera sobre los riegos potenciales de la aplicación usando sus experiencias, juicio y conocimiento del área de aplicación. 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 aplicación. C.2.2. Lista de Verificación de Riesgos Se provee al equipo de riesgo de una lista con los riesgos más comunes que ocurren en aplicaciones automáticas. El equipo selecciona de la lista aquellos riesgos aplicables a la aplicación. En este método, el equipo necesita pocas habilidades porque la lista de riesgos provee el estímulo para el proceso, y el objetivo del equipo es determinar cuales de los riesgos de la lista son aplicables a la aplicación. He aquí una lista de riesgos para su identificación: Acceso no controlado al sistema. Prácticas de seguridad no eficaces para la aplicación. Errores de procedimiento en los servicios de información: Procedimientos y controles. Manipulación de medios de almacenamiento. Errores del programa. Defectos del sistema operativo. Fallas en el Sistema de Comunicación: 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 aceptación del perjuicio de cada riesgo identificado. Otra forma de manifestar el nivel de daño aceptable, es el objetivo mensurable de control. La adecuación del control no puede chequearse hasta que no esté definido el nivel de perjuicio de cada riesgo. Por lo tanto, mientras que la definición de los objetivos de control es responsabilidad del usuario y del proyecto, puede llevar a la formación 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 típico sistema de Facturación y Distribución. Esta matriz muestra cuatro riesgos para el sistema de Facturación y Distribución, 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 envíos 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 envío que se despacha se prepara una factura. Sin embargo, nótese que el siguiente riesgo es que el producto se facturará con un precio o cantidad errónea y que los controles tienen establecido un nivel de defecto mayor a cero, como los otros dos riesgos. C.4. Identificar Controles en Cada Sistema Durante la fase de diseño, el equipo de riesgo identificará los controles en cada fase del sistema de aplicación para cada riesgo identificado. Los segmentos de sistemas más comunes son: Origen: La creación del documento fuente más la autorización asociada con aquella transacción original. TABLA XIV. EJEMPLO DE MATRIZ DE RIESGO AL FINAL DE LA FASE DE REQUERIMIENTOS RIESGO Despachado pero no facturado Facturado con precio o cantidad errónea OBJETIVOS DE CONTROL Asegurar que todos los envíos estén facturados Facturar al precio actual el 99% de los ítems básicos y error permitido menor al 10% Facturado al cliente equivocado Reducir facturas perdidas a menos del 1% Despacho del producto o cantidad equivocada Despachar los productos y cantidades correctas al 99% de los ítems de base Ingreso de Datos: Transferencia de información a un medio legible por la máquina. Comunicación: El movimiento de datos desde un punto del sistema a otro. El movimiento puede ser manual o electrónico. Procesamiento: Aplicación del sistema lógico a los datos. Almacenamiento: La retención de datos, por largos o cortos períodos de tiempo. Salida: La traducción de la información de computadora a los medios entendibles y utilizables. Uso: Satisfacción de la necesidad del negocio a través de los resultados del sistema de procesamiento. El equipo de evaluación de riesgos, determinará qué controles son aplicables a qué riesgos y los registrará en el segmento correcto del sistema. Al término del desarrollo de la matriz de riesgo, el equipo de riesgo hará una estimación para verificar si los controles son los adecuados para reducir el riesgo hasta el nivel de aceptación identificado en el objetivo de control. Esto verificará la efectividad de los controles al finalizar el proceso de diseño. En la tabla XV se muestra un ejemplo de matriz de riesgo para sistemas de facturación y distribución al final de la fase de diseño. Los mismos cuatro riesgos identificados durante la fase de Requerimientos (tabla XIV) también se muestran en esta matriz, por lo que los controles están asociados a cada riesgo. En este ejemplo, el riesgo de despachar sin facturar muestra que los controles 1, 2 y 3 ayudarán a disminuir ese riesgo (para una matriz real estos controles deben describirse). La matriz muestra en qué segmento del sistema de aplicación residen aquellos controles. Después 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 verificación termina cuando el equipo de riesgo determina si los controles son los adecuados para reducir cada uno de los riesgos identificados al nivel aceptable. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

44 TABLA XV. EJEMPLO DE MATRIZ DE RIESGO AL FINAL DE LA FASE DE DISEÑO RIESGO DEL SEGMENTO DEL SISTEMA ORIGEN INGRESO DATOS COMUNIC. PROCES. ALMAC. SALIDA USO Despacho sin facturación #1 #2 #6 Facturado con precio o calidad errónea Facturado al cliente equivocado Despacho de producto o cantidad errónea #6 #17 #18 #7 #8 #9 #12 #3 #19 #20 #10 #11 #14 #15 #16 #21 #22 D. Análisis de Factores (Módulo 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 verificación para cada ítem. Hay 15 ítems a considerar, cubriendo cada fase del proceso de desarrollo. Para cada ítem hay un programa de verificación que tiene en cuenta ciertas consideraciones las cuales se encuentran detalladas más abajo. El programa de verificación enumera aquellos criterios, que aseguran al equipo de aseguramiento de la calidad, que la magnitud de esa preocupación es mínima. A estos criterios debe responder el equipo de aseguramiento de la calidad. También se debe realizar una verificación suficiente para evaluar si el equipo de proyecto ha manejado adecuadamente cada factor de verificación. A continuación, se detallarán brevemente cada uno de los factores a tener en cuenta: D.1. Requerimientos Compatibles con la Metodología (Factor: Metodología) El procedimiento utilizado para definir y documentar requerimientos, debe estar presente durante la fase de requerimientos. Cuanto más formales sean estos procedimientos, se facilita el proceso de su verificación. El proceso de requerimientos es un proceso de, análisis, toma de decisiones y registro de requerimientos en una forma predefinida para poder utilizarse luego en el diseño. D.2. Funcionalidad de las Especificaciones (Factor: Precisión) La satisfacción 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 difíciles de usar finalmente no se utilizan, en cambio los sistemas funcionales fáciles de usar son altamente utilizados. Entonces los desarrolladores, deberán crear especificaciones fáciles 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 también las áreas donde los cambios son muy probables. Las especificaciones determinarán los métodos de mantenimiento (Ej.: cambio de parámetros introducido por el usuario) y el intervalo de tiempo en el cual se necesitan implementar dichos cambios. D.5. Necesidades de Portabilidad (Factor: Portabilidad) La capacidad para operar el sistema en diferentes tipos de hardware, o migrarlo a otra versión, deberá enunciarse como parte del requerimiento. La necesidad de tener la aplicación desarrollada como portable, puede afectar significativamente la implementación de requerimientos. D.6. Interfaces del Sistema (Factor: Acoplamiento) Se debe definir en forma precisa, la información esperada como entrada desde otros sistemas computadorizados y las salidas a entregar a otros sistemas. Esta definición no solo incluye los tipos de información intercambiada, sino también, 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 información. D.7. Criterios de Performance (Factor: Performance) Debe quedar establecido: la eficacia, economía y eficiencia esperadas del sistema. Estos objetivos son una parte integral del proceso de diseño. Cuando no son alcanzados, la insatisfacción del usuario está garantizada. Como producto final de la fase de requerimientos, se realizará el análisis del costo-beneficio del factor performance, calculado para la aplicación. D.8. Necesidades operativas (Factor: Facilidad de Operación) Las consideraciones operativas deben definirse durante la fase de requerimientos. Esto es especialmente importante en sistemas de aplicación manejados por el usuario. Los procesos a seguir para operar el sistema, en otras palabras, los procedimientos necesarios para procesar transacciones, deben ser lo más simple posible. También deben considerarse procedimientos de operación por excepción 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 precisión de la facturación, el porcentaje de órdenes que necesitan procesarse dentro de las 24 horas, etc. La tolerancia de facturación puede afirmar que se procesarán 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 período de tiempo. Si no se define el nivel de defectos esperados, normalmente se espera cero defectos. Los controles para lograr cero defectos son antieconómicos. Usualmente es más económico, que surja una cantidad mínima de defectos en el proceso pero que sean detectados y mensurables. D.10. Reglas de Autorización Definidas (Factor: Autorización) Deben especificarse los métodos de autorización (niveles de seguridad) para asegurar que las transacciones se procesen de 194 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

45 acuerdo con la intención que tiene la organización, respecto del sistema. D.11. Requerimientos de Integridad de Archivos (Factor: Integridad de Archivos) Se necesita especificar los métodos para asegurar la integridad de los archivos. Esto normalmente incluye el conjunto de controles que deben mantenerse dentro del archivo e independientemente de la aplicación. Los controles deben asegurar que los registros de detalle sean consistentes con los totales de control para cada archivo. D.12. Recuperación ante Fallas (Factor: Auditoria) La recuperación abarca los procedimientos de recomposición ante la identificación de un problema. Se debe definir para cada aplicación, las necesidades de recomposición de procesos e información. Si la recomposición es necesaria, se necesita enunciar el momento para su ejecución. Este momento, puede variar según la hora del día y el día de la semana. Estos requerimientos de recomposición 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 mínimos, puede ser innecesario asegurarse el procesamiento continuo. Por el contrario, cuando la continuidad de la operación es esencial, es necesario duplicar los equipos y centros de cómputos, 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 programación, 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 relación entre recursos de sistema y humanos. Los requerimientos deben enunciar todos los recursos del sistema disponibles sujetos a control, y luego indicar quién debe tener acceso a aquellos recursos y con qué propósitos. Al final del módulo, el equipo de aseguramiento de la calidad, puede emitir juicio acerca de la adecuación 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 más de lo normalmente esperado para el criterio. Evaluación adecuada: El equipo de proyecto ha hecho el trabajo suficiente para asegurar el control por encima del criterio. Evaluación inadecuada: El equipo de proyecto no ha hecho el trabajo suficiente, y deben trabajar más en este criterio. No aplicable (N/A): Debido al tipo de aplicación o diseño filosófico del sistema por parte de la organización, la implementación de este criterio no es aplicable al sistema que se está revisando. E. Inspecciones Las inspecciones y las recorridas walkthrough apuntan a asistir a los productores para mejorar su trabajo. Las inspecciones intentan examinar técnicamente el trabajo y proveer a los productores, una evaluación independiente de aquellas áreas productivas en donde las mejoras son necesarias. Las recorridas son generalmente menos formales y están conducidos en un formato más educacional. Las inspecciones, por el contrario, generalmente tienen un formato formal, la asistencia es específica, y la información 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 diseño de alto nivel, el diseño de alto nivel antes de comenzar el diseño detallado, el diseño detallado antes de comenzar la implementación, y la implementación antes de comenzar la verificación. Esto no significa que todos los diseños de alto nivel deben ser inspeccionados antes del comienzo de cualquier diseño detallado, pero el diseño específico a realizar debe basarse en el trabajo que ha sido inspeccionado. También es de ayuda inspeccionar los casos verificados y la documentación. Se recomiendan las inspecciones para diseño, codificación, casos de prueba, y documentación. Caso contrario, es adecuado un proceso de recorrida menos formal. E.1. Proceso El proceso de inspección sigue ciertos principios básicos: La inspección es un proceso formal, estructurado a través de un sistema de listas de verificación ( checklists ) y roles definidos para los participantes. Provee un instrumento ordenado para implementar un estándar de excelencia de ingeniería del software o de conocimiento en toda la organización. Los estándares y listas de verificación genéricas son desarrollados para cada tipo de inspección y, cuando sea apropiado, se ajustan a las necesidades de un proyecto específico. Estas listas cubren el planeamiento de la inspección, la preparación, la conducción, la salida y reportes de normas. Los inspectores están preparados de antemano y tienen identificados sus tareas y cuestiones antes de que comiencen la inspección. El foco de la inspección estará en identificar problemas, no en resolverlos. Este foco, junto a lo mencionado en el punto anterior, asegura que la inspección pueda manejarse con una mínima pérdida de tiempo. Una inspección es conducida por técnicos para técnicos. Los directivos no se involucrarán, aunque serán informados de los hallazgos y las fechas en las cuales se resolverán los problemas identificados. La información de la inspección deberá ser ingresada a una base de datos y se la utilizará para monitorear la efectividad de la inspección, seguimiento y conducción de la calidad del producto. Mientras mucha gente pueda estar interesada en los resultados de la inspección, el propósito de la inspección es asistir a los productores para mejorar su trabajo. Esto puede hacerse mejor limitándose a cinco o seis los inspectores. El punto clave de esta limitación es la atención técnica. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

46 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 métodos de inspección antes de que puedan hacer un trabajo competente. Esto les dará las herramientas básicas y los ayudará a tener mayor confianza en sí mismos, necesaria para liderar tal actividad. Como las inspecciones bien realizadas requieren de una intensa concentración de todos los participantes, éstos pueden quedar exhaustos. Por esto, las sesiones de inspección generalmente no deben exceder las dos horas. También es de gran ayuda asignar algunos inspectores en áreas productivas específicas durante el proyecto. E.2. Participantes Los participantes de la inspección, se detallan a continuación: El moderador (líder de inspección): Persona responsable para liderar la inspección pronta y eficientemente a una conclusión 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 inspección. E.3. Salidas Las salidas a obtener luego de realizarse una inspección, se detallan a continuación: Informe de Inspección (Figura 14) Resumen de la Inspección (Figura 15) Fig. 15. Resumen de la inspección Muestreo: Los atributos que se utilizarán corresponderán a una muestra de todos los atributos abarcados en la implementación de un sistema. Alta correlación positiva. Los atributos elegidos tendrán que mostrar una alta correlación positiva en el pasado con cualquier éxito o fracaso durante la automatización de una aplicación. Estos atributos no deberían ser intuitivos sino, que deberán ser atributos para los cuales pueda demostrarse que la ausencia o presencia de los mismos muestre una alta correlación con respecto al resultado final del proyecto. Facilidad de uso. Para ser efectivo, el proceso de ranking debe ser lo más 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 aplicación. Esto indicaría el grado de riesgo, el área de riesgo, y también una comparación de riesgos entre las diferentes aplicaciones. Al ranking de riesgo se llega a través de un desarrollo matemático, como se muestra a continuación. TABLA XVI. DESARROLLO MATEMÁTICO PARA OBTENER UN RANKING DE RIESGO RIESGO DE LA CARACTERÍSTICA # DE CARACTERÍSTICAS EVALUADAS FACTOR DE MULTIPLICACIÓN FACTOR PARA EL RANKING Alta Media Fig. 14. Informe de inspección F. Ranking de Factores de Éxito (Módulo de Diseño) El ranking ( scoring ) es una herramienta predictiva que utiliza experiencias en sistemas anteriores. Se analizan los sistemas existentes para determinar los atributos o características de los mismos y su correlación con el éxito o el fracaso de cada aplicación en particular. Una vez que los atributos correlacionados al éxito o al fracaso pueden ser identificados, también 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 continuación: Baja Total 39 Para usar esta tabla, el número de atributos o características calificadas con alto, medio y bajo, deberá ser totalizado, y los totales colocados en la columna # (cantidad) de Características Evaluadas. Luego a cada número se lo multiplica por el factor de multiplicación y así obtener el ranking de riesgo. Por ejemplo, el número total de características definidas con alto riesgo debe multiplicarse por tres. Luego los tres números se suman para llegar a totalizar el riesgo total, el cual puede utilizarse para comparar entre los diferentes sistemas, o bien, respecto de un estándar definido por la organización. cuanto más alto es el puntaje, mayor será el riesgo, y a menor puntaje menor riesgo. 196 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

47 G. Análisis de Factores (Módulo de Diseño) Los factores que deben analizarse durante el módulo de diseño se describen a continuación: G.1. Controles de Integridad de Datos La integridad de datos va desde la identificación de riesgos, hasta la decisión gerencial de aceptar esos riesgos, establecida en términos de la cantidad de pérdidas aceptables. Los controles de integridad de datos se diseñan a partir de la tolerancia a tales riesgos, los cuales se encuentran especificados. G.2. Reglas de Autorización Las autorizaciones en los sistemas pueden ser manuales y/o automáticas. Los procedimientos para autorización manual deben especificarse durante la fase de diseño. Los métodos de autorización automática deben especificarse más detalladamente que los manuales, por el hecho de que no se pueden dejar librados a criterios personales según la situación que se presente. G.3. Controles de Integridad de Archivos La integridad de los archivos estará asegurada por los métodos de identificación de archivos, controles automáticos y controles de integridad de archivos mantenidos independientemente. Las especificaciones para este proceso integrador de tres partes debe determinarse durante la fase de diseño. G.4. Pistas de Auditoria Estas pistas proveen la capacidad para rastrear transacciones desde su origen hasta los controles. Además, las pistas de auditoria se usan para consolidar el procesamiento de transacciones individuales y recuperar la integridad de operaciones luego de su pérdida. Frecuentemente los entes gubernamentales especifican las pistas de auditoria que necesitan retener para cada tipo de información que manipulan. Estas necesidades de información, deben definirse durante la fase de diseño. G.5. Plan de Contingencias El plan de contingencias esquematiza las acciones a tomar ante la aparición de problemas. Este plan deberá incluir los métodos manuales a seguir cuando las aplicaciones automatizadas no estuvieran en operación, así como también, las consideraciones de lugar físico. Las especificaciones del plan de contingencia deben llevarse a cabo durante la fase de diseño. G.6. Método para Alcanzar el Nivel de Servicio Requerido La fase de requerimientos define el nivel de servicio a obtener durante la operación de la aplicación. El método para alcanzar ese nivel de servicio es desarrollado durante la fase de diseño. Esto involucra el desempeño 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 quién puede tener acceso a qué recursos y para hacer qué. Esto estará indicado por los perfiles de seguridad definidos. Durante la fase de diseño, deberán desarrollarse los procedimientos, las herramientas y las técnicas necesarias para crear e implementar los perfiles de seguridad necesarios. G.8. Diseño Acorde con la Metodología El proceso de diseño de sistemas debe ejecutarse y documentarse de acuerdo con la metodología establecida por la organización. Los procedimientos estándares de diseño aseguran la facilidad de comprensión por todos los miembros del equipo capacitados y entrenados en esa metodología y al mismo tiempo ayuda a asegurar que se cumpla en forma completa el proceso de diseño. G.9. Diseño Acorde con los Requerimientos El diseño del sistema es una transformación de los requerimientos de los usuarios en especificaciones más detalladas. Durante cualquier transformación, pueden ocurrir malos entendidos o malas interpretaciones. Entonces, deben tomarse las medidas necesarias para asegurar que el diseño cumpla sus objetivos y esté focalizado a cumplir con los requerimientos definidos. G.10. Facilidad de Uso Cuanto el producto final sea más fácil 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 motivación en el mismo, de todas las personas usuarias del sistema. G.11. Mantenibilidad del Diseño El costo de mantener una aplicación normalmente excede el costo de desarrollo. Identificar aquellos aspectos del sistema que son los más factibles de cambiar y construir aquellas partes del sistema para facilidad del mantenimiento es un aspecto importante del proceso de diseño. La mantenibilidad del diseño puede cambiar significativamente dependiendo de la frecuencia esperada de los cambios introducidos. G.12. Portabilidad del Diseño Si los requerimientos indican que el sistema debe poder ser transferido desde un ambiente de hardware a otro, o una versión de software de base a otra, el diseño debe tener en cuenta e incorporar estos aspectos de portabilidad. Cuando el hardware y software futuros son inciertos, el diseño debe ser lo más general posible y no intentar sacar ventaja de los aspectos o facilidades que brindan el hardware y software existentes. G.13. Interfaces de Diseño Deben ser identificadas y especificadas y documentadas las interfaces con otras aplicaciones. Las especificaciones de las interfaces deben también considerar usos alternativos de la información de la aplicación. G.14. Diseño Acorde con Criterios Establecidos El estudio de costo/beneficio realizado durante la fase de requerimientos no provee una estimación de gran precisión. La estimación de la fase de requerimientos puede estar afectada en más o menos el 50%. Durante la fase de diseño, la estimación del desempeño puede ser definida mejor por lo que se puede hacer una mejor predicción y así lograr el cumplimiento del criterio de desempeño establecido. Una guía útil a ser utilizada, es que la precisión de la estimación del criterio de desempeño al final de la fase de diseño puede variar en ±10%. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

48 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 más grandes sean los requerimientos de procesamiento, mayor será la necesidad de involucrar al sector de operaciones en la consideración de las alternativas de diseño. H. Revisión del Diseño El objetivo es identificar aquellos atributos del diseño que se correlacionan con los problemas del sistema. Entonces durante la revisión de diseño, se investigarán dichos atributos para determinar si el equipo de proyecto los ha tratado apropiadamente. El equipo de revisión de diseño comprende los siguientes miembros: Personal del proyecto: El personal del proyecto puede conducir su propia revisión del diseño. Normalmente la persona asignada con la responsabilidad de la revisión del proyecto no es la misma que realmente diseñó el sistema; sin embargo el que revisa puede tener responsabilidad parcial en el diseño. Esto requiere que las personas durante el proceso de revisión acepten roles y responsabilidades diferentes a los que han tenido en el proceso de diseño. Debido a probables vínculos con el diseño real del sistema, tener una lista de verificación de revisión de diseño como herramienta evaluadora, normalmente cumple una valiosa función para el/los que revisan. Equipo de revisión independiente: Los miembros de este equipo de revisión 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 revisión ya que no habrá conflicto de intereses entre los roles de diseñador y del que revisa. Por otro lado es frecuentemente difícil para los inspectores ser críticos unos con otros, especialmente en situaciones donde el que revisa pueda eventualmente trabajar para la persona que está siendo revisada. La siguiente es una guía en la conducción de una revisión de diseño: Seleccionar el equipo de revisión: Los miembros del equipo de revisión deben seleccionarse antes del proceso de revisión propiamente dicho. Entrenar los miembros del equipo de revisión: Las personas que conducirán la revisión deben estar entrenadas sobre cómo dirigir la revisión. Mínimamente significa revisar el checklist y explicar el objetivo e intención de cada asunto. También es aconsejable entrenar a las personas involucradas en relaciones interpersonales y así realizar la revisión en un ambiente armonioso. Notificar al equipo del proyecto: El equipo del proyecto debe estar notificado de la revisión con varios días de antelación cuando comienza la revisión y su responsabilidad durante la misma. Es importante organizar formalmente la revisión para que estén todos presentes. Asignar tiempos adecuados: La revisión debe conducirse formalmente y tan eficientemente como sea posible. Aún cuando la misma gente que diseñó la revisión, la dirija, las relaciones interpersonales y los efectos de la sinergia de la revisión pueden producir muchos efectos positivos si se asigna el tiempo suficiente para permitir una interacción apropiada. Documentar los datos de la revisión: Deben registrarse todos los hallazgos realizados en la revisión. 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 específicas del checklist que cubrían. Revisar los datos con el equipo de proyecto: La precisión de los datos debe ser comprobada por todas las personas involucradas, y la revisión no debe continuar si esto no está hecho. Es mejor hacerlo al final de la revisión que durante el proceso mismo. Desarrollar recomendaciones de revisión: Basándose en los datos, el equipo de revisión hará sus recomendaciones para corregir cualquier situación de conflicto. Estas recomendaciones son parte importante del proceso de revisión. 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 revisión por la organización. Sin embargo es importante tener un registro formal del proceso de revisión, 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 diseño. Así podrán llevarse a cabo revisiones del diseño de alto nivel y del diseño detallado. H.1. Revisión del Diseño de Alto Nivel Cada defecto descubierto durante la revisión del diseño lógico o de alto nivel debe documentarse. Se confecciona un reporte de defectos para llevar registro de los mismos, incluyendo tipo y categoría de los defectos. La descripción de cada defecto se registra bajo una columna de Faltante, Erróneo o Adicional. Al final de la revisión del diseño lógico, los defectos se resumen y totalizan. En la figura 16 se muestra un formulario de registro de defectos en la fase de diseño de alto nivel: Fig. 16. Formulario de registro de defectos en la fase de diseño de alto nivel 198 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

49 H.2. Revisión del Diseño Detallado Cada defecto descubierto durante la revisión del diseño físico o detallado debe documentarse. Se confecciona un reporte de defectos para llevar registro de los mismos, incluyendo tipo y categoría de los defectos. La descripción de cada defecto se registra bajo una columna de Faltante, Erróneo o Adicional. Al final de la revisión del diseño físico, los defectos se resumen y totalizan. En la figura 17 se muestra un formulario de registro de defectos en la fase de diseño detallado: Fig. 17. Formulario de registro de defectos en la fase de diseño detallado I. Depuración de Programas La depuración ( debugging ) permite al programador evaluar la integridad y precisión del programa previo a la conducción de revisiones y verificaciones menos económicas. La depuración, incluye el diseño detallado y la codificación. Esta operación 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 implementación. Recursos de prueba Eficiencia de herramientas de test. Políticas del área. La depuración puede ser sintáctica, estructural, o funcional. I.1. Depuración Sintáctica Las especificaciones y expresiones del programa deben desarrollarse de acuerdo con la metodología definida por la organización 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 función a realizar, está claramente identificada? Las sentencias del programa están identificadas correctamente? Las sentencias del programa están construidas utilizando la estructura apropiada? Los elementos de datos están apropiadamente identificados? Las estructuras de datos son las adecuadas para colocar los valores que serán utilizados en dichas estructuras? I.2. Depuración Estructural Los problemas de estructura crean un significante número de defectos en la mayoría de las aplicaciones. Estos defectos ocultan defectos funcionales por lo que su detección se torna difícil. Las preguntas típicas durante la depuración 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 límite están usados de manera que cuando se excede el límite se puede continuar procesando? Depuración Funcional Las funciones son los requerimientos que el programa ejecutará. Las preguntas cuando se depura la funcionalidad son: El programa ejecutará la función específica en la forma indicada? Algunas de las funciones son mutuamente excluyentes? El sistema detectará datos incorrectos o ilógicos? Se acumulará apropiadamente la información entre diferentes ejecuciones del programa? J. Análisis de Factores (Módulo de Codificación) La profundidad de la verificación en el módulo de codificación, depende de cómo se adecua el sistema a las necesidades del usuario, al final del módulo de diseño. A mayor confianza del equipo de verificación en la adecuación de la aplicación al final del módulo de diseño, tendrán menos inquietudes durante el módulo de codificación. En el módulo de codificación, el equipo de aseguramiento de la calidad debe identificar las inquietudes que sean de mayor interés, y luego desarrollar el proceso de verificación 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 verificación. Los objetivos que los miembros del equipo de aseguramiento de la calidad deben considerar en el módulo de codificación, son: Los sistemas son mantenibles? Se han implementado correctamente las especificaciones del sistema? Los programas son compatibles con los estándares y procedimientos? Existe un plan de verificación capaz de evaluar los ejecutables? Los programas están adecuadamente documentados? Las inquietudes ( concerns ) a considerar durante esta tarea se describen a continuación: Implementación del control de integridad de información: Es necesario tener implementados controles específicos de manera de lograr la precisión en el procesamiento deseado. Los controles implementados en forma impropia, no alcanzarán el nivel de tolerancia aceptado, y por la mala comprensión del propósito de los controles, serán implementadas soluciones simplistas cuando en realidad se Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

50 requieren controles complejos para alcanzar los objetivos de control establecidos previamente. Implementación de reglas de autorización: Es necesario verificar la implementación de reglas de autorización de manera de dificultar su evasión. Además, las reglas de autorización no deben sólo considerar la ejecución de las reglas si no también tener en cuenta los métodos más comunes de evadirlas. Implementación de controles de integridad de archivos: Los controles de integridad de archivos deben implementarse de manera que minimicen la probabilidad de pérdida la integridad, debiendo además prevenirla y detectarla oportunamente. Implementación de auditorías de rastreo: Es necesario implementar una verificación de las auditorias para facilitar la recuperación de información de las mismas (rastreo). Si la verificación de la auditoria contiene información costosa o demanda mucho tiempo, su valor disminuye significativamente. Las consideraciones de la implementación incluyen la cantidad de información a recuperar seguida de la facilidad de recuperación, referencias cruzadas de información para la recuperación y el tiempo que la información 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 estén disponibles cuando sea necesario activarse. Abordar el diseño de la contingencia es de poco valor si no se documenta o no estará en manos de la gente que lo utilizará. Consecución del nivel de servicio deseado para el sistema: El nivel de servicio deseado puede solo hacerse realidad cuando los procedimientos y métodos estén implementados. Uno de los procedimientos que debe establecerse, es el monitoreo del nivel de servicio para asegurarse que cumple con las especificaciones. La inclusión 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. Implementación de procedimientos de seguridad: La seguridad es la combinación de previsión y entrenamiento, más herramientas y técnicas de seguridad. Los procedimientos que aseguran que tanto las herramientas como las técnicas de seguridad estén disponibles y que trabajen juntas, deben desarrollarse durante la fase de codificación. Cumplimiento del programa con la metodología a adoptar: Los procedimientos a implementar deben asegurar conformidad con estándares, políticas, procedimientos y métodos definidos por la organización. Si se detecta la no conformidad, se deberían tomar las medidas necesarias para modificar el diseño y así lograr la conformidad. Programas acordes al diseño (Correctitud): El cambio continuo de condiciones puede provocar que varios miembros del personal del proyecto, ignoren los objetivos del mismo durante la fase de codificación. 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 implementación de dichos objetivos. Si no se han alcanzado los mismos, o deben cambiarse, o bien, debe cambiarse el sistema para tratar de ajustarlos a las especificaciones funcionales ya realizadas de la aplicación. Programas acordes al diseño (Facilidad de uso): La implementación de especificaciones del sistema puede invalidar algunas de los aspectos del diseño respecto de la facilidad de uso, a menos que los mismos se encuentren definidos específicamente. La programación es la traducción de especificaciones de diseño a lenguaje ejecutable por la máquina. Esto puede entorpecer el logro de la facilidad de uso. La codificación 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 método de codificación puede significar más para el mantenimiento que las especificaciones de diseño mismas. Las reglas de mantenimiento deben definirse en parte por los estándares y en parte por las especificaciones del sistema. Además, el programador debe utilizar su juicio y experiencia para desarrollar código altamente mantenible. Programas acordes al diseño (Portabilidad): La portabilidad de los programas depende del lenguaje seleccionado y de cómo se usa ese lenguaje. Las especificaciones deben indicar lo que se hace y no se hace en la programación para lograr su portabilidad, y la codificación debe apegarse a esas especificaciones de diseño. Si la portabilidad es una preocupación importante y las especificaciones del programa fallan al definir adecuadamente la portabilidad de la codificación, la misma quedará en manos del programador. Programas acordes al diseño (Acoplamiento): Las especificaciones de diseño deben indicar parámetros a pasar desde y hacia otros módulos y aplicaciones del sistema. Normalmente es una buena práctica del programador, verificar que las especificaciones del sistema estén actualizadas antes que las funciones sean codificadas. Esto no solo asegura que el programa se ajusta al diseño, sino también, que las especificaciones de interconexión entre aplicaciones no se han modificado desde que se documentó el diseño. Desarrollo de procedimientos operativos: Los procedimientos deben desarrollarse durante la fase de programación, de forma de poder operar la aplicación. Durante la fase siguiente, los programas ejecutables serán operados. Los procedimientos operativos deben ser consistentes con los requerimientos operacionales definidos para la aplicación. Alcance de los criterios de performance por parte de los programas: La creación del programa provee la primer oportunidad para los usuarios de evaluar si el sistema puede lograr el nivel rendimiento deseado. Una evaluación temprana del rendimiento, brindará una buena oportunidad para hacer ajustes si es necesario. K. Revisiones por Pares La revisión por pares contribuye a construir el código de un programa a través de revisiones informales, pero sin embargo efectivas, acerca de la funcionalidad del programa. Este tipo de revisión provee un análisis estático que evalúa la estructura y funcionalidad del programa. Puede detectar errores sintácticos en mayor medida que una simple observación visual, como resultado de un recorrido (walktrhough) de requerimientos. 200 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

51 La revisión por pares también puede ser formal. Las formales son tareas integrales en el proceso de programación, mientras que las informales son solicitadas a discreción del líder de programación. Además puede aplicarse a otros productos, no sólo al código de un programa. El equipo de revisión 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 serán: Programadores (por lo menos dos). Especialistas en JCL ( Job Control Language ) o similar. Operadores. Líderes de programación. El programa de revisiones por pares se realiza ejecutando las siguientes tareas: K.1. Establecer Reglas Básicas para la Revisión Esto no es necesario para cada revisión pero es importante tener buenas reglas de base. Entre dichas reglas, están: Áreas incluidas y excluidas de la revisión por pares. Por ejemplo: Ver si la eficiencia de los programas será incluida. Cuándo se usarán reportes. Método para seleccionar el líder de la revisión por pares. Ubicación de la conducción de la revisión. Método para seleccionar productos a ser revisados por pares. K.2. Seleccionar al Equipo de Revisión Los integrantes del equipo deben ser seleccionados con la suficiente antelación, de manera que puedan organizar su tiempo y estar entrenados para la revisión. K.3. Entrenar a los Miembros del Equipo Si una persona del equipo no ha participado previamente en el programa de revisión por pares, se la debe entrenar en el proceso. El entrenamiento incluye el entendimiento de las reglas básicas de esta revisión, preferentemente algún entrenamiento en relaciones interpersonales acerca de cómo entrevistar y trabajar con gente en el proceso de la revisión, y entrenamiento en los estándares y metodología de programación. K.4. Seleccionar el Método de Revisión El líder del equipo debe seleccionar el método de revisión. La revisión en sí misma consiste en dos partes. La primera es una explicación general de los objetivos y funcionamiento del programa. La segunda parte es la revisión de los programas utilizando el método seleccionado. Los métodos que pueden ser utilizados para conducir la revisión por pares son cuatro: Diagrama de flujo: El programa se explica desde un diagrama de flujo. Esto es más efectivo cuando el diagrama de flujo es producido directamente desde el código fuente. Código fuente: La revisión examina cada línea del código fuente para entender el programa. Muestra de transacciones: El líder de programación explica los programas exponiendo los procesamientos típicos 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. K.5. Conducir la Revisión El líder de programación del proyecto normalmente inspecciona la revisión por pares. La revisión comienza habiendo hecho el líder de programación, una revisión rápida de las reglas básicas, explicado los objetivos, y luego conduce al equipo a revisar el procesamiento del programa. El equipo de revisión será libre de preguntar y comentar sobre cualquier aspecto de la explicación del programador y de hacer recomendaciones y sugerencias acerca del programa. Generalmente, la revisión por pares es dirigida en forma democrática. El rol del líder 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 específico si, en la opinión del líder de inspección, no tiene sentido continuar discutiendo. K.6. Conclusiones Al final de la revisión por pares, el líder de programación indicará cuándo no tiene más comentarios que hacer y lo deja en manos del líder del equipo de revisión por pares. El líder del equipo de revisión por pares, toma el control y resume la información bosquejada de la revisión y presenta las recomendaciones del equipo de revisión. Idealmente, esto se hace como actividad grupal, pero algunos equipos de revisión por pares, especialmente cuando el proceso se formaliza, puede querer algún 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 consideración. K.7. Reportes En el proceso de la revisión por pares, se prepara el reporte documentando los resultados. Sin embargo, esto es opcional y no es una parte esencial del proceso de revisión por pares. El formato de los informes típicos será similar al que ya se han detallado con anterioridad: Informe de Inspección Resumen de la Inspección L. Verificación de Documentación L.1. Integridad de la Documentación Los criterios principales para la verificación de la integridad de la documentación, surgirán de la metodología y estándares de la organización. A continuación, se detallan criterios adicionales para verificar la integridad de la documentación: Contenido de la documentación: Al índice de cada documento le debería seguir una breve descripción de cada elemento dentro del documento. Cada documento debe tener un índice de contenidos mínimos obligatorios, para poder determinar si los documentos contienen toda la información necesaria. Si faltan elementos, hay un defecto potencial en la integridad de la documentación, la cual debería 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 usarán el documento para ejecutar una función. (Por ejemplo, operación, mantenimiento, diseño y programación). Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

52 La información deberá ser presentada con la terminología y el nivel de detalles apropiados para el tipo de usuario al cual está dirigido el documento. Redundancia: Los documentos típicos dentro del proyecto (Ej. Especificación de Requerimientos, Análisis de Factibilidad, etc.) tendrán alguna redundancia. Se deberá incluir material introductorio en cada tipo de documento para proveer al lector de un marco de referencia, facilitando la interpretación del documento con la menor cantidad de referencias cruzadas hacia otros documentos. La información que debería ser incluida en cada tipo de documento diferirá en su contexto y a veces en la terminología y nivel de detalle, porque intenta ser leído 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 organización. Tamaño del documento: Cada tipo de documento puede tener un tamaño que va de unas pocas a varias decenas de hojas. La longitud depende del tamaño 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. Combinación de diferentes tipos de documentos: En ocasiones, es necesario combinar algunos tipos de documentos bajo una sola portada o producir algunos volúmenes 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 módulo. Algunas veces el tamaño del documento puede requerir ser repartido en varios volúmenes para hacer más fácil su uso. En esos casos, deberán 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 párrafos 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 presentación, caso contrario, debería ajustarse a los estándares ya definidos por la organización. Títulos de secciones/párrafos. Estos títulos generalmente son los mismos que los mostrados en la índice de contenidos. Pueden modificarse para reflejar la terminología del software a documentar si el significado le agrega valor a la presentación. Se pueden agregar o eliminar secciones o párrafos según sea necesario. Expansión de los párrafos: La mayoría de los tipos de documentos definidos por la metodología, estándares o lineamientos de la organización tienen párrafos con un título general y una lista de puntos que pueden discutirse dentro de ese párrafo. La intención de esa lista no es establecer la discusión de cada uno de estos puntos, sino sugerir la consideración de los mismos al escribir el párrafo. Este y todos los otros párrafos pueden expandirse y subdividirse para llevar a cabo una mejor presentación de la información. Diagramas de flujo y tablas de decisión: Los gráficos de las soluciones a problemas en forma de diagramas de flujo o tablas de decisión, pueden estar incluidos o ser un apéndice del documento. Formularios: El uso de formularios específicos depende de las prácticas de la organización. Parte de la información especificada en los párrafos del índice de contenidos puede registrarse en tales formularios. Si es así, el formulario puede referenciarse desde el párrafo apropiado. Se requiere usar los formularios que conforman los estándares de la organización. L.2. Grado de actualización de la Documentación El equipo de verificación de la documentación puede usar cualquiera de las siguientes cuatro verificaciones propuestas para validar la actualización de la documentación. Los tipos de verificación posibles se enumeran a continuación: L.2.1. Utilizar la Documentación Vigente La actualización puede validarse utilizando la documentación vigente para realizar algún cambio en la aplicación. Esto permite al analista de calidad buscar y confirmar la consistencia entre varios documentos (por ejemplo, que las especificaciones en el documento de diseño del programa, sean las mismas que están en el código actual) y determinar si la documentación respalda el funcionamiento del sistema. L.2.2. Comparar el Código Fuente con la Documentación Esta verificación usa la versión actual del código fuente de uno o más programas como base de la documentación. Esta verificación 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 documentación. El objetivo es determinar si el código es representativo de la documentación que se posee del mismo. L.2.3. Verificar la Vigencia de la Documentación Las personas que elaboran la documentación deben verificar que esté vigente. Deben hacerse preguntas específicas, como éstas: La documentación es 100% representativa de la aplicación en operación? La documentación cambia cada vez que se hace un cambio en el sistema? Los individuos que cambian el sistema confían en que la documentación es la correcta? L.2.4. Verificar la Actualización de la Documentación con el Usuario Los usuarios finales deben preguntarse si la documentación para el sistema está actualizada. Si los usuarios finales no están familiarizados con la documentación, necesitarán que se seleccione una muestra pidiendo piezas específicas de la documentación. La documentación seleccionada debe ser familiar para el usuario final de manera que se les pueda dar partes representativas del documento y pedir que validen si están actualizadas o no. VI. NIVEL DE SERVICIO ESPERADO En el presente capítulo se describe el Nivel de Servicio Esperado, a través de la cuantificación de los resultados esperados. A. Generalidades A.1. Necesidad de cuantificación Toda aplicación de un modelo o servicio, requiere de ciertos niveles de servicio o indicadores que permitan obtener una 202 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

53 cuantificación de los resultados de la aplicación del mismo y/o establecer las expectativas para aplicaciones futuras. Para ello, se describen cuatro indicadores. Los indicadores aquí presentados, tanto su definición como el valor objetivo sugerido, constituyen sólo una muestra no estática del tipo de indicadores que habría que considerar; es decir se pueden agregar nuevos y/o modificar los aquí presentados, conforme a la capacidad de la organización y a la experiencia en la aplicación del modelo. A.2. Definición de términos Con el objeto de clarificar diferentes términos que se suelen confundir o usar indistintamente y para precisar los acuerdos de nivel de servicio, se presenta a continuación las siguientes definiciones, propuesta en [6]: Errores: Estos son equivocaciones humanas como los errores tipográficos o sintácticos. 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 documentación. 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 están latentes pero nunca se encuentran). Los defectos pueden encontrarse muchas veces, dando como resultado múltiples bugs por defecto. Fallas: Es un mal funcionamiento en una instalación de usuario. Puede ser provocado por un bug, una instalación incorrecta, una falla del hardware, etc. Problemas: Son dificultades encontradas por los usuarios. Pueden provenir de fallas, mal uso o mal entendimiento. Los problemas son eventos relacionados con los humanos, contrariamente a las fallas que son eventos relacionados con el sistema. Entradas Unitarias: Corresponde a cada uno de los elementos del conjunto que componen la entrada a cada uno de los módulos 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. DEFINICIÓN DE TÉRMINOS Categoría Ítems medidos Causas Errores Acciones humanas Equivocaciones del programador Defectos Propiedades del programa Errores Bugs Mal funcionamiento del programa Defectos del programa Fallas Mal funcionamiento del sistema Bugs y otros mal funcionamientos Problemas Percepciones humanas Fallas, errores humanos, incomprensión humana En la figura 18 se muestran las relaciones entre las categorías de la tabla anterior. Este diagrama tiene una doble utilidad: Comenzando con el problema se pueden rastrear las posibles causas. B. Indicadores B.1. Indicador A El indicador A establece el nivel tiempo promedio en que debe poder adaptarse el plan general de aseguramiento de la calidad a un proyecto en particular. El esquema correspondiente al indicador A se muestra en la figura 19. Fig. 18. Proceso del módulo de metodología, estándares y procedimientos Descripción: Tiempo promedio insumido en la generación del plan específico de aseguramiento de la calidad para un proyecto dado. Valor objetivo sugerido: Menor o igual a 1 semana. Fig. 19. Tiempo promedio en que se debe adaptar el plan general al proyecto en particular B.2. Indicador B El indicador B establece el nivel de la capacidad de trabajo concurrente del equipo de SQA en su conjunto. El esquema correspondiente al indicador B se muestra en la figura 20. Descripción: Capacidad máxima de entradas unitarias en proceso de verificación concurrente. Valor objetivo sugerido: Hasta 10 entradas unitarias. Comenzando con el error del programador, se puede rastrear en el diagrama hasta llegar al problema. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

54 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. Descripción: Tiempo máximo promedio de verificación para una entrada unitaria. Valor objetivo sugerido: Menor o igual a 1 semana. 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, podría ser asignado a un proyecto en particular, mientras que, el Líder de SQA de la organización, tiene el control sobre los sub-equipos y mantiene una visión general que comprende a todos los proyectos de dicha organización. 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. Descripción: 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 después de su puesta en producción). Valor objetivo sugerido: 75% de los defectos Fig. 22. Nivel de eficacia del trabajo de SQA VII. EQUIPO DE SQA En el presente capítulo 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 características particulares de la organización en la cual el equipo se desempeña. En el presente trabajo se presentará una estructura en tres niveles, muy común en varias organizaciones. En la figura 23 se esquematiza esta estructura: B. Responsabilidades del equipo A continuación de describe, sólo a modo de ilustrativo, las principales responsabilidades de cada uno de los perfiles establecidos en la estructura de la figura 23. B.1. Líder de SQA Mantenimiento del dialogo primario con los referentes del área de desarrollo. Administración del presupuesto de los proyectos para la función de SQA. Responsable de asegurar al equipo de trabajo los elementos que éste o cualquiera de sus integrantes necesite. Coordinación de las necesidades políticas de los proyectos con las capacidades operativas disponibles. Coordinación de responsabilidades entre los analistas de SQA de los distintos proyectos. Mantenimiento de la conducción de todo el equipo de SQA. Determinación de los objetivos de SQA, para etapa de un proyecto y control de su cumplimiento. Elaboración periódica de informes de avance y seguimiento. Participación en reuniones técnicas, siempre que resulte necesario. Participación en los módulos que se indica en el modelo de aseguramiento de la calidad propuesto. Supervisión (directa o indirecta) de los analistas de SQA. Evaluación 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. Aplicación de la metodología de aseguramiento de la calidad para los proyectos asignados. Aseguramiento del cumplimiento de los objetivos fijados por el líder de SQA. Aseguramiento del cumplimiento de la metodología de trabajo fijada. 204 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

55 Participación en los módulos que se indica en el modelo de aseguramiento de la calidad propuesto. Conducción y administración del equipo asignado a su cargo. Asignación de tareas a los analistas de SQA Semi-senior. Supervisión de las tareas de los analistas de SQA Semi-senior que le correspondan en cada proyecto. Elaboración periódica de informes de gestión de su equipo. Elaboración de informes por excepción cada vez que resulte necesario. Comunicación inmediata en situaciones que excedan su capacidad de control o decisión. Responsable primario de la disciplina y cumplimiento de su equipo. Colaboración técnica con el Líder de SQA en las reuniones o consultas que éste requiera. Asesoramiento al Líder de SQA en toda cuestión técnica vinculada a su área de influencia. B.3. Analista de SQA Semi-senior Participa en los módulos que se indica en el modelo de aseguramiento de la calidad propuesto. Cumplimiento detallado con la metodología de trabajo impuesta y con las pautas que le fijen sus supervisores. Elaboración de informes detallados de cada unidad de análisis. Elaboración de informes por excepción cada vez que resulte necesario. Comunicación inmediata en situaciones que excedan su capacidad de control o decisión. Colaboración técnica con el Analista de SQA Senior en las reuniones o consultas que éste requiera. VIII. CONCLUSIONES En el presente capítulo se establecen las Conclusiones obtenidas al concluir el presente trabajo, señalando los beneficios y problemas esperados en la aplicación de la función de SQA en una organización. También se establecen las bases para un análisis costo-beneficio. A. Beneficios y problemas Aunque pocos profesionales pondrían en duda la necesidad de calidad en el software, muchos no están interesados en establecer funciones de SQA formales. Las principales razones de esta aparente contradicción 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 están haciendo todo lo que hay que hacer con respecto al aseguramiento de la calidad. Pocos saben dónde situar esa función dentro de la organización. Todos quieren evitar cierto nivel de burocracia que la función de SQA tiende a introducir en el proceso de ingeniería del software o de conocimiento. En el presente trabajo, se ha presentado un enfoque práctico para la aplicación de la función de aseguramiento de la calidad del software en una organización, que intenta echar luz sobre las razones ya enunciadas que impiden la aplicación de la dicha función. Aunque instanciada en la metodología IDEAL, este enfoque es independiente de la metodología de desarrollo que esa organización utilice. La independencia del enfoque con respecto a metodología utilizada por la organización, se debe a qué el enfoque presentado es general, aplicable a fases comunes de cualquier metodología y a que no obliga a su aplicación rígida, sino que permite su adaptación a esa metodología y a la propia realidad de la organización. Asimismo, el enfoque presentado constituye un complemento no disruptivo de la metodología de desarrollo que ya utiliza una organización y no obliga a profundos cambios en la misma. Por el contrario, si la organización no utiliza una metodología, incentiva la utilización de una. Algunos de los principales beneficios esperados de la aplicación constante y rigurosa de la función 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 satisfacción del cliente. Se podrán 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 función de SQA podría resultar problemática por las siguientes razones: Es difícil institucionalizar en organizaciones pequeñas, en las que no están disponibles los recursos necesarios para llevar a cabo esas actividades. Representa un cambio cultural, y el cambio nunca es fácil. Requiere un gasto que, de otro modo, nunca se hubiera destinado explícitamente a la ingeniería del software o de conocimiento o al aseguramiento de la calidad. B. Evaluación costo-beneficio A la hora de establecer la función de aseguramiento de la calidad del software en una organización, es razonable preguntarse si valdrá la pena, si el costo de su establecimiento y aplicación continua se verá justificado por los beneficios alcanzados. En el marco de un análisis básico de costo-beneficio, se puede afirmar que la función de SQA en una organización será efectiva si se cumple con la siguiente: A > B + C siendo: A: Costo de las fallas que aparecen sin la aplicación de la función de SQA. Esto incluye, entre otros, las actividades de reparación y re-trabajo, resolución 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 aplicación de la función de SQA. Esto incluye, entre otros, los salarios del equipo de SQA y las actividades de planificación, revisiones y auditorias. C: Costo de las fallas que no se encuentran con la aplicación de la función de SQA. Esto incluye los mismos puntos que A, pero deberían ser dramáticamente inferiores. Sin embargo, es importante resaltar que en un análisis más minucioso habría que considerar también otros aspectos, tales como: Reducciones en los costos de las pruebas y de la integración. Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

56 Reducción del número de cambios en las primeras versiones. Reducción en los costos de mantenimiento. y otros de no tan fácil cuantificación, tales como: Mejora en satisfacción del cliente. Mejora en la imagen de la imagen externa de la organización. Mejora en la imagen interna del equipo de ingeniería del software o de conocimiento. Finalmente, también es necesario tener en cuenta al momento de hacer un análisis costo-beneficio, que la función de SQA no necesariamente está circunscripta al ámbito de la ingeniería del software o de conocimiento, sino que evoluciona como parte de un esfuerzo general de gestión en la organización, dirigido a mejorar la calidad. A ese esfuerzo general de gestión dentro de la organización se lo suele denominar gestión de la calidad total. IX. BIBLIOGRAFÍA [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. 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 Ingeniería de Software en la Licenciatura en Sistemas (Res. CONEAU 1089/12) del Departamento de Desarrollo Productivo y Tecnológico de la Universidad Nacional de Lanús y Profesor Adjunto Regular del Área de Ingeniería de Software en la Carrera de Ingeniería Informática de la Facultad de Ingeniería de la Universidad de Buenos Aires. Es Profesor de la Maestría en Ingeniería de Software (Acreditada por Resolución CONEAU nro 239/04) en el marco del Convenio Universidad Politécnica de Madrid - ITBA y Profesor de Posgrado en la Maestría en Ingenieria de Sistemas de Información en la Escuela de Posgrado de la Facultad Regional Buenos Aires de la Universidad Tecnológica Nacional. Es Investigador del Grupo de Investigación en Sistemas de Información y dirige del Laboratorio de Investigación y Desarrollo en Aseguramiento de Calidad de Software de la Licenciatura en Sistemas y de la Maestria en Sistemas de Información del Departamento de Desarrollo Productivo y Tecnológico de la Universidad Nacional de Lanús. Su areas de interes en investigación 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 Explotación de Información. Es Analista de Sistemas y Licenciado en Sistemas por la Universidad de Belgrano. Es Especialista en Ingeniería de Sistemas Expertos y Magister en Ingeniería de Software por el Instituto Tecnológico de Buenos Aires y por la Facultad de Informática de la Universidad Politécnica de Madrid. 206 Eduardo Diez Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el Conocimiento: Un Enfoque Práctico Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

57 Estudio Comparativo de Plataformas Cloud Computing para Arquitecturas SOA Franco Bocchio 1,2 1. Programa de Maestría en Ingeniería de Sistemas de Información. Escuela de Posgrado, Facultad Regional de Buenos Aires. Universidad Tecnológica Nacional. Argentina. 2. Laboratorio de Investigación y Desarrollo en Arquitecturas Complejas. Grupo de Investigación en Sistemas de Información. Universidad Nacional de Lanús. Argentina. franco.bocchio.ar@member.mensa.org Resumen Las plataformas Cloud Computing están fundadas en un paradigma tecnológico moderno que ofrece nuevas alternativas a empresas de diversas envergaduras para implementar modelos de negocios innovadores. Con estos nuevos modelos de negocio las empresas pequeñas pueden hacer uso de las plataformas Cloud Computing disponiendo de la posibilidad de incrementar, tanto progresiva como abruptamente, su capacidad de cómputo y almacenamiento de datos en función de las necesidades y en tiempo real, implicando una oportunidad singular para la competencia de mercado. En adición, las arquitecturas orientadas a servicios otorgan características de grandes beneficios para los sistemas modernos, permitiendo altos niveles de reutilización 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 arquitectónicos SOA que de las plataformas antedichas se desprenden con el objetivo de encontrar similitudes y diferencias, así como también faltantes. Palabras Clave. Cloud Computing, Arquitectura orientada a Servicios, Plataformas. I. QUÉ ES UNA ARQUITECTURA SOA? SOA es una representación de una arquitectura abierta, extensible y federada basada en composición, que promueve la orientación a los servicios interoperables e independientes de los proveedores, los cuales pueden ser identificados en catálogos con gran potencial de reutilización e implementados como servicios Web. SOA puede establecer una abstracción de la lógica del negocio y la tecnología, resultando en un bajo acoplamiento entre dominios [1]. SOA es el producto de la evolución de plataformas de tecnología que se solían utilizar con frecuencia, preservando las características exitosas de las arquitecturas tradicionales. Podemos entender a las arquitecturas SOA como un estilo de diseño que guía los aspectos de creación y uso de servicios de negocio a través de su correspondiente ciclo de vida. Además define y aprovisiona la infraestructura de tecnologías de la información que permite a diferentes aplicaciones intercambiar datos y participar en los procesos de negocio, independientemente del sistema operativo o de los lenguajes de programación con los cuales estos servicios (y aplicaciones) fueron desarrollados e implementados [2]. Muchas definiciones de SOA incluyen el término servicios web, sin embargo, es necesario hacer la distinción de estos conceptos y aclarar que SOA no es lo mismo que servicios Web puesto que SOA, a diferencia de los servicios web, define y trata un paradigma, en tanto que los servicios web son solo una forma posible de consumar la infraestructura utilizando una estrategia de implementación específica. Podemos decir entonces que SOA es un paradigma arquitectónico que permite el tratamiento de procesos de negocio distribuidos de nuevos sistemas heterogéneos 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 también aclarar que SOA no es una bala de plata (silver bullet) ni una tecnología específica, por lo cual, hay casos en los cuales SOA puede ser un paradigma apropiado y otros en los cuales pueden no ser la solución más adecuada o conveniente. SOA puede ser entendido también como un modelo de diseño cuyas raíces conceptuales establecen los principios de encapsulamiento de la lógica de la aplicación por medio de servicios, los cuales pueden interactuar a través de protocolos de comunicación estandarizados. La arquitectura orientada a servicios representa la evolución a un nuevo modelo que permite la construcción 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 construcción de aplicaciones y sistemas que resuelven problemas organizacionales, departamentales y corporativos. Un negocio con múltiples 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 teórico de SOA: el concepto de servicios puede resultar familiar para cualquiera que realice compras en línea utilizando aplicaciones web de tipo e-commerce (comercio electrónico; 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 crédito, la cual es típicamente autorizada y actualizada (gasto) por un proveedor de servicios externo. Una vez que la orden ha sido consumada, la compañía de comercio electrónico coordina la entrega con un proveedor de servicios de envíos para entregar el producto que el cliente Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

58 adquirió. SOA no es la primera arquitectura distribuida que permite utilizar componentes a través de interfaces de dominios independientes, por lo cual su aporte diferencial no reside precisamente en esta característica. 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 años en arquitecturas distribuidas, con excepción de que la interacción entre los proveedores de servicios web y los consumidores se caracterizan por presentar mucho menor acoplamiento. SOA también es un paradigma único en tanto que incorpora factores que son críticamente 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 comunicación sincrónicos rígidos bajo un flujo de trabajo lineal el cual es altamente susceptible a fallas en algún punto. SOA asume que los errores ocurren y en efecto ocurrirán, para lo cual ofrece estrategias para una eficiente administración de estos. Por ejemplo, si un servicio falla al recibir una petición de mensaje en su primer intento, la arquitectura SOA propone que su implementación reintente el envío de este mensaje, y si el servicio se encontrara por completo no disponible (lo cual nunca debería ocurrir en una SOA robusta), la arquitectura debe estar diseñada para evitar posibles fallas catastróficas que podrían interrumpir por completo la recepción de peticiones (requests). En conclusión, y en un sentido más amplio, podemos decir que SOA representa un proceso de maduración de la tecnología como el incremento de uso de los servicios web y tecnologías de integración en general. SOA reconoce que los sistemas de misión crítica basadas en tecnologías distribuidas deben proporcionar ciertas garantías. Debe asegurar entonces que las solicitudes de servicio se entreguen correctamente, que serán respondidas en el momento oportuno y que se publicarán sus políticas de comunicación e interfaces [4]. A CONTINUACIÓN SE PRESENTA UN EJEMPLO DE ARQUITECTURA ALINEADA A SOA En la Figura 1 se presenta un diagrama que modela una arquitectura genérica de 3 capas alineada a SOA. A continuación se presenta la Tabla 1, que describe cada uno de los componentes que integran esta arquitectura genérica. II. ESTADO DE LA CUESTIÓN A. Características de SOA: Bajo acoplamiento: el acoplamiento es el grado en que cada módulo de programa depende de cada uno de los otros módulos de programa. El bajo acoplamiento generalmente se correlaciona con la alta cohesión y viceversa [5]. Los servicios web poseen la característica 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 fácil de mover a otro equipo, puesto que la funcionalidad se encuentra abstraída 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. TABLA 1. DESCRIPCIÓN DE LOS COMPONENTES QUE INTEGRAN LA ARQUITECTURA GENÉRICA Término Agentes de Servicio Componentes de IU Componentes de Lógica de Acceso a Datos Componentes de Negocio Componentes de Procesos de IU Entidades de Negocio Flujo de Trabajo del Negocio Fuentes de datos Interfaces de Servicios Seguridad, gestión operativa, Comunicaciones Definición Este componente (Service Agents) permite a las implementaciones de los servicios de negocio acceder a otras instancias de servicios, con el propósito de reutilizar funcionalidades, testear minimizar las pruebas funcionales (las funcionalidades reutilizables se encuentran 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 podrán beneficiarse con las mejoras implementadas). Se refiere a los componentes de interfaz de usuario que serán implementados y desplegados en esta arquitectura Estos componentes contienen la lógica de acceso a datos (Data Access Logic Components), abstrayendo y separando concretamente la capa de lógica del negocio de la capa de acceso a datos (separación y asignación de responsabilidades por capas). Corresponden a la implementación de los servicios de negocio, comprendiendo fundamentalmente las funcionalidades y operaciones de negocio requeridas. Implementan las operaciones definidas en las interfaces del negocio (Service Interfaces). Hace referencia a los componentes que implementan procesos competentes a la capa de interfaz de usuario. Corresponden a las entidades del modelo de dominio (Business Entities). Son utilizadas tanto por los servicios como por los componentes de acceso a datos. Este componente encapsula e implementa mecanismos de flujos de trabajo (Business Workflow) que permiten formalizar y organizar los procesos del negocio para el modelo de dominio en cuestión. Algunas de las fuentes de datos posibles (Data Sources) podrían ser una base datos relacional, archivos de datos, un data grid, bases de datos NoSQL, etc. Las interfaces de servicios funcionan como contratos, definiendo formalmente las operaciones (capacidades) que brindarán los servicios basados en esta arquitectura. Estos componentes (Security, Operational Management, Communication) operan de manera transversal porque su funcionamiento debe considerarse en todas las capas. La aplicación podría utilizar también componentes para realizar la administración de excepciones, autorizar a los usuarios a realizar ciertas tareas y comunicarse con otros servicios y aplicaciones. Se refiere a los usuarios que harán uso de la Usuarios aplicación. a. Componentes de la arquitectura genérica. Adaptado de [Microsoft Corp., 2003]. Digamos que, sin embargo, el propietario de la unidad central quiere remplazar la máquina antigua con un nuevo servidor Sun. Como vemos en la parte 2, la máquina Sun sustituye a la unidad central, pero la minicomputadora, que es el consumidor del servicio web no tiene conocimiento de esta sustitución. 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 máquina Sun, la 208 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

59 minicomputadora continúa accediendo al servicio sin percibir este cambio. WSDL, de manera que se establezca un vínculo entre el cliente (consumidor del servicio) y la nueva dirección del servicio web en el dominio B. 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 sustitución de ordenadores continúa. El propietario de la minicomputadora la remplaza con un PC. El PC que está equipado con su propia interfaz SOAP puede acceder fácilmente a los servicios web expuestos por la máquina Sun. Si por cualquier razón el propietario del servicio decidiera sustituir la máquina Windows por otro servidor Sun, no habría problema alguno; una vez más se podría acceder al servicio sin necesidad de realizar ninguna modificación 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 envían 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 ningún 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 dónde residen las aplicaciones a las cuales estamos está accediendo con nuestro navegador, lo único que se necesita saber es la dirección web. Un mismo servicio web puede estar situado en dos dominios diferentes. Si por alguna razón el dominio A se encontrara no disponible, entonces el consumidor del servicio podría acceder al servicio web desde el dominio B de manera alternativa. Lo único que tiene que ocurrir es la modificación de la dirección (URL) del servicio web en el documento Fig. 2. Bajo acoplamiento del servicio. Adaptado de [6] Dada nuestra amplia experiencia con la Internet en los últimos años, 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 informática. La combinación de acoplamiento débil y la transparencia de red presentan nada menos que una revolución en la informática empresarial, no porque se trate de una idea novedosa, sino debido a que la infraestructura y los estándares han llegado por fin para que sea una realidad. Las empresas han gastado fortunas en los últimos años en la gestión de interfaces que hacen factible la interoperabilidad de los equipos en entornos distribuidos. Algunas empresas Norteamericanas gastan cientos de miles de millones de dólares por año en tecnologías de la información [6]. Reusabilidad y granularidad: Un servicio es un software reutilizable y auto-contenido, independiente de las aplicaciones y las plataformas de computación 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 relación entre los servicios y los procesos de negocios es crítica. Un proceso de negocio es un conjunto de tareas de negocios relacionados que abarcan personas, sistemas e información para producir un resultado o producto específico. Con SOA, un proceso se compone de un conjunto de servicios. Antes de SOA, el foco estaba en sub-tareas técnicas. Puede haber oído que la gente llama a esto un buen "nivel de granularidad" o bajo "grado de abstracción." Por la simplicidad de SOA, sabemos que es más que una simple relación uno-auno entre los pasos de un proceso (como la comprobación de una calificación crediticia) y los servicios que están diseñados para apoyar ese proceso de negocio flexible. Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

60 Cada empresa tiene una visión diferente respecto de la granularidad que requieren sus servicios en función de su diseño de negocios. En pocas palabras, la granularidad es la cantidad de función que un servicio expone. Por ejemplo, un servicio de granularidad fina proporciona unidades más pequeñas de un proceso de negocio, y un servicio de granularidad gruesa proporciona una tarea de negocio más amplia que contiene un mayor número de pasos [7]. Los servicios no pueden ser demasiado grandes o demasiado pequeños, sino que deben tener la granularidad adecuada. Diseñar y decidir la granularidad de los servicios es una cuestión clave que conduce al éxito. Si el servicio es demasiado grande, será menos reutilizable. Si el servicio es demasiado pequeño, provoca una disminución en el rendimiento y mala asignación de tareas entre los negocios y los servicios que los apoyan. Determinar qué tan grande o pequeño debe diseñarse un servicio es función qué tan atómica es la composición de su función. Es importante observar que este concepto de servicios es una de las claves para hacer que SOA sea el lenguaje de los negocios. La mayoría de los líderes empresariales no comprenden el valor de SOA. En su lugar, se centran -y con razón- en el problema en cuestión. Debido a estos servicios de negocio, este lenguaje y la vinculación de los servicios de negocio y SOA se convierten en una pieza fundamental para la solución del problema, y constituyen la futura misión estratégica [7]. Sistemas distribuidos: A medida que las empresas crecen se vuelven más y más complejas, y cada vez se involucran más empresas y sistemas. Hay una integración 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 definición más adecuada para "capacidades distribuidas" en IT sería "sistemas distribuidos", o como dice la definición 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 realización de funcionalidades de negocio [3]. Diferentes propietarios: La definición 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 razón importante por la que SOA no es sólo un concepto técnico. SOA incluye prácticas 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 comprensión 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 más pequeños. Una consideración importante es que "la política" entra en juego: hay que comprometerse con los demás, 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 pequeños y grandes es la falta de armonía. Todos lo sabemos por experiencia (aunque podríamos no estar de acuerdo acerca de si se trata de un fenómeno natural o el resultado de un mal diseño). Los grandes sistemas utilizan distintas plataformas, diferentes lenguajes de programación (y paradigmas de programación), e incluso diferentes componentes middleware. Se trata de un lío de mainframes, ejércitos de SAP, bases de datos, aplicaciones J2EE, pequeños motores de reglas, etc. En otras palabras, son heterogéneos. En el pasado, se han propuesto una gran cantidad de métodos para resolver el problema de la integración de sistemas distribuidos mediante la eliminación de la heterogeneidad: "Vamos a armonizar, y todos los problemas habrán 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 métodos no funcionan. Grandes sistemas distribuidos con diferentes propietarios son heterogéneos. Esto es un hecho, y por lo tanto algo que debemos aceptar la hora de diseñar soluciones distribuidas de gran tamaño [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 combinación arquitectónica de recursos, tecnologías y plataformas (relacionadas con la infraestructura o no). Si nos tomamos el tiempo para personalizar estos elementos arquitectónicos, podemos establecer un ambiente refinado y normalizado para la aplicación de programas de software también personalizados. El diseño intencional de la tecnología 210 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

61 de arquitectura es muy importante para la computación orientada a servicios. Es esencial crear un entorno en el que los servicios pueden ser recompuestos varias veces para maximizar la realización de las necesidades de negocio. El beneficio estratégico para personalizar el alcance, el contexto y los límites de una arquitectura es significativo. Para comprender mejor los mecanismos básicos de SOA, ahora tenemos que estudiar los tipos más comunes de las arquitecturas tecnológicas que existen. Se presentan a continuación, en la tabla 2, estos tipos de arquitecturas tecnológicas más comunes, con sus correspondientes definiciones. TABLA 2. ARQUITECTURAS TECNOLÓGICAS MÁS COMUNES. ADAPTADO DE [MICROSOFT CORP., 2003] Término Arquitectura de Composición de Servicios Arquitectura de Inventario de Servicios Arquitectura empresarial Orientada a Servicios Arquitectura de Servicios Definición La arquitectura de un conjunto de servicios reunidos en composición de servicios Arquitectura que soporta un conjunto de servicios relacionados que son independientemente estandarizados y gobernados La arquitectura de la propia empresa (para cualquier tamaño de empresa) orientada a servicios Se trata de la arquitectura de un único servicio B.1. Arquitectura de servicios La arquitectura de servicios es una arquitectura de tecnología limitada al diseño físico de un programa de software diseñado como un servicio. Esta forma de arquitectura de la tecnología 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 autonomía. El ámbito de aplicación de una arquitectura de servicios también tenderá a ser mayor debido a que un servicio puede, entre otras cosas, abarcar múltiples componentes. Considerando que no siempre fue común documentar una arquitectura diferente para cada componente en aplicaciones distribuidas tradicionales, la importancia de la producción de servicios que deben existir como programas de software independiente, muy autosuficiente y autónomo, requiere que cada uno de ellos sea diseñado de forma individual [8]. B.2. Arquitectura de Composición de Servicios El propósito 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 más grandes y más complejas. Cada composición de servicios tiene una arquitectura de composición de servicios correspondiente. De la misma manera que una arquitectura de aplicación 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 composición (especialmente una que compone servicios que encapsulan sistemas heredados dispares) puede ser comparado con una arquitectura de integración tradicional. Esta comparación por lo general sólo es válida parcialmente, ya que las consideraciones de diseño destacadas por la orientación a servicios aseguran que el diseño de una composición de servicios es muy diferente a la de las aplicaciones integradas. Por ejemplo, una diferencia en cómo se documentan las arquitecturas de composición tiene que ver con la medida de detalle que estas incluyen acerca de los servicios reutilizables que participan en la composición. Debido a que estos tipos de especificaciones de arquitecturas de servicios están a menudo protegidas (según las necesidades planteadas por el principio de abstracción de Servicios), una arquitectura de composición sólo podrá hacer referencia a la interfaz técnica y acuerdo de nivel de servicio (SLA), publicado como parte del contrato público 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 colección representa un alcance significativo que excede el límite de procesamiento de un único proceso de negocio e idealmente abarca numerosos procesos de negocio. El alcance y los límites de una arquitectura de inventario de servicio pueden variar. Idealmente, el inventario de servicios es primero modelado conceptualmente, lo que lleva a la creación 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 diseño de la empresa, el inventario de servicios puede representar un límite concreto para la implementación de la arquitectura estandarizada. Esto significa que debido a que los servicios dentro de un inventario están estandarizados, son las tecnologías 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 razón, a este tipo de arquitectura no se le llama "arquitectura de dominio". Se relaciona con el alcance del inventario, que puede abarcar múltiples dominios. Es difícil comparar una arquitectura de inventario de servicios con los tipos de arquitecturas tradicionales, porque el concepto de un inventario no ha sido común. El candidato más cercano sería una arquitectura de integración que representa algún segmento importante de una empresa. Sin embargo, esta comparación sólo sería relevante en su alcance, ya que las características del diseño orientado a servicios y los esfuerzos de estandarización relacionados intentan convertir un inventario de servicios en un entorno altamente homogéneo [8]. B.4. Arquitectura Empresarial Orientada a Servicios Esta forma de arquitectura tecnológica representa prácticamente la totalidad de los servicios, composición de servicios y arquitecturas de inventario de servicios que residen dentro de una empresa de IT específica. Una arquitectura orientada a servicios empresariales, es comparable con una arquitectura técnica empresarial tradicional sólo cuando la mayoría o todos los entornos técnicos de la empresa están orientados a servicios. De lo contrario, puede ser simplemente una documentación de las Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

62 partes de la empresa que han adoptado SOA, en cuyo caso existe como un subconjunto de la tecnología arquitectónica empresarial. En entornos de múltiples inventarios o en entornos en los cuales los esfuerzos de estandarización no fueron un éxito total, una especificación de arquitectura empresarial orientada a servicios documentará todos los puntos de transformación y la disparidad de diseño que también pueda existir. Además, la arquitectura orientada a servicios empresarial puede establecer estándares y convenciones de diseño que apliquen a la totalidad de empresa que todos los servicios, la composición y las implementaciones de la arquitectura del inventario deben cumplir [8]. C. Amazon Elastic Compute Cloud C.1. Descripción Amazon Elastic Compute Cloud (Amazon EC2) es un servicio web que proporciona capacidad informática con tamaño modificable en la nube. Está diseñado para facilitar a los desarrolladores recursos informáticos 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 rápidamente la capacidad, ya sea aumentándola o reduciéndola, según cambien sus necesidades. Amazon EC2 cambia el modelo económico de la informática, al permitir pagar sólo por la capacidad que utiliza realmente. Amazon EC2 presenta un auténtico entorno informático 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. Características principales C.2.1. Elastic Amazon EC2 permite aumentar o reducir la capacidad en cuestión de minutos, sin esperar horas ni días. Puede enviar una, cientos o incluso miles de instancias del servidor simultáneamente. Desde luego, como todo esta operación se controla con API de servicio Web, la aplicación 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 raíz (root) a todas ellas, y puede interactuar con ellas como con cualquier otra máquina. Puede detener su instancia y mantener los datos en su partición de arranque, para reiniciar a continuación la misma instancia a través 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 emisión 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 configuración de memoria, CPU, almacenamiento de instancias y el tamaño de la partición de arranque óptimo para su sistema operativo y su aplicación. Por ejemplo, entre sus opciones de sistemas operativos se incluyen varias distribuciones de Linux y Microsoft Windows Server. C.2.4. Diseño 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 solución informática 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 sustitución se pueden enviar con rapidez y anticipación. 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 Región de Amazon EC2 [9]. C.2.6. Seguro Amazon EC2 ofrece diversos mecanismos para proteger los recursos informáticos [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 informáticas especificando el rango de IP que desea utilizar, así como conectarse a su infraestructura de IT existente mediante la red cifrada IPsec VPN estándar del sector. También 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 más aislamiento [9]. C.2.9. Económico Amazon EC2 permite disfrutar de las ventajas financieras de Amazon. Pagará una tarifa muy baja por la capacidad informática que realmente utiliza. Consulte las Opciones de compra de instancias de Amazon EC2 para obtener una descripción más detallada [9]. C Instancias en demanda Con On-Demand Instances puede pagar por la capacidad informática por hora, sin compromisos a largo plazo. Esto le liberará de los costes y las complejidades de la planificación, la compra y el mantenimiento del hardware y transformará lo que normalmente son grandes costes fijos en costes variables mucho más pequeños. Gracias a On-Demand Instances también se elimina la necesidad de comprar una "red de seguridad" de capacidad para gestionar picos de tráfico periódicos [9]. C Instancias reservadas Las instancias reservadas ofrecen la opción de realizar un pago puntual reducido por cada instancia que desee reservar y recibir a cambio un descuento importante en el cargo de uso 212 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

63 por horas de dicha instancia. Existen tres tipos de instancias reservadas (instancias reservadas de utilización ligera, mediana e intensa) que permiten equilibrar el importe del pago anticipado a realizar con su precio por hora efectivo. Está a su disposición 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 región 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 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 periódicamente según la oferta y la demanda, y los clientes cuyas ofertas alcancen o superen dicho precio tendrán acceso a las instancias puntuales disponibles. Si es flexible respecto a cuándo ejecutar sus aplicaciones, las instancias puntuales pueden reducir significativamente sus costes de Amazon EC2 [9]. C.3. Amazon CloudWatch (autoescalabilidad) Amazon CloudWatch proporciona la supervisión 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 métricas 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 también puede supervisar métricas personalizadas generadas por las aplicaciones y los servicios de un cliente. Con Amazon CloudWatch, obtendrá una visibilidad para todo el sistema de la utilización de recursos, el rendimiento de las aplicaciones y el estado de funcionamiento. Amazon CloudWatch le permite supervisar las instancias de Amazon EC2, volúmenes de Amazon EBS, Elastic Load Balancers y las instancias de bases de datos de Amazon RDS en tiempo real. Métricas como la utilización de la CPU, la latencia y los recuentos de solicitudes se proporcionan automáticamente para estos recursos de AWS [10]. C.4. Blueprints / Imágenes para acelerar el aprovisionamiento Amazon denomina AMIs a sus Blueprints o imágenes para acelerar y facilitar el aprovisionamiento de instancias en la nube. Una máquina de imagen Amazon (AMI) es un tipo especial de sistema operativo pre-configurado y software de aplicaciones virtualizadas que se utiliza para crear una máquina virtual en el Amazon Elastic Compute Cloud (EC2). Además, es la unidad básica de la implementación de los servicios prestados mediante EC2. La plataforma Elastic Compute Cloud cuenta con más de 2200 imágenes de máquinas virtuales alternativas, con diferentes sistemas operativos, aplicativos y configuraciones. Una de las configuraciones más populares cuenta con un sistema operativo Ubuntu y software de base LAMP (Linux, Apache, MySQL y PHP). Además, las instancias de AMIs se pueden filtrar por Proveedor (Ej. IBM, Oracle, Amazon Web Services, Sun Microsystems, Novell, Microsoft o Community), por Región (física), 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 rápido 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 solución compatible basada en Windows en la plataforma informática en la nube de AWS, que ofrece alto rendimiento, fiabilidad y rentabilidad. Entre los casos prácticos 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, transcodificación de medios, pruebas distribuidas, alojamiento de aplicaciones en ASP.NET y cualquier otra aplicación que requiera software de Windows. Amazon EC2 también es compatible con las bases de datos SQL Server Express, SQL Web y SQL Standard y, además, pone estas ofertas a disposición de sus clientes con tarifas por horas. Amazon EC2 ejecutándose sobre Windows Server proporciona una integración 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 están 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 reúnen 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á diseñada para proporcionar un entorno de ejecución estable, seguro y de alto rendimiento para aplicaciones que se ejecuten en Amazon EC2. También incluye paquetes que permiten una fácil integración con AWS, incluidas herramientas de configuración de inicio y muchas bibliotecas y herramientas populares de AWS. Amazon Web Services también 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á diseñado para facilitar a los desarrolladores recursos informáticos 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 económica, altamente escalable, fiable, segura y rápida que utiliza Amazon para tener en funcionamiento su propia red internacional de sitios web. Este Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

64 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 configuración, utilización y escalado de una base de datos relacional en la nube. Proporciona capacidad rentable y de tamaño modificable y, al mismo tiempo, gestiona las tediosas tareas de administración 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 código, las aplicaciones y las herramientas que ya utiliza en la actualidad con sus bases de datos existentes funcionarán a la perfección con Amazon RDS [15]. C.7.2. Amazon SimpleDB (beta) Amazon SimpleDB es un almacén de datos no relacionales de alta disponibilidad y flexible que descarga el trabajo de administración 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 réplicas de sus datos y las distribuye geográficamente para permitir alta disponibilidad y capacidad de duración. El servicio sólo le cobra los recursos realmente consumidos en almacenamiento de los datos y en distribución de las solicitudes. Es posible cambiar el modelo de datos sobre la marcha, y el sistema indexa los datos automáticamente por usted [16]. C.8. Soporte para Colas Amazon Simple Queue Service (Amazon SQS) ofrece un sistema de gestión 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 creación de un flujo de trabajo automatizado, trabajando en estrecha conexión 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 gestión de mensajes a escala web de Amazon como un servicio web. Cualquier sistema de Internet puede añadir o leer mensajes sin tener instalado ningún software ni configuración de cortafuegos especial. Los componentes de las aplicaciones que utilizan Amazon SQS se pueden ejecutar independientemente y no es necesario que estén en la misma red, que se hayan desarrollado con las mismas tecnologías ni que se ejecuten a la vez [17]. C.9. Alternativas de Hipervisor Amazon EC2 actualmente utiliza una versión altamente personalizada del hipervisor Xen, aprovechando la paravirtualización. Como los huéspedes ("Guest") paravirtualizados 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. Descripción Windows Azure es una plataforma de nube abierta y flexible que permite compilar, implementar y administrar aplicaciones rápidamente en una red global de centros de datos administrados por Microsoft. Puede compilar aplicaciones en cualquier lenguaje, herramienta o marco, permitiendo además integrar sus aplicaciones de nube públicas con el entorno de TI existente [19]. D.2. Características 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 automáticas del Sistema Operativo y de los servicios, equilibrio de carga de red integrado y resistencia ante errores de hardware. Admite un modelo de implementación con el que se puede actualizar una aplicación sin inactividad (downtime) [19]. D.2.3. Abierto Windows Azure permite utilizar cualquier lenguaje, marco o herramienta para crear aplicaciones. Las características y los servicios se exponen utilizando protocolos REST abiertos. Las bibliotecas de cliente de Windows Azure están disponibles para varios lenguajes de programación, se comercializan bajo una licencia de código abierto y se hospedan en GitHub [19]. D.2.4. Servidores ilimitados, almacenamiento ilimitado Windows Azure permite escalar aplicaciones a cualquier tamaño con facilidad. Es una plataforma de autoservicio totalmente automatizada que permite el aprovisionamiento de recursos en cuestión de minutos. El uso de recursos aumenta o disminuye de manera flexible en función de las necesidades. Solo se pagan los recursos que usa la aplicación. 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 aplicación. Permite hospedar y ampliar el código de aplicación 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 opción de usar la funcionalidad de Hadoop e inteligencia empresarial para la minería de datos. 214 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

65 Puede aprovechar la sólida funcionalidad de mensajería de Windows Azure para habilitar aplicaciones distribuidas escalables, así como para entregar soluciones híbridas 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 Aplicación Autoescalable" puede escalar automáticamente su aplicación de Windows Azure basado en reglas definidas específicamente para su aplicación. Puede utilizar estas reglas para ayudar a la aplicación 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 aplicación en Windows Azure. Junto con la escalabilidad, aumentando o disminuyendo el número de instancias de rol (working role) en su aplicación, el bloque también permite utilizar otras medidas de escalabilidad tales como funcionalidades determinadas de estrangulamiento ("throttling") dentro de la aplicación o el uso de las acciones definidas por el usuario. Brinda además la posibilidad de optar por implementar el bloque en un rol de Windows Azure o en una aplicación interna. El Bloque de Aplicación 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 automático de escalabilidad para su aplicación: Reglas de restricciones: Para establecer los límites superior e inferior en el número de instancias, por ejemplo, digamos que 8:00-10:00 todos los días quiere un mínimo de cuatro y un máximo de seis instancias, se utiliza una regla de restricción. Reglas Reactivas: Para permitir que el número de instancias de rol puedan cambiar en respuesta a los cambios impredecibles en la demanda, se utilizan reglas reactivas [20]. D.4. Blueprints / Imágenes para acelerar el aprovisionamiento Las máquinas virtuales entregadas a demanda ofrecen una infraestructura de computación escalable cuando se necesita aprovisionar rápidamente recursos para satisfacer las necesidades de un negocio en crecimiento. Es posible obtener máquinas virtuales de los sistemas operativos Linux y Windows Server en múltiples 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 configuración deseada (instancias de memoria estándar o alta) y seleccionar una imagen de la galería de imágenes de máquinas virtuales. Las Máquinas 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 código va a ser diferente, ya que se ejecuta en la nube, o si vas a tener que aprender un nuevo marco (traducido del término en inglés "framework"), la respuesta es "no". Continuará escribiendo código que se ejecuta en Windows Server. El marco de. NET (3.5 SP1) se instala por defecto en todas las máquinas, y el código ASP.NET típico funcionará. Es también posible utilizar el soporte FastCGI para correr cualquier marco que soporte FastCGI (como PHP, Ruby on Rails, Python, etc). Si dispone de código nativo o binario, también puede ejecutarlo [22]. Cada hipervisor administra varios sistemas operativos virtuales. Todos ellos corren el sistema operativo Windows Server compatible con En realidad, no se nota ninguna diferencia entre ejecutar un Windows Server 2008 y estas máquinas. Las únicas diferencias son algunas optimizaciones específicas para el hipervisor en el cual están corriendo [22]. Bajo qué sistema operativo estará corriendo su código en Windows Azure? Incluso con toda esta discusión sobre el funcionamiento del sistema y las optimizaciones de integración con el hipervisor, la mayoría de los desarrolladores sólo se preocupan por el entorno en el cual correrán 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 están abstraídas varias capas lejos de estos cambios, y no deben notar nada distinto respecto de su ejecución en una máquina Windows Server normal [22]. D.6. Soporte para Sistemas operativos Linux Crear una máquina virtual que ejecute el sistema operativo Linux en Windows Azure es fácil por medio de la Galería de imágenes (blueprints) utilizando el Portal de administración. Es también posible acceder a las instancias de estas máquinas virtuales Linux para personalizarlas a gusto, por medio de un usuario con privilegios de adminsitrador ("Root"). Es también factible implementar En Azure máquinas virtuales ya disponibles que corren sistemas operativos Linux, por ejemplo con instancias de máquinas virtuales vmware. Para esto, solo es necesario convertir la imagen de la máquina virtual Linux al formato de Windows Azure (de.vmx a.vmdk), para luego subirla a nuestra cuenta Azure por medio del administrador de imágenes 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 máquinas virtuales son las siguientes [21]: opensuse 12.3 SUSE Linux Enterprise Server 11 Service Pack 2 Ubuntu Server LTS Ubuntu Server Ubuntu Server OpenLogic CentOS 6.3 Ubuntu Server DAILY D.7. Soporte para almacenamiento de datos D.7.1. SQL Server en máquinas virtuales de Windows Azure Cuando las aplicaciones requieren funcionalidad completa de SQL Server, Máquinas virtuales es la solución ideal. Encontrará ofertas de imágenes de SQL Server 2012 y SQL Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

66 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 ejecución de SQL Server en Máquinas virtuales es una solución adecuada en los escenarios siguientes: Para desarrollar y probar nuevas aplicaciones de SQL Server rápidamente No es necesario esperar semanas para el aprovisionamiento local de hardware, sino que basta con captar la imagen de SQL Server correcta en la galería de imágenes. Puede optar por realizar la implementación en un entorno de producción o local con poco esfuerzo. Para hospedar aplicaciones de SQL Server de nivel 2 y nivel 3 existentes Gracias a los distintos tamaños 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 computación 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 máquina virtual de Windows Azure en caso de que sea necesaria la recuperación ante desastres en el entorno local. Para ampliar aplicaciones locales Cree aplicaciones híbridas que utilicen activos locales y máquinas virtuales de Windows Azure para disfrutar de una mayor eficacia y alcance global. Para crear aplicaciones de varias capas en la nube Cree una aplicación de varias capas que utilice la funcionalidad de escalado única del servicio Base de datos SQL para la capa de aplicación y que aproveche la compatibilidad completa de SQL Server en Máquinas 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 mayoría de los principales marcos de desarrollo. Además, la base de datos SQL, basada en las tecnologías probadas de SQL Server, permite utilizar los conocimientos y la experiencia existente para reducir el tiempo de solución, 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 certificación ISO que se pueden escalar automáticamente para satisfacer un rendimiento y volumen masivos de hasta 100 terabytes, accesibles prácticamente desde cualquier lugar a través de REST y las API administradas [24]. D.7.4. Blob no estructurado Los blobs son el modo más sencillo de almacenar grandes cantidades de texto no estructurado o datos binarios tales como vídeo, audio e imágenes. Los blobs son un servicio administrado con certificación ISO que se pueden escalar automáticamente para satisfacer un rendimiento y volumen masivos de hasta 100 terabytes, accesibles prácticamente desde cualquier lugar a través de REST y las API administradas [24]. D.8. Soporte para colas El bus de servicio de Colas soporta un modelo de comunicación de mensajería negociado.cuando se utilizan colas, los componentes de una aplicación distribuida no se comunican directamente entre sí, en cambio, intercambian mensajes via una cola, lo cual actúa como un intermediario. Un productor de mensajes (remitente) envía un mensaje a la cola y continua su procesamiento. Asincrónicamente, 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 más mensajes. Las colas ofrecen la implementación de la técnica "primero que entra, primero que sale" (modelo conocido por sus siglas en inglés como "FIFO") enviando mensajes a uno o más 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 añadidos 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. Rápido El hipervisor de Windows Azure ha sido diseñado para ser lo más eficiente posible. Gran parte de esto se consigue a través 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 características de hardware, a diferencia de hipervisores genéricos diseñados para un mercado más amplio [22]. D.9.2. Pequeño El hipervisor es construido para ser claro y directo, y no incluye aquellas características que no están directamente relacionadas con la nube. Menor cantidad de código no sólo significa un mejor rendimiento, sino que también significa menos código para corregir o actualizar [22]. D.9.3. Estrechamente integrado con el núcleo 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 confusión sobre las diferencias entre Hyper-V y el hipervisor de Windows Azure, y algunos libros / artículos a menudo asumen que se trata del mismo hipervisor. En realidad, ambos son diferentes y están construidos también con diferentes propósitos. Hyper-V es entregado como parte de Windows, y está destinado para funcionar en una 216 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

67 amplia variedad de hardware para una amplia variedad de propósitos. El hipervisor de Windows Azure se ejecuta sólo en los centros de datos de Microsoft, y se ha optimizado específicamente 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 código y diseño. En el futuro, las nuevas características del hipervisor de Windows Azure tendrán influencias en Hyper-V, y viceversa [22]. E. Google App Engine E.1. Descripción 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 implementación rápidos, y una administración sencilla, sin necesidad de preocuparse por el hardware, las revisiones o las copias de seguridad y una ampliación sin esfuerzos. Las aplicaciones Google App Engine son fáciles de crear, fáciles de mantener y fáciles de escalar a medida que el tráfico y las necesidades de almacenamiento de datos crecen. Con App Engine no es necesario mantener ningún servidor. Basta con cargar su aplicación y esta ya se encontrará lista para servir a los usuarios [26]. E.2. Características Principales E.2.1. Rápido para iniciar Sin necesidad de comprar ni mantener ningún software o hardware, puede prototipar y desplegar aplicaciones disponibles para los usuarios en cuestión de horas [27]. E.2.2. Fácil 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 fácil uso, permitiendo cerar servicios rápidamente [27]. E.2.4. Escalabilidad Inmediata No hay prácticamente ningún límite respecto de qué tan alto o qué tan rápido su aplicación pueda escalar [27]. E.2.5. Modelo de negocio de pago por uso Pague por lo que usa, comenzando sin ningún costo inicial. Pagará sólo por los recursos que su aplicación utilice a medida que crece [27]. E.2.6. Infraestructura probada Google App Engine utiliza la misma tecnología probada que alberga otras aplicaciones de Google, ofreciendo automáticamente 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 supervisión del sistema [27]. E.3. Autoescalabilidad Google App Engine está diseñado para alojar aplicaciones con muchos usuarios simultáneos. Cuando una aplicación puede servir a muchos usuarios simultáneos sin degradar su rendimiento, se dice que es escalable. Las aplicaciones escritas para App Engine escalan automáticamente. A medida que más personas utilizan la aplicación, App Engine asigna más recursos para la aplicación y administra el uso de esos recursos. La aplicación 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 aplicación en varios servidores, así como también iniciar y detener los servidores para satisfacer las demandas de tráfico. La caja de arena (traducción literal del término en inglés "Sandbox") aísla la aplicación en su propio entorno seguro y confiable que es independiente del hardware, sistema operativo y la ubicación física del servidor web. Ejemplos de las limitaciones de acceso al sistema operativo incluyen: Una aplicación sólo puede acceder a otros ordenadores situados en internet a través de la URL proporcionada y/o por medio de servicios de correo electrónico. Otros equipos sólo se pueden conectar a la aplicación realizando peticiones HTTP (o HTTPS) en los puertos estándar. Las aplicaciones no pueden escribir en el sistema de archivos en ninguno de los entornos de ejecución. Una aplicación puede leer archivos, pero sólo los archivos subidos con el código de la aplicación. La aplicación debe utilizar el almacén de datos de App Engine, memcache u otros servicios para aquellos datos que se persisten entre las peticiones. El código de aplicación sólo se ejecuta en respuesta a una petición 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 código después de que la respuesta haya sido enviada [28]. E.5. Soporte para almacenamiento de datos El almacenamiento de datos de una aplicación web escalable puede ser complicado. Un usuario puede interactuar con cualquiera de las docenas de servidores web en un momento dado, y la siguiente petición del usuario podría ir a un servidor web diferente a la anterior solicitud. Todos los servidores web deben interactuar con los datos, que también se extienden a través de docenas de máquinas, 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 distribución, la replicación y el equilibrio de carga de los datos detrás de una sencilla API-y se obtiene un motor de búsqueda de gran alcance, garantizando también las transacciones. El repositorio de datos de App Engine y el almacén de datos de alta replicación (HRD) utilizan el algoritmo Paxos para replicar datos a través de múltiples centros de datos. Los datos se escriben en el almacén 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 almacén de datos forman Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

68 así un espacio de estructura jerárquica similar a la estructura de directorios de un sistema de archivos. El almacén de datos es extremadamente resistente frente a fallos catastróficos, sin embargo, garantizar la consistencia puede ser bastante diferente de lo que usted está familiarizado. Las entidades que descienden de un antepasado común se dice que pertenecen a un mismo grupo de entidades, las llaves de su ancestro común 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 específica. Los grupos de entidad son una unidad de consistencia y transaccionalidad: mientras que las consultas sobre múltiples 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 aplicación puede realizar tareas además de responder a solicitudes web. Las aplicaciones implementadas en Google App Engine pueden ejecutar estas tareas siguiendo la programación que se configure, por ejemplo, cada día o cada hora. Asimismo, es posible ejecutar tareas que ella misma ha añadido a una cola, como una tarea en segundo plano creada durante el procesamiento de una solicitud. Las tareas programadas también se conocen como "tareas cron", administradas por el servicio cron. Las colas de tareas se incluyen actualmente como una función experimental. En este momento, solo el entorno de tiempo de ejecución 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 aplicación necesita ejecutar algún trabajo en segundo plano, puede utilizar el API de la cola de tareas para organizarlo en pequeñas unidades discretas llamadas tareas. A continuación, la aplicación inserta estas tareas en una o más colas. App Engine detecta automáticamente nuevas tareas y las ejecuta cuando los recursos del sistema lo permiten [28]. E.7. Alternativas de Hipervisor Google App Engine brinda muy escasa información 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 inglés 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. Descripción OpenShift es la oferta de plataforma como servicio para Computación 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 aplicación que se está construyendo, también proporciona acceso a una plantilla de sistema de archivos para esos tipos (por ejemplo PHP, Python y Ruby/Rails). También proporciona herramientas de desarrollo integradas para apoyar el ciclo de vida de las aplicaciones, incluyendo la integración de Eclipse, JBoss Developer Studio, Jenkins, Maven y GIT. OpenShift utiliza un ecosistema de código abierto para proporcionar servicios clave de la plataforma de aplicaciones móviles (Appcelerator), servicios NoSQL (MongoDB), servicios de SQL (PostgreSQL, MySQL), y más. 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. Características Principales F.2.1. Prestación de servicios de aplicación 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 normalización del desarrollo del ciclo de vida de aplicación de flujo de trabajo, permitirá la aceleración 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 tecnologías de código abierto, la plataforma OpenShift está diseñada para proporcionar libertad de elección, incluyendo la libertad de elegir alejarse de las PaaS. Para lograr esto, dentro de la plataforma OpenShift solo se utilizan lenguajes de código abierto y frameworks sin alteraciones. No se utilizan APIs, tecnologías o recursos privados. Esto asegura la portabilidad de aplicaciones de la plataforma OpenShift, evitando así las dependencias con los proveedores de tecnología utilizada por la plataforma PaaS OpenShift [31]. F.2.3. Pilas de aplicaciones de autoservicio y en demanda Al permitir a los desarrolladores desplegar rápida y fácilmente las pilas de aplicaciones, la plataforma OpenShift puede aumentar la productividad y fomentar la innovación en el diseño y la entrega de aplicaciones. Las nuevas ideas pueden ser prototipos rápidamente y proyectos de misión crítica pueden ser llevados al mercado más rápidamente [31]. F.2.4. Flujos de trabajo estandarizados para Desarrolladores [Red Hat Inc., 2013b.] OpenShift como plataforma de aplicaciones cloud permite que la organización 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. Políglota Elección de los lenguajes de programación 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 elección diferente para cada proyecto, según sea necesario. Además de estos y otros lenguajes de código abierto, muchos de los marcos de código abierto populares se incluyen también dentro de OpenShift. Algunos 218 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

69 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 reingeniería al código o a la arquitectura [31]. F.2.7. Servicios de base de datos incorporados Con las opciones de tecnología de bases de datos disponibles en OpenShift y la capacidad de tener estas instancias de bases de datos conectadas automáticamente a las pilas de aplicación según sea necesario, los desarrolladores y arquitectos de la empresa pueden elegir entre los almacenes de datos relacionales clásicos y los modernos NoSQL [31]. F.2.8. Sistema de cartucho Extensible para agregar servicios Además de la función de idiomas y servicios, los desarrolladores pueden añadir otro idioma, base de datos o componentes de middleware que necesitan a través del sistema de cartuchos OpenShift personalizable. Esta extensibilidad Cartucho permite a los desarrolladores (y operaciones) extender las PaaS para soportar los estándares o requisitos específicos de la empresa [31]. F.2.9. Soporte para múltiples entornos (desarrollo / Pruebas / Producción) Con la capacidad de la plataforma OpenShift para soportar múltiples ambientes del ciclo de vida de desarrollo de las aplicaciones (como Desarrollo, Calidad, Pre-Producción y Producción), las empresas pueden adoptar e implementar la plataforma PaaS (Platform As A Service) OpenShift sin necesidad de cambiar sus metodologías o procesos actuales [31]. F Dependencia y Gestión de la Construcción La plataforma OpenShift incluye Dependencia y gestión de la Construcción para muchos de los lenguajes de programación más populares, incluyendo Bundler para Ruby, NPM para Node.JS y Maven para Java. Estas herramientas automatizan el proceso de identificación de las dependencias en el código fuente, y la construcción de la aplicación completa. Estas características incrementan la productividad y reducen la posibilidad de error, volviéndose críticas en una plataforma de aplicaciones de nube como PaaS [31]. F Integración Continua y Gestión de Versiones La plataforma OpenShift incluye Jenkins para integración continua y gestión de lanzamiento. Jenkins puede realizar pruebas cuando se sube código al repositorio, organizar el proceso de construcción, y promover o cancelar automáticamente una versión de la aplicación dependiendo de los resultados de las pruebas. Esta gestión automatizada de los releases se convierte en una parte fundamental para simplificar el desarrollo de aplicaciones [31]. F Gestión de versiones de código fuente La plataforma OpenShift incluye el control distribuido de versiones Git y un sistema de gestión de código fuente. El protocolo Git asegurado con SSH es utilizado por los desarrolladores para comprobar el código en el repositorio Git seguro que reside dentro de su contenedor de aplicaciones con OpenShift. Git permite tanto la gestión rápida, segura y controlada de origen de la aplicación de control de versiones de código [31]. F Inicio de sesión 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 sesión 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 administración de sus aplicaciones [31]. F Integración con IDE Con integración 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 cómodos a la hora de trabajar con OpenShift [31]. F Línea de comandos enriquecida Para desarrolladores que prefieren trabajar desde la línea de comandos, la plataforma OpenShift incluye un amplio conjunto de herramientas de línea de comandos que proporcionan acceso completo a la interfaz del programador de las PaaS. Estas herramientas son fáciles de usar, así como secuencias de comandos para las interacciones automatizadas [31]. F Desarrollo de aplicaciones móviles A través de una asociación con Appcelerator, la plataforma OpenShift incluye una estrecha integración con Titanium Studio IDE móvil que permite el desarrollo de aplicaciones móviles en la nube con respaldo para Android o ios que pueden ser ejecutados por aplicaciones de servidor que se ejecutan en OpenShift [31]. F 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 mensajería, e infraestructura de alojamiento de aplicaciones (nodos). Cada pieza de la plataforma se puede configurar con redundancia múltiple para conmutación por error y equilibrio de carga escenarios para eliminar el impacto de fallo de hardware o infraestructura [31]. F Aprovisionamiento automático de la pila de aplicaciones Cuando un desarrollador utiliza la plataforma OpenShift de autoservicio para crear una aplicación, OpenShift creará automáticamente los engranajes necesarios, desplegará los runtimes del lenguaje (a través de cartridges), configurará las interfaces de red y la prestación de los ajustes del DNS y, finalmente, retornará al usuario las credenciales que necesitará para comenzar a subir el código para la aplicación. Este aprovisionamiento automático reemplaza lo que históricamente podría tomar días, semanas o incluso meses para el equipo de Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

70 operaciones de TI para hacerlo manualmente. Esto libera al equipo de operaciones para centrarse en las necesidades críticas de los clientes en lugar de ocuparse en la configuración de servidores de forma repetida [31]. F Escalabilidad automática de aplicación La plataforma OpenShift permite elasticidad cloud, proporcionando escalabilidad de aplicación horizontal automática a medida que aumenta la carga de aplicaciones, eliminando la necesidad de Operaciones para aumentar manualmente el número de instancias de aplicación [31]. F Elección de la infraestructura de nube (No disponible en OpenShift Online) OpenShift empresarial está diseñado para ser desplegado en la capa superior, y se ejecuta en Red Hat Enterprise Linux (RHEL). RHEL es necesario debido a la utilización de SELinux dentro de la plataforma OpenShift, y permite además 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 específicos para la capa de infraestructura aparte de que debe ser capaz de proveer instancias de RHEL. Para ello, los clientes OpenShift empresarial tienen la opción de infraestructura. Los clientes de la platasforma como servicios de OpenShift empresarial cuentan con opciones de infrasestructura, pudiendo implementar la solución mediante servidores físicos, mediante una plataforma de virtualización, una Infraestructura como servicio, o un proveedor de nube pública, siempre y cuando las instancias de RHEL puedan ser configuradas y accedidas, se pueden implementar. Esto otorga la libertad de implementar la solución 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 aplicación OpenShift, es automáticamente escalada basándose en la cantidad de peticiones (del inglés request ). OpenShift también permite escalar manualmente las aplicaciones ajustando los umbrales mínimos y máximos permitidos para escalar [32]. Cómo funciona la escalabilidad de OpenShift: El cartucho HAProxy se sienta entre la aplicación y el Internet público y las rutas de tráfico web a sus cartuchos web. Cuando aumenta el tráfico, 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 código en el repositorio git se copia en cada nuevo equipo, pero el directorio de datos comienza vacío. Cuando se inicia el nuevo cartucho de copia realizará los procedimientos necesarios y el proxy de alta disponibilidad (del inglés High availability Proxy, de acrónimo "HAProxy") comenzará a realizar el enrutamiento de las peticiones web al mismo. El algoritmo para la escalabilidad hacia arriba y hacia abajo (expansión y decremento) se basa en el número de solicitudes simultáneas a su aplicación. OpenShift asigna 10 conexiones por equipo. Si el HAProxy ve que la aplicación está sosteniendo el 90% de su capacidad máxima, añade otra instancia. Si la demanda cae un 50% de su capacidad máxima 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 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 expansión y crecimiento, pretende añadir más capacidades como almacenamiento compartido, bases de datos a escala, y el almacenamiento en caché compartida. La consola web OpenShift muestra cuántas instancias están actualmente siendo consumidas por la aplicación [33]. F.4. Blueprints / Imágenes 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 raíz 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 versión 6.3 (o superior) para las plataformas de hardware x86 o bien x64. A la fecha de creación 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 librería transaccional también basada en una base de datos SQL que no requiere configuración alguna [37]. Además, 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 técnicas de Map-Reduce [38]. F.6. Soporte para colas Red Hat OpenShift ofrece soporte para colas de mensajería con el producto IronMQ [39]. IronMQ es un servicio de colas de mensajería fácil de usar y de alta disponibilidad. IronMQ está construido para distribuir aplicaciones en la nube con necesidades de mensajería críticos. 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.Características principales F Listo para usar Sólo tiene que conectar IronMQ a los puntos finales (del inglés "endpoints") y ya está listo para crear colas y enviar y recibir mensajes. Perfecto para hacer mucho más cosas de forma asíncrona. F Alta disponibilidad Se ejecuta sobre infraestructuras de nube y utiliza múltiples centros de datos de alta disponibilidad. Utiliza almacenes de datos fiables para la durabilidad y persistencia de sus mensajes. 220 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

71 F Rendimiento escalable / Alto Escrito con la elasticidad y la escalabilidad en su núcleo. Construido con lenguajes de alto rendimiento diseñados para la concurrencia, se ejecuta en las nubes de potencia industrial. F Múltiples enlaces de lenguaje Hace uso de un amplio conjunto de bibliotecas de idiomas IronMQ como Ruby, PHP, Python, Java, Go, y mucho más. Gateways Seguros / OAuth2: Utiliza HTTPS y SSL para proporcionar pasarelas (del inglés "gateways") seguras para la gestión 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 implementación de Sistemas operativos basados en Kernels Windows. Las instalaciones típicas de OpenShift se realizan con el hipervisor KVM [41]. G. IBM SmartCloud G.1. Descripción SmartCloud ofrece una gestión de cloud con el valor agregado que permite la elección y la automatización más allá del aprovisionamiento de máquinas virtuales. IBM SmartCloud Enterprise+ es un entorno Cloud seguro, totalmente administrado y listo para producción, diseñado para garantizar una alta performance y disponibilidad. SmartCloud Enterprise+ ofrece un control completo de "governance", administración y gestión, permitiendo definir acuerdos de nivel de servicio (SLA) para alinear las necesidades de negocio y los requisitos de uso. Ofrece además múltiples opciones de seguridad y aislamiento, integrados en la infraestructura virtual y de red, manteniendo el cloud separado de otros entornos cloud [42]. G.2. Características Principales PureApplication System soporta múltiples virtualizadores. Es posible virtualizar, por ejemplo, con VMWare o Hyper-V. Los usuarios pueden autogestionar los recursos que necesitan (patterns de aplicación, requerimientos de disponibilidad, CPU, memoria, storage, etc) y el sistema realiza el deployment y el accounting automáticamente. Es posible definir políticas para las aplicaciones de manera que los recursos que esta insume sean elásticos, 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. Además, opcionalmente soporta la sincronización 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 otros clouds vendors mencionados, puesto que se implementa en un appliance. PureApplication System, que integra la funcionalidad de Cloud, de virtualización de aplicaciones y de datagrid, funciona todo en una misma "caja" (hardware) provista por IBM. G.3. Autoescalabilidad Obtener aplicaciones basadas en WebSphere rápidamente en la nube con el Servicio de Carga de Trabajo de aplicación de IBM SmartCloud: El Servicio de Carga de Trabajo de aplicación (SCAWS) de IBM SmartCloud elimina el tedio de la gestión de middleware y de infraestructura, lo que permite implementar más fácil, rápida y repetidamente aplicaciones basadas en WebSphere para la nube pública de IBM SmartCloud Enterprise [43]. Acelerar y simplificar la llegada a la nube con patrones: Como núcleo de la tecnología PaaS de IBM y construido en los años de experiencia de IBM, los patrones son plantillas que consisten en software y recursos de la máquina virtual. Los patrones simplifican radicalmente la configuración y gestión de los recursos de hardware y software, lo que permite a los equipos implementar rápidamente entornos de aplicaciones complejas para la nube con resultados validados, de alta calidad y consistentes [43]. Escale las Aplicaciones con escalabilidad automatizada basada en políticas: Los patrones tienen políticas para proporcionar automatización de gran alcance, incluyendo una política de enrutamiento para el balanceo de cargas, una política de registro, una política de JVM, y una política de escalabilidad basada en reglas automatizadas. Al establecer la política de ampliación, un patrón desplegado puede escalar de forma dinámica en función de las reglas (por ejemplo, sobre la base de tiempo de respuesta de solicitud) [43]. Rápido aprovisionamiento y escalabilidad: Con el aprovisionamiento de IBM SmartCloud, las organizaciones de TI pueden implementar rápidamente el tipo específico de entorno cloud que necesitan sin importar el tamaño, 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 rápidamente hacia arriba o hacia abajo según sea necesario, para ayudar a las organizaciones a satisfacer las necesidades cambiantes de TI sin interrumpir las operaciones. Despliegue de cientos de máquinas 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 informáticos, a su vez acelera la entrega de productos y servicios innovadores, lo que permite una respuesta más rápida a los retos y oportunidades del mercado. El aprovisionamiento de IBM SmartCloud permite un rápido despliegue y la integración de las capacidades de la nube utilizando patrones de carga de trabajo. Los patrones pueden ser creados utilizando un patrón suministrado como una plantilla o bien se pueden crear desde cero. Una vez creado un patrón, se puede reutilizar una y otra vez para crear varias instancias idénticas en la nube. Se puede lograr una integración significativa con componentes de middleware y recursos de infraestructura para optimizar los componentes para un tipo particular de carga de trabajo de la aplicación. Capacidades dinámicas y elásticas se realizan plenamente. El sistema puede Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

72 crear o eliminar recursos adicionales según sea requerido por la demanda de la aplicación [44]. G.3.1. Características destacadas Reducir los costos y la complejidad al permitir solicitudes de autoservicio y automatización de las operaciones Obtener una rápida escalabilidad para satisfacer el crecimiento del negocio con un despliegue casi instantáneo de cientos de máquinas virtuales Evitar los proveedores de tecnología mediante la creación de cargas de trabajo en la nubes optimizadas para entornos heterogéneos Acelerar las implementaciones de aplicaciones utilizando los patrones de carga de trabajo repetibles Optimizar los entornos virtualizados con la gestión del ciclo de vida y análisis de imagen avanzada Con herramientas como la Biblioteca Virtual de imagen, Construcción de Imagen y Composición (ICONO), y el Editor de diseños, El aprovisionamiento de IBM SmartCloud ayuda a las organizaciones a gestionar la expansión de imagen, velar por el cumplimiento, crear imágenes base, automatizar la instalación de software y crear patrones repetibles. Esta amplitud de capacidades ayuda a asegurar que las organizaciones no sólo puedan crear entornos de nube robustos, sino que también 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 fácil y rápidamente, y probar y desplegar aplicaciones de negocio, poniendo fin a la utilización de los procesos manuales, procesos complejos o aquellos que requieren mucho tiempo asociado a la creación de entornos de aplicación. Una vez que las solicitudes han completado sus tareas, los recursos retornan automáticamente al administrador de recursos compartidos. Esta solución también 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 gestión a lo largo de las diferentes infraestructuras, ayudando a reducir la complejidad y el coste de las operaciones. Permite el diseño 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, máquinas virtuales basada en el kernel (KVM), Xen, Microsoft Hyper-V, IBM PowerVM e IBM z/vm. Integra cómupto, almacenamiento de red y distribución de aplicaciones para ayudar a permitir la integración organizacional. Además, ayuda a reducir los costos de licencias y hardware con su soporte para múltiples hipervisores y gestión de entornos mixtos [44]. G.5. Soporte para almacenamiento de datos G.5.1. IBM SONAS 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. TCO hasta en un 40 por ciento inferior con la gestión del ciclo de vida y la migración automatizada en cinta Ofrece la opción de puerta de enlace (del inglés "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 migración automática de las unidades de estado sólido de alto rendimiento (SSD) [46]. Habilita el almacenamiento de hasta cinco veces los datos primarios más activos en el mismo espacio físico en disco utilizando Real-time Compression [46]. Consolida el bloque y el almacenamiento de archivos para simplificar, obteniendo una mayor eficiencia y facilidad de gestión [46]. Habilita la disponibilidad casi continua de las aplicaciones a través de la migración dinámica [46]. Gestión de datos diseñada para que sea fácil de usar, con una interfaz gráfica de usuario y sistema de gestión con la capacidad "apuntar y hacer clic" [46]. Metro Mirror y Global Mirror para la replicación de datos síncrona o asíncrona entre sistemas para la eficiencia del backup [46]. SSD para aplicaciones que requieren alta velocidad y acceso rápido 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 desafío 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 dinámicas, heterogéneas y una estrecha integración con hipervisores, así como también 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 diseñado para el crecimiento de los datos y una incomparable facilidad de uso Alto Rendimiento uniforme, logrado a través de paralelismo masivo y ajuste automático Almacenamiento virtualizado, fácil aprovisionamiento y agilidad extrema para la nube optimizada y entornos virtuales Opción de aumento de rendimiento adicional a través del manejo libre de almacenamiento en caché SSD Alta fiabilidad y disponibilidad a través de la redundancia completa, velocidad de reconstrucción sin precedentes TCO bajo permitido por el almacenamiento de alta densidad, la planificación simplificada, las características de la gratuidad y la gestión bajo-touch [47]. G.6. Soporte para colas El bus de Integración de IBM (antes conocido como WebSphere Message Broker) es un bus de servicios empresariales (ESB) que proporciona conectividad y transformación de datos universal para la arquitectura orientada 222 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

73 a servicios (SOA) y entornos no SOA. Ahora las empresas de cualquier tamaño 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 integración para satisfacer las necesidades de cualquier tamaño de proyecto. Ayudar a toda su organización a tomar decisiones más inteligentes de negocios, proporcionando un rápido acceso, visibilidad y el control sobre los datos que fluyen a través de sus aplicaciones empresariales y sistemas. Conectar toda una serie de aplicaciones heterogéneas 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 integración 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 gestión para lograr una computación inteligente. Un componente integral de la cartera de Sistemas de IBM, IBM Systems Director permite la integration con Tivoli y plataformas de gestión de terceros, proviendo componentse para los servicios de gestión integrados. Con Systems Director puede: Automatizar las operaciones del centro de datos mediante la implementación de infraestructuras virtuales cloud-ready Unificar la gestión de los recursos físicos y virtuales, almacenamiento y redes, para los servidores IBM Simplificar la gestión de los sistemas optimizados Lograr una visión única de la utilización real de energía a través de su centro de datos Gestión del ciclo de vida simple de las cargas de trabajo con un uso intuitivo y reducción de la complejidad - IBM Systems Director ofrece una plataforma unificada integral de gestión de sistemas. Proporciona herramientas para el descubrimiento, el inventario, el estado, la configuración, notificación de eventos de salud del sistema, monitoreo de los recursos, actualizaciones del sistema y la automatización de la gestión. Integración - Tivoli y plataformas de gestión de terceros proporcionan la base para la gestión integrada de los servicios de virtualización. Con una amplia gama de tareas disponibles en la plataforma de gestión y las herramientas automatizadas, Director asiste al personal de gestión 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 drásticamente el número de herramientas de gestión e interfaces, simplificando la forma en que los administradores de TI realizan sus tareas, y la liberación de su tiempo para satisfacer las cambiantes necesidades del negocio [49]. IBM Systems Director VMControl: gestión de infraestructuras físicas y virtuales lista parra la nube. IBM Systems Director VMControl le ayuda a obtener más de la infraestructura de virtualización, con una gestión lista para la nube. La combinación 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 gestión, aumentando la utilización de activos, y la vinculación de rendimiento de la infraestructura de los objetivos de negocio [49]. VMControl simplifica la gestión de los entornos virtuales a través de múltiples tecnologías de virtualización y plataformas de hardware. VMControl es una solución de gestión de virtualización multi-plataforma líder 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. Características destacadas Reúne la gestión física y virtual en una interfaz única para reducir la complejidad Ofrece una inigualable plataforma cruzada para la gestión de múltiples sistemas operativos, lo que ayuda a mejorar la prestación de servicios mediante la eliminación de silos aislados de virtualización en entornos heterogéneos. Proporciona un "time-to-value" más rápido, y una mayor agilidad del negocio a través de la gestión de la virtualización simplificada que permite una utilización más eficaz de los recursos virtualizados. Establece una precisión y consistencia repetibles gracias a la automatización. Reduce los costos operativos y de infraestructura a través de una mayor eficiencia y utilización 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 próxima generación y escalabilidad elástica [50]. El Software de IBM WebSphere extreme Scale proporciona un marco caché escalable de alto rendimiento y tecnología de redes. WebSphere extreme Scale proporciona una mayor calidad de servicio en entornos de computación de alto rendimiento a través de "caching elástico". El Caching elástico mejora el rendimiento y la rentabilidad de la inversión [50]. WebSphere extreme Scale es una herramienta esencial para la escalabilidad elástica y ofrece estos valiosos beneficios: Procesa grandes volúmenes de transacciones con extrema eficiencia y escalabilidad lineal. Construye rápidamente una rejilla elástica transparente, flexible y de alta disponibilidad que escala acorde a las necesidades de las aplicaciones, eliminando los límites de rendimiento de la base de datos. Proporciona alta disponibilidad y seguridad con copias redundantes de datos de la caché. Dispone de esquemas de autenticación 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 inglés "Total cost of ownership", por sus siglas TCO) [50]. Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN

74 H. VMware VCloud Suite H.1. Descripción La virtualización ha reducido los costos de IT dramáticamente, mejorando la eficiencia en gran medida. Ahora las unidades de negocio necesitan un acceso rápido a los recursos de IT para lograr mayor eficiencia en el "time to market" de los proyectos. VMware vcloud Suite es una solución de infraestructura integral y completa que simplifica las operaciones de IT ofreciendo mejores SLAs para las aplicaciones. Ayuda además a mejorar la agilidad, la eficiencia y a realizar una gestión inteligente de la administración de operaciones de computación en la nube [51]. Qué es VMware vcloud Suite?: La virtualización de VMware ha ayudado a los clientes a reducir drásticamente los gastos de capital gracias a la consolidación de servidores. Ha mejorado los gastos de explotación mediante la automatización y ha minimizado la pérdida de ingresos porque reduce el tiempo de inactividad, planificado y no planificado. Sin embargo, las empresas actuales también necesitan reducir el tiempo de comercialización de sus productos y servicios. Las unidades de negocio exigen acceso rápido a los recursos de TI y a las aplicaciones. Se presenta a continuación (Figura 4), la solución para la nube propuesta por VMware, y también un cuadro que define las responsabilidades de cada uno de los productos para la gestión e infraestructura de la nube (Figura 5) [52]. vcloud Suite incluye VMware vcloud Automation Center, que introduce un potente modelo de aprovisionamiento de servicios de TI gestionados en régimen de autoservicio a través de un portal seguro y fácil de usar controlado mediante políticas. Las redes definidas por software permiten a las máquinas virtuales de una cloud de VMware utilizar los recursos en cualquier lugar del centro de datos, sin importar los límites de las redes. Además, con VMware vcloud Connector, el equipo de TI puede estar preparado para una demanda inesperada, recurriendo a clouds públicas de confianza, fuera de sus instalaciones, basadas en VMware cuando sea preciso [52]. Fig. 5. Responsabilidades de productos [52]. Fig. 4. Solución completa e integrada en la nube [52]. H.2. Características Principales H.2.1. Agilice el acceso a los recursos y a las aplicaciones vcloud Suite permite a los técnicos de TI prestar servicios de TI controlados por políticas en régimen de autoservicio, así como aprovisionar máquinas virtuales y aplicaciones de múltiples niveles en solo unos minutos. Además, amplía la capacidad disponible para las unidades de negocio tanto de forma interna como externa. H.2.2. Simplifique y automatice la gestión de operaciones A medida que el centro de datos se convierte en una cloud privada o híbrida, la gestión 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 planificación inteligente de la capacidad, solución automatizada de los problemas de rendimiento y gestión continua del cumplimiento normativo. vcloud Suite incluye las completas prestaciones de gestión de TI de vcenter Operations Management. La supervisión del rendimiento y las alertas proactivas garantizan que el departamento de TI pueda reaccionar a los desafíos de cumplimiento de los acuerdos de nivel de servicio en la cloud antes de que lleguen a afectar al negocio [52]. 224 Franco Bocchio, Estudio Comparativo de plataformas Cloud Computing para Arquitecturas SOA. Revista Latinoamericana de Ingeniería de Software, 1(5): , ISSN