Proceedings Latin American Congress on Requirements Engineering & Software Testing

LACREST MEDELLN 2012 Copyright 2012 LACREST

Except where otherwise noted, content in this publication is licensed under the Creative Commons Attribution, NonCommercial, ShareAlike 3.0 Unported License, available at http://creativecommons.org/licenses/by-sa/3.0 As for readers, this license allows users to download, copy and build upon published chapters even for commercial purposes, as long as the author and publisher are properly credited, which ensures maximum dissemination and a wider impact of our publications. Notice Statements and opinions expressed in the papers are these of the individual contributors and not necessarily those of the editors or publisher. No responsibility is accepted for the accuracy of information contained in the published papers. The publisher assumes no responsibility for any damage or injury to persons or property arising out of the use of any materials, instructions, methods or ideas contained in the book. A free online edition of this book is available at www.lacrest.org

Edicin, Julio de 2012 ISBN 978-958-46-0577-1

Latin American Congress on Requirements Engineering & Software Testing www.lacrest.org lacrest2012@lacrest.org

Medelln Antioquia Colombia

LACREST MEDELLN 2012

COMIT ORGANIZADOR
Edgar Serna M. Miguel Buitrago B. William A. Arvalo C. Luis Fernando Vargas C. Fernando Arango I. Rosalba Rios Galvis Director General LACREST Instituto Antioqueo de Investigacin - IAI Director Ejecutivo LACREST MEDELLN 2012 Centro de Ingeniera de Software - CEIS Director I+D LACREST MEDELLN 2012 Centro de Investigacin y desarrollo de Nuevas Tecnologas - CIDENET Director LACREST MEDELLN 2012 Universidad Cooperativa de Colombia Director Cientfico LACREST MEDELLN 2012 Universidad Nacional de Colombia Directora Acadmica LACREST MEDELLN 2012 Corporacin Universitaria Remington

COMIT CIENTFICO
Dr. Gustavo Rodrguez G. Dr. Miguel Buitrago B. Dr. Javier Jess Gutirrez R. Dr. Libardo A. Londoo C. Dra. Mara Jos Escalona C. Licda. Lydia de Toppin Dra. Elsa Estevez Dr. Jorge A. Villalobos S. Dr. Clifton E. Clunie B. Dr. Antonio R. Castro L. Dr. John Willian Branch B. Dr. Oscar Pastor Lpez Dr. Jos Antonio Pow-Sang P. Dr. Ljubo Vlacic Dra. Ana M. Moreno Dr. Jons A. Montilva C. Dr. Ramn Garca-Martnez Dr. Jaime Navon Cohen Dr. ric Adrien Filiol Dr. Oscar Dieste Dr. Jovani A. Jimnez B. Dr. Jos A. Calvo-Manzano Dr. George Spanoudakis Dra. Patricia Osorio A. Dra. Gloria P. Gasca H. Dra. Raquel Anaya H. Instituto Nacional de Astrofsica, ptica y Electrnica, Mxico. CEO Sequal S.A., Colombia. Universidad de Sevilla, Espaa. Politcnico Colombiano Jaime Isaza Cadavid, Colombia. Universidad de Sevilla, Espaa. Universidad Tecnolgica de Panam, Panam. United Nations University, Argentina. Universidad de los Andes, Colombia. Universidad Tecnolgica de Panam, Panam. Universidad Tecnolgica Nacional, Argentina. Universidad Nacional de Colombia sede Medelln, Colombia. Universidad Politcnica de Valencia, Espaa. Pontificia Universidad Catlica del Per, Per. Griffith University, Australia. Universidad Politcnica de Madrid, Espaa. Universidad de Los Andes, Venezuela. Universidad Nacional de Lans, Argentina. Pontificia Universidad Catlica de Chile, Chile. cole Suprieure d'informatique, lectronique et automatique, Francia. Universidad Politcnica de Madrid, Espaa. Universidad Nacional de Colombia sede Medelln, Colombia. Universidad Politcnica de Madrid, Espaa. City University London, United Kingdom. CasodePrueba, Colombia. Universidad de Medelln, Colombia. Universidad Eafit, Colombia.

POR LA PROFESIONALIZACIN DEL DESARROLLO DE SOFTWARE

CONTENIDO
PRESENTACIN PONENCIAS Los procesos de gestin en la Ingeniera de Requisitos segn la gua del PMBOK
Luis A. Esteban V., William M. Rojas C.

6 7 8 14 23 29 38 46 53 62 67 73 81 89 95 104 110 116 120 128 129 130 137 140 146

Conceptualizacin de Requerimientos: Propuesta de Proceso y Tcnicas Asociadas Variabilidad del Comportamiento de Agrupamiento e Induccin Basado en las Caractersticas del Dominio

Alejandro Hossian, Ramn Garca-Martnez, Oscar Dieste Marcelo Lpez N., Ramn Garca-Martnez

Comparacin de Mtricas de Estimacin para Proyectos de Explotacin de Informacin Modelo de proceso para elicitacin de requerimientos en proyectos de explotacin de informacin

Pablo Pytel, Ramn Garca-Martnez, Paola Britos

Diego Mansilla, Florencia Pollo-Cattaneo, Ramn Garca-Martnez, Paola Britos, Patricia Pesado

Un Modelo de Procesos para Proyectos de Explotacin de Informacin

Juan A. Vanrell, Ramn Garca-Martnez, Rodolfo Bertone Juan B. Quintero, Diana M. Hernndez, Pamela Rucinque

Catlogo de anti-patrones al especificar requisitos funcionales usando casos de uso

Heydi Menndez A., Yanetsi Millet L., Aniubis Rodrguez B. Yadira Machado P., Odelky Betancourt G., Surima G P., Mairelis Quintero R., Yailin Fundora C.

Pruebas basadas en riesgos

Propuesta de estrategia para la ejecucin de pruebas funcionales

Metodologa para ensear a asegurar la calidad del software a travs de tcnicas de verificacin y validacin

Gabriela Salazar B.

Integracin de Redmine y Subversion en la construccin de una plataforma para la prueba de proyectos software
Guillermo E. Murillo G., Gabriela Salazar B.

Razonamiento Basado en Casos para Inferir el Comportamiento de una Prueba de Liberacin de Productos Software Una experiencia de aseguramiento de la calidad en una Unidad de Sistemas Elicitacin de requisitos desde la perspectiva del diseo de producto Metodologa de Ejecucin del Plan de Pruebas de Software basado en la gua PMBOK
Marcelo Jenkins, Alexandra Martnez, Gustavo Lpez

Heney Daz P., Daira Prez S.

Ricardo Meja G., Alejandro Clad A., Daniel Zuluaga H. Luz E. Valencia, Jorge L. Suarez, Anglica M. Cardona

Comparativo para la fase de anlisis de requisitos entre un mtodo de desarrollo de software tradicional vs la incorporacin de BPM
Luis Merchn P., Diego A. Gmez M., Eunice Borja O., Mara E. Flrez O., Paola A. Torres L.

Un Vistazo al Testing de la Seguridad en Aplicaciones y Servicios Web: Opciones Libres

Luis E. Melndez C.

CONFERENCIAS Usabilidad y Mtodos giles: Debate y Vas de Integracin Participacin de Agentes en los Procesos de Ingeniera, determinada por RNFs

Ana M. Moreno

Germn Urrego G., Gloria L. Giraldo G.

De Requisitos a Cdigo: Desarrollo de Software Dirigido por Modelos en Prctica Reusing Formal Proofs Through Isomorphisms

scar Pastor Lpez, Marcela Ruiz, Sergio Espaa Mauricio Ayala-Rincn

Verificacin y Validacin independiente para asegurar mayor confianza en el software que controla sistemas crticos
Patricia Rodrguez Dapena

PRESENTACIN
En un entorno altamente interactivo como Internet, los temas de investigacin en Ingeniera de Requisitos y Software Testing varan en funcin del desarrollo de nuevas tecnologas y modos de interaccin en la comunidad del conocimiento, el cual, debido al progreso de las tecnologas mviles y la Web 2.0, es mucho ms rpido de transferir, almacenar y recuperar. Esas tecnologas y modos cada vez son ms diversos, al mismo tiempo que los tipos de comunidades en lnea con altos niveles de interaccin son cada vez ms multidimensionales. Para optimizar el rendimiento organizacional y para promover an ms la innovacin y la gestin del conocimiento alrededor de estas dos reas, se requieren estrategias nuevas y ms amplias para intercambiar saberes dentro y entre esas comunidades. En aos recientes, ha habido nuevos y sorprendentes aportes y descubrimientos que soportan las teoras, los mtodos y los modelos de la Ingeniera de Requisitos y del Software Testing. Igualmente, se han presentado tecnologas y herramientas innovadoras relacionadas con la gestin del conocimiento en ambos campos. Estas tendencias hablan de la importancia de los estudios acerca de ellos y del impacto para la Sociedad de la Informacin y del Conocimiento; adems, esos estudios amplan cada vez ms su influencia en aplicaciones multidisciplinares. Pero, dado el dinamismo de la investigacin se espera ms y mejores progresos para los aos venideros. Comprender, aportar y difundir estos temas de investigacin ayudar al desarrollo de nuevas aplicaciones desde lo acadmico y lo prctico que soportarn y darn mayor valor al principio de la profesionalizacin del desarrollo de software. La comunidad que investiga necesita espacios para presentar, analizar y discutir sus aportes, idea que dio origen al congreso que hoy nos convoca y que proyectaremos en busca de alcanzar una comunidad unidad y fortalecida, que tenga como objetivo responder a las exigencias sociales de productos software de mayor calidad y seguridad. Este libro contiene las ponencias y conferencias que se presentaron en el Latin American Congress on Requirements Engineering & Software Testing LACREST MEDELLN 2012, en la ciudad de Medelln Colombia. Esperamos que proporcione informacin relevante sobre las tendencias de la investigacin de la comunidad y que se pueda integrar de forma novedosa al conocimiento existente. El objetivo es que la informacin que contiene sirva como un importante recurso para investigadores, profesores y estudiantes y que promueva el trabajo acadmico y el desarrollo de nuevas prcticas en los campos de la Ingeniera de requisitos y del Software Testing.
Director General LACREST

Edgar Serna M.

PONENCIAS

Management processes in the Requirements Engineering as the PMBOK guide Los procesos de gestin en la Ingeniera de Requisitos segn la gua del PMBOK
Luis A. Esteban V.1, William M. Rojas C.2
1

Universidad de Pamplona, Grupo de Investigacin en Ciencias Computacionales. Pamplona, Colombia. lesteban@unipamplona.edu.co, 2 mrojas@unipamplona.edu.co ABSTRACT This paper show an analysis of management processes defined in PMBOK Guide version 4, directly related to requirements engineering and adapted to software development projects. RESUMEN En este artculo se presenta un anlisis de los procesos de gestin definidos en la cuarta versin de la gua del PMBOK, relacionados con la ingeniera de requisitos y adaptados a proyectos de desarrollo de software.

INFORMACIN DEL ARTCULO Tipo de artculo: Reflexin Historia del artculo: Recibido: 30/03/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Gua del PMBOK, recoleccin de requisitos, procesos de gestin. Categories and Subject Descriptors D.2.1 [Requirements/Specifications]: Tools. General Terms Software Engineering, Requirements Engineering. Keywords PMBOK guide, requirement elicitation, management processes.

1. INTRODUCCIN La gua del PMBOK [9] diseada por el PMI, ha sido de gran importancia para la gestin de todo tipo de proyectos, por lo cual tambin puede ser adaptada para proyectos de desarrollo de software. De otro lado las metodologas de desarrollo de software plantean actividades de gestin, pero se pueden complementar o sustituir dichas actividades por las definidas en los procesos de gestin de la gua del PMBOK, agregando valor al proceso de desarrollo [7]. Dentro de los cambios significativos realizados a la gua entre la tercera y cuarta versin [9], estn los procesos relacionados con la gestin de requisitos, incluyendo como nuevos procesos, la identificacin de los stakeholders y la recoleccin de requisitos. Esto puede ser interpretado como un reconocimiento a la Ingeniera de Requisitos como clave en el desarrollo de proyectos. En este artculo se hace un anlisis de los procesos de gestin de la gua del PMBOK relacionados directamente con los conceptos del rea de conocimiento de Requisitos de Software [4] dentro de la gua para el cuerpo de conocimiento de la Ingeniera del software (Gua para el SWEBOK) [10]. En la primera parte se presentan algunos conceptos generales sobre la gua del PMBOK, haciendo una interpretacin de su estructura y describiendo un posible orden en la ejecucin de los procesos segn los

cinco grupos de procesos. La segunda parte resalta los procesos de la gua que tienen que ver directamente con la captura, anlisis, documentacin y seguimiento de requisitos. La tercera parte presenta algunas conclusiones relacionadas con la importancia de las actividades de gestin de requisitos, dentro de los procesos de desarrollo de software. 2. LA GUA DEL PMBOK El cuerpo de conocimiento BOK Body Of Knowledge de una ciencia o una disciplina, est conformado por toda la informacin existente alrededor de dicho dominio, esto incluye libros, artculos, investigaciones, publicaciones en eventos y cualquier otro tipo de contenedor de informacin al respecto. Esto supone que cualquier cuerpo de conocimiento dispone de grandes volmenes de informacin, distribuida en todo el mundo y producida por profesionales que tienen su inters en dicha disciplina. Algunos organismos lderes mundiales en algunas disciplinas, entre las cuales se encuentra la Ingeniera del software y la gestin de proyectos, han dedicado gran esfuerzo en la recopilacin de informacin que permita estructurar estos grandes volmenes de informacin de una disciplina, en guas para el cuerpo de conocimiento (Figura 1), los cuales son documentos relativamente breves que intentan recopilar los conceptos comnmente aceptados en la disciplina y organizados por reas de conocimiento.

Gua para el BOK

Estructura el

rea n

Necesidades

Libros Artculos Documentales Experiencias Investigaciones Guas

G2

G2 T1

Gi Tj

Proceso

Gj Tj

rea 1
Conforman

rea 3

G0 T0 Ti T2

Gj Tn

rea 2

Gm

Producto o servicio nico

Conceptos y prcticas pr comnmente com aceptadas en la disciplina

Personal

Cuerpo de Conocimiento BOK

Tj

Tj

.... --

Producen, utilizan

Fig. 1: Los cuerpos de conocimiento (BOK)

Producto

Personas

.... --

.... --

.... --

.... --

G0

Necesidades

G G1 G

Ejecucin
G Gi Gi Gj Gj

Gi Gm

A diferencia de otras guas para el cuerpo de conocimiento, la gua para el PMBOK, tiene dos enfoques: El primer enfoque es el tpico en otras guas de otros cuerpos de conocimiento, y se trata de dividir los conceptos fundamentales de la disciplina en reas de conocimiento, lo que permite estructurar la informacin. El segundo enfoque, que no tienen las dems guas, es como metodologa de gestin de proyectos, para lo cual organiza los procesos de direccin en cinco grupos de procesos y cuarenta y dos procesos organizados en dichos grupos.
Por reas de Conocimiento
PMBOK
Gestin de Integracin Gestin de Alcance Gestin de Tiempos Gestin de Costes Gestin de Calidad Gestin de Recursos Humanos Gestin Comunicaciones Gestin de Riesgos Gestin de Adquisiciones

8 procesos de Ejecucin

10 procesos de Seguimiento y control del proyecto

20 procesos de Planificacin 2 procesos de inicio

Gua para el PMBOK V4

2 procesos de cierre

Fig. 4: Procesos de Gestin organizados por grupos

a Gu

Por grupos de Procesos

Procesos de Inicio Procesos de Planificacin Procesos de Ejecucin Procesos de Seguimiento y control Procesos de Cierre

Estos procesos de gestin dentro de proyectos de desarrollo de software son pertinentes dentro de los alcances de la Ingeniera del software [2, 10], por lo que pueden ser estudiados como mtodos, herramientas y tcnicas para proyectos de desarrollo de software. Si se utiliza la gua del PMBOK, como metodologa para la direccin del proyecto, se combinan de manera organizada las actividades tcnicas y de gestin en una sola estructura organizada para el proyecto, como se muestra en la Figura 5.
Procesos de la gua del PMBOK
Procesos Iniciales Procesos de Planificacin

Procesos Propios del desarrollo de software como producto del proyecto

Fig. 2: Los dos enfoques de la gua PMBOK

Un proyecto es definido en esta gua como Esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado nico [9] y este esfuerzo se puede traducir como un conjunto de actividades (proceso), ejecutadas por personas (personal), que utilizan herramientas (tecnologa), para generar artefactos (producto) propios de la gestin y elaboracin del producto o servicio nico, motivo del proyecto. Esto puede ser representado como se muestra en la Figura 3. Las actividades que constituyen el proceso del proyecto, pueden ser clasificadas en dos grandes grupos: Actividades de Gestin (representadas con la letra G) y Actividades Tcnicas (representadas con la letra T). Separando las actividades de gestin de las actividades tcnicas en un proyecto, la gua del PMBOK organiza estas actividades de gestin en cinco grupos de procesos y cuarenta y dos procesos [9] (Figura 4).

Estructura de desglose de trabajo del producto Procesos de control Procesos de ejecucin

Procesos de cierre

Fig. 5: Procesos de Gestin y tcnicos en un proyecto

Visto de manera integrada se puede representar como se muestra en la Figura 6. Las actividades de gestin son determinadas y organizadas segn la gua del PMBOK, mientras que las actividades Tcnicas en el desarrollo de software son guiadas por la metodologa de desarrollo de software utilizada en el proyecto.

Producto o servicio nico

La gestin de proyectos como disciplina, tiene su gua para el cuerpo de conocimiento, elaborada por el PMI, y ampliamente utilizada como herramienta para la direccin de proyectos de cualquier tipo, por lo que se puede adaptar a proyectos de desarrollo de software, complementando o sustituyendo las actividades de gestin propuestas por cada una de las metodologas de desarrollo de software [7].

Tecnologa
Tiempo

Fig. 3: Estructura de un Proyecto

Inicio de proyecto una vez aprobado Organizacin y preparacin del trabajo Terminacin del proyecto

Realizacin del trabajo

inicio

Seguimiento y control Planificacin

G Gi Gi Gi Gi

Cierre

inicio

Seguimiento y control Planificacin

G G G Gi Gi Gi Gi

Cierre

Ejecucin
Gi Gi Gj Gj

Necesidades

G0 G G

Gm

Actividades propias del desarrollo de software motivo del proyecto

T0

Ti T T T Tj

Tj Tj

Tj

Tn Tj

Ti T

Tj

Tj

Producto software final

Gi

Procesos de Ejecucin Dirigir y Gestionar la Ejecucin del Proyecto Realizar Aseguramiento de Calidad Adquirir el Equipo del Proyecto Desarrollar el Equipo del Proyecto Dirigir el Equipo del Proyecto Distribuir la Informacin Gestionar las Expectativas de los Interesados Efectuar Adquisiciones Procesos de Seguimiento y Control Hacer Seguimiento y Controlar el Trabajo del Proyecto Realizar Control Integrado de Cambios Verificar el Alcance Controlar el Alcance Controlar el Cronograma Controlar Costos Realizar Control de Calidad Informar el Desempeo Dar seguimiento y Controlar Riesgos Administrar las Adquisiciones Procesos de Cierre Cerrar el Proyecto Cerrar las Adquisiciones Los siguientes procesos hacen parte de lo que se podra llamar la gestin de las actividades tcnicas de la ingeniera de requisitos en proyectos de desarrollo de software. 3.1 Desarrollar el Project Charter La gua del SWEBOK [10], define dentro del rea de conocimiento de requisitos de software, las siguientes fuentes de requisitos: Stakeholders. El ambiente operacional. Objetivos (factores crticos de xito) se refiere a los objetivos de alto nivel del software. Conocimiento del dominio de aplicacin. El ambiente organizacional. Es por lo tanto el Project Charter, una fuente importante para los procesos de requisitos en proyectos de software, debido a que all se consignan de manera resumida esta parte de esta informacin, entre la cual se pueden resaltar los objetivos del producto software a desarrollar, el contexto de la aplicacin (dominio), un listado inicial de stakeholders y las caractersticas del sistema en el cual estar inmerso el producto a desarrollar. Los objetivos de un proyecto pueden definirse en trminos de las cuatro variables tpicas de un proyecto: Costo, Calidad, Alcance y Tiempos, como se observa en la Figura 7. Aunque los objetivos del proyecto relacionados con requisitos estn concentrados en el factor de Alcance, es tambin importante tener en cuenta que de alguna manera directa o indirecta, repercuten sobre las otras tres variables.

PMBOK

Estructura de desglose de trabajo definida por la metodologa de desarrollo de software

Fig. 6: Los procesos de gestin y tcnicos integrados

En proyectos de desarrollo de software [8], las actividades relacionadas con requisitos se distribuyen por todo el proyecto, tanto en el grupo de actividades de gestin, con en las actividades tcnicas. En este artculo se hace un anlisis de los procesos de gestin que estn relacionados con los conceptos tcnicos de requisitos, en proyectos de desarrollo de software. 3. PROCESOS DE GESTIN RELACIONADOS CON REQUISITOS Para proyectos de desarrollo de software, existen metodologas propias para su gestin, incluida la gestin giles de proyectos de desarrollo de software [3], sin embargo en este artculo se hace nfasis en la utilizacin de la gua del PMBOK como metodologa de gestin de proyectos. La gua del PMBOK en su cuarta edicin, define los siguientes cuarenta y dos procesos, organizados en los cinco grupos de procesos [9]: Procesos de Inicio Desarrollar el Project Charter Identificar los Stakeholders (Involucrados) Procesos de Planificacin Recolectar Requisitos Definir el Alcance Crear la EDT (estructura de desglose de trabajo) Definir las Actividades Secuenciar las Actividades Estimar la Duracin de las Actividades Estimar los Recursos de las Actividades Desarrollar el Cronograma Estimar Costos Determinar el Presupuesto Desarrollar el Plan de Recursos Humanos Planificar la Gestin de Riesgos Identificar Riesgos Realizar Anlisis Cualitativo de Riesgos Planificar la Respuesta a los Riesgos Realizar Anlisis Cuantitativos de Riesgos Planificar las Adquisiciones Planificar la Calidad Planificar las Comunicaciones Desarrollar el Plan de Gestin del Proyecto

10

Pesos, dolares, etc

Costo

S1

Impacto

Alto

Alto

S6

Poder

Bajo

Bajo

Los requerimientos hacen parte de la definicin de alcance de un proyecto

S2

S3

S7

S6

S3

S9

S2 S5 S8

S1 S4

S5 S8

S4 S9

S7

rea del triangulo

Alcance

Baja

Alta

Baja

Alta

Influencia
A favor

Influencia

Calidad

+
Aos, meses, das

S2

S9

S7

Tiempo

Inters

Fig. 7: Cuatro Variables tpicas en todo proyecto

Normal

S1 S3 S8 S6

Un prototipo de Project charter para un proyecto de software puede tener la siguiente estructura: Descripcin del proyecto. Definicin del producto del proyecto. Definicin de requisitos del proyecto. Objetivos del proyecto. Finalidad del proyecto. Justificacin del proyecto. Designacin del Project manager del proyecto. Cronograma de hitos del proyecto. Organizaciones que intervienen en el proyecto. Riesgos negativos del proyecto. Riesgos positivos del proyecto. Presupuesto preliminar del proyecto. Patrocinador que autoriza el proyecto.

En contra

S5

S4

Bajo

Medio

Alto

Poder

Fig. 8: Anlisis de stakeholders

Influencia vs Impacto: permite clasificar cada uno de los stakeholders del proyecto (Sn), de acuerdo al involucramiento activo en el proyecto (influencia) y la capacidad para realizar cambios en los requisitos (impacto). Influencia vs poder: entendido el poder como el nivel de autoridad o capacidad para tomar decisiones. Poder vs Intereses: entendido los intereses como la preocupacin o conveniencia sobre los requisitos del producto. Estas formas de clasificacin permiten la definicin de estrategias para facilitar la captura de los requisitos y la gestin de expectativas durante el desarrollo tcnico de la captura, anlisis, especificacin y validacin de los requisitos de un proyecto. Durante este proceso se genera un registro y una lista por roles de stakeholders. El registro se debe estructurar en tres segmentos: Identificacin (nombre, empresa, ubicacin, rol, informacin de contacto), evaluacin (requisitos, influencia potencial) y clasificacin (interno-externo, apoyo-neutral-opositor). La lista por roles debe estar estructurada con el rol y la instancia del rol que lo va a desempear. 3.3 Recolectar requisitos Este proceso aunque en proyectos de desarrollo de software es considerado un proceso tcnico (para el cual existen tcnicas de captura), y que casi siempre es iterativo durante todo el proyecto, la gua del PMBOK lo define como el primero de los procesos de planificacin del proyecto y consiste en recoger la informacin de cada uno de los stakeholders respecto a sus necesidades y requisitos tanto del proceso como del producto, suficientes y necesarios para definir el alcance del proyecto y su correspondiente Estructura de Desglose de Trabajo (EDT). Por lo tanto no se refiere a las actividades tcnicas de captura, anlisis, especificacin y validacin de requisitos que normalmente se llevan a cabo con herramientas y

3.2 Identificar stakeholders En este proceso se elabora un listado de los involucrados dentro del proyecto de desarrollo de software, esto incluye no solo al equipo de trabajo sino a cualquier otra persona u organizacin que participa en el proyecto o que se ve afectado de manera positiva o negativa por el producto generado por el proyecto. Por otro lado la gua del SWEBOK define como actores del proceso de requisitos, los roles de las personas que participan en un proceso de requisitos: Usuarios, Clientes, Analistas de mercado, Reguladores, Ingenieros de software, entre otros. Estos actores hacen parte del listado de involucrados segn la Gua del PMBOK. En proyectos de desarrollo de software este listado de involucrados puede ser construido utilizando como criterio, quienes tienen algn requisito de software como necesidad a satisfacer. Si una persona u organizacin tiene algn requisito del producto a desarrollar, esta pasa directamente a ser parte de los stakeholders del proyecto. Cada uno debe ser registrado con alguna informacin complementaria como: rol que desempeara en el proyecto, requisitos primordiales, expectativas principales, influencia potencial, fase del proyecto de mayor inters, clasificacin segn sea interno o externo, de apoyo o neutral u opositor. Esta informacin facilita realizar anlisis sobre los involucrados mediante su clasificacin desde diversos factores como los representados en la Figura 8.

11

tcnicas propias del desarrollo de software, durante varias veces (de manera iterativa) dentro del proyecto y no solo en la fase de planificacin. Sin embargo este proceso de gestin es de relevante importancia en la medida que permite identificar las caractersticas del producto relevantes tanto para organizar el trabajo como para definir una arquitectura inicial del producto software. De igual forma es en este proceso donde se definen los atributos que complementan la descripcin del requisito entre los cuales estn: sustento de su inclusin, propietario, fuente, prioridad, versin, estado actual (activo, cancelado, diferido, adicionado, aprobado) fecha de cumplimiento, nivel de estabilidad (alto, medio, bajo) grado de complejidad (alta, media, baja), criterio de aceptacin, entre otros que pueden ser considerados relevantes para el proyecto. Este proceso de gestin facilita la trazabilidad del requisito durante la etapa de ejecucin, seguimiento y control. La clasificacin de stakeholders anteriormente descrita, permitir aqu, definir tcnicas de captura aplicables a cada grupo, de igual manera podr ser utilizada para resolver conflictos entre requisitos, dado que las variables influencia, poder e intereses pueden definir estrategias como reglas para la solucin de conflictos. En este proceso se debe generar un documento de requisitos que tiene las siguientes secciones: Necesidad del negocio Objetivos del negocio Requisitos funcionales Requisitos no funcionales Requisitos de calidad Criterios de aceptacin Impacto en otras dependencias internas y externas Supuestos y restricciones

3.5 Crear la estructura de divisin del trabajo (EDT) La recoleccin de requisitos en una fase inicial de planificacin de un proyecto software y complementado con el proceso de definicin de alcance, son la principal entrada para el proceso de crear el EDT. Este EDT organiza las actividades tcnicas en paquetes de trabajo, de tal manera que se pueda ver una descomposicin jerrquica del producto, en subproductos o en fases de construccin del producto con el fin de disminuir el nivel de complejidad y facilitar la asignacin de paquetes a grupos pequeos de desarrolladores. En el artculo [7] se muestra algunos EDTs tpicos para algunas metodologas de desarrollo de software, derivados del proceso definido por cada metodologa y de los requisitos capturados y organizados, sobre los cuales se centrarn cada una de las iteraciones, entregas, o fases segn establece la metodologa. La Figura 9 representa la estructura de desglose de trabajo del desarrollo de un producto software, integrado con los procesos de gestin del PMBOK. Donde la estructura de desglose de trabajo se observa en el paquete de trabajo denominado Desarrollo con RUP que corresponde a la organizacin de actividades tcnicas de desarrollo de software en cuatro fases, y dentro de cada una de las fases, se observan las iteraciones que como bien se sabe, son dirigidas por casos de uso, y los casos de uso representan aqu un tipo de requisito. Por lo tanto son los requisitos parte indispensable para definir la EDT.

3.4 Definir el alcance El objetivo de este proceso consiste en determinar los subproductos tangibles que se entregarn como parte del producto final del proyecto. El alcance en un proyecto de desarrollo de software, puede definirse en trminos de los requisitos que debe satisfacer cada subproducto software. Gran parte de las metodologas de desarrollo de software como RUP [5], y las consideradas giles [6] como XP [1], FDD, SCRUM, entre otras, definen sus fases e iteraciones dirigidas por los requisitos, agrupados y organizados en paquetes que pueden constituir productos entregables parciales. La definicin de alcance por lo tanto organiza los requisitos y plantea posibles formas de configurar los procesos de las actividades tcnicas segn la metodologa de desarrollo seleccionada. Este proceso genera el scope statement: Alcance del producto (requisitos, caractersticas). Criterios de aceptacin del producto. Artefactos del proyecto. Exclusiones, restricciones y supuestos del proyecto.

Fig. 9: Estructura de un proyecto software con RUP y dirigido con la gua del PMBOK

3.6 Gestionar las expectativas de los interesados Este proceso dentro del grupo de procesos de ejecucin, contiene las actividades de planificacin iterativa durante el desarrollo del producto de las actividades de captura de requisitos, pues del continuo intercambio de informacin sobre el avance del proyecto a cada uno de los stakehoders, se puede obtener la retroalimentacin de la cual surgen nuevos requisitos, o se aclaran detalles de requisitos ya detectados. 3.7 Verificar el alcance El objetivo de este proceso consiste en revisar, los entregables definidos en el alcance, en trminos de aceptacin por parte de quien los recibe (en algunas

12

metodologas es el usuario del software) y por lo tanto se debe constar el cumplimiento de requisitos, segn han sido definidos y traducidos en trminos de productos entregables pro el proceso de definicin de alcance. Dentro del proceso se considera la modificacin de la matriz de rastreabilidad de requisitos Artefacto de gestin, construido inicialmente en la definicin del alcance, pues es mediante esta, que se permite registrar la culminacin a cabalidad de un requisito, o cualquiera de otros estados como activo, cancelado, diferido, adicionado, aprobado. 3.8 Controlar el alcance Este proceso es consecuente con el proceso de verificacin de alcance, en el sentido de que una vez detectadas variaciones respecto a lo planeado en la definicin de alcance, se toman medidas que permitan mantener el proyecto dentro de los lmites de costo, calidad, tiempo y alcance. Este proceso implica probablemente cambios en requisitos, o adicin de nuevos requisitos, producto de las medidas de control definidas para cada una de las situaciones. 3.9 Informar el desempeo Este proceso consiste en recopilar y distribuir la informacin sobre el estado del proyecto, las mediciones de avance y proyecciones en diferentes puntos del proyecto. En proyectos de desarrollo de software estos estados pueden definirse en trminos de los requisitos satisfechos hasta el momento del informe, y las proyecciones en trminos de tiempos de los requisitos restantes. 4. CONCLUSIONES La gua del PMBOK como herramienta para la direccin de proyectos, brinda el necesario y suficiente soporte para gestionar los requisitos durante todo el proceso de desarrollo de software, independiente de la metodologa de desarrollo seleccionada. La Figura 10 muestra los procesos relacionados directamente con la ingeniera de requisitos, definidos por la gua del PMBOK y su interaccin.
1. Desarrollar el Project Charter 3. Recoleccin de requisitos 7. Verificar Alcance 8. Controlar Alcance

Otros procesos de gestin definidos por la gua del PMBOK, tambin tienen alguna relacin con los proceso tcnicos de requisitos, y no son analizados en este artculo, pues corresponden a otras reas de conocimiento diferente a la de los requisitos de software, segn la gua del SWEBOK. Entre estos procesos se pueden identificar: Monitoreo y control del trabajo del proyecto, control integrado de cambios, control de cronograma, control de costos y control de calidad. 5. AGRADECIMIENTOS Al grupo de investigacin en Ciencias Computacionales de la Universidad de Pamplona que apoya el programa de Maestra en Gestin de proyectos Informticos, dentro de la cual la gua del PMBOK es estudiada y discutida junto con docentes y estudiantes del programa.
[1] Beck, K. 2002. Una explicacin de la programacin extrema: aceptar el cambio. Addison-Wesley Iberoamericana. [2] Cohen, D.; Lindvall, M. & Costa, P. 2003. Agile Software Development A DACS State-of-the-Art Report. Fraunhofer Center for Experimental Software Engineering Maryland and The University of Maryland. [3] Highsmith, J. 2004. Agile Project Management: Creating Innovative Products. Addison-Wesley Professional. [4] IEEE standard. 1990. IEEE Std 610.12-1990 Glossary of Software Engineering Terminology. IEEE Computers Society. [5] Jacobson, I.; Booch, G. & Rumbaugh, J. 1999. The Unified Software Development Process. Addison Wesley. [6] Larman, C. 2003. Agile and Iterative development: A managers guide. Addison Wesley. [7] Rojas, C. M.; Esteban, V. L. A. & Orjuela, D. A. 2011. Modelo de integracin de las actividades de gestin de la gua del PMBOK, con las actividades de ingeniera, en proyectos de desarrollo de software. Avances en Sistemas e Informtica, 8(2), 97-105. [8] McConnell, S. 1997. Desarrollo y gestin de proyectos informticos. McGraw Hill. [9] PMI. 2009. Gua de los fundamentos para la direccin de proyectos (Gua del PMBOK). Project Management Institute, Inc. [10] IEEE Computer Society. Guide to the Software Engineering Body of Knowledge SWEBOK, 2004 Version. Computer Society.

6. REFERENCIAS

inicio
G0

Seguimiento y control Planificacin

Necesidades

G G1 G

Ejecucin
G

2. Identificar los Stakeholders

5. Definicin de Alcance 5. Crear EDT

9. Informar Desempeo 6. Gestionar las expectativas de los Stakeholders

Fig. 10: Procesos de gestin directamente relacionados con los requisitos

Producto o servicio nico

Gi

Gi

Gj

Cierre

13

Conceptualization of Requirements: Proposal of Process and Associated Techniques Conceptualizacin de Requerimientos: Propuesta de Proceso y Tcnicas Asociadas
Alejandro Hossian1, Oscar Dieste2, Ramn Garca-Martnez3
1

Programa de Doctorado en Ciencias Informticas. UNLP y Grupo de Investigacin en Sistemas Inteligentes en Ingeniera. UTN-FRN, Neuqun, Argentina. alejandrohossian@yahoo.com.ar. 2 Grupo de Ingeniera de Software Emprica. Facultad de Informtica. Universidad Politcnica de Madrid. Madrid, Espaa. odieste@fi.upm.es. 3 Grupo de Investigacin en Sistemas de Informacin. Departamento de Desarrollo Productivo y Tecnolgico. Universidad Nacional de Lans. Buenos Aires, Argentina. rgarcia@unla.edu.ar. ABSTRACT The requirements elicitation process, whose main objective is to give birth to the requirements, not only is a technical process to build a particular system but also an important process of social connotations involving different people (stakeholders), a circumstance which causes certain problems arise when carrying out this process of requirement conceptualization. We propose a process of Requirements Conceptualization that are structured in two phases: (a) Problem-Oriented Analysis: aimed at understanding the problem given by the user in the domain in which this takes place, and (b) Product-Oriented Analysis: its aim is to obtain the functionalities that the user intends to obtain from the software product to be developed, taking into account the relationship of these features with the reality expressed by the user in his speech. The techniques for each activity in both phases are introduced. RESUMEN El proceso de captura de requisitos constituye un proceso con connotaciones sociales relacionadas con diferentes personas (stakeholders), una circunstancia que hace que ciertos problemas se presenten cuando se lleva adelante el proceso de conceptualizacin de requisitos. Se propone un proceso de conceptualizacin de requisitos que se estructura en dos fases: (a) Anlisis Orientado a al Problema: cuyo objetivo es comprender el problema dado por el usuario en el dominio en el que este se lleva a cabo, y (b) Anlisis de Orientado al Producto: cuyo objetivo es obtener las funcionalidades que el usuario espera del producto de software a desarrollar, teniendo en cuenta la relacin de estas con la realidad expresada por el usuario en su discurso. Se proponen seis tcnicas que articulan cada una de las tareas que componen las fases de proceso propuesto.

INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo Recibido: 23/04/2012 Correcciones: 29/05/2012 Aceptado: 31/05/2012 Palabras clave Requerimientos, proceso, tcnicas. conceptualizacin,

Categories and Subject Descriptors D.2.1 [Requirements/Specifications]: Methodologies. General Terms Software engineering, engineering requirements

Keywords Requirements, conceptualization, process, techniques.

1. INTRODUCCIN El proceso de educcin de requisitos, cuyo objetivo central consiste en dar a luz a los requisitos, no solo constituye un proceso de carcter tcnico para construir un determinado sistema, sino tambin un proceso con importantes connotaciones de tipo social [1] que involucra a distintas personas (stakeholders); circunstancia sta que origina que se presenten ciertos problemas a la hora de la realizacin de dicho proceso de educcin [2]. Asimismo, con respecto a los stakeholders cabe aclarar que dicho trmino se utiliza en referencia a cualquier persona o grupo que se ver afectado por el sistema en forma directa o indirecta; entre los mismos se pueden citar a usuarios finales que interactan con el sistema, as como tambin a dems personas que pueden verse afectadas por la puesta en marcha del mismo profesionales que proporcionan mantenimiento a otros sistemas relacionados, expertos en el dominio del sistema, gerentes de negocio, entre otros.

Los problemas citados anteriormente pueden ser enfocados en funcin de los inconvenientes a los que se ven enfrentados los ingenieros de requisitos a la hora de relevar y comprender los requisitos que manifiestan los diferentes stakeholders [3]. Estos problemas pueden ser sintetizados de la siguiente manera: En la mayora de los casos los stakeholders desconocen lo que desean obtener del sistema informtico, resultndoles difcil expresar cual es el problema que pretenden que sea resuelto y, en consecuencia, lo que deseen que haga el sistema. Por lo general, los stakeholders manifiestan sus requisitos con su propio lenguaje natural y con un conocimiento implcito de su propia labor. Por consiguiente, los ingenieros de requisitos, que en la generalidad de los casos carecen de la experiencia y el conocimiento en el dominio del usuario, deben comprender en forma correcta estos requisitos.

14

 Muy posiblemente, los diferentes stakeholders involucrados en la construccin del sistema posean diferentes requisitos, los cuales pueden ser expresados de varias formas distintas. Por consiguiente, los ingenieros deben tener en consideracin todas las posibles fuentes potenciales de requisitos y hallar coincidencias y conflictos. Tambin es posible que factores de carcter poltico tengan cierta influencia en los requisitos del sistema. A modo de ejemplo, un director de un cierto departamento puede solicitar requisitos del sistema a los efectos de tener mayor influencia en el seno de la organizacin. Continuando en esta lnea, por las razones expuestas se puede afirmar que el proceso de educcin es difcil de llevar a cabo. En este sentido, conforme a [4] y con idea de complementar los problemas expresados anteriormente, se estima conveniente aadir las siguientes consideraciones: Mucha informacin importante para la construccin del producto software no llega a ser verbalizada, quedando as plasmados importantes huecos en la informacin capturada. En la mayora de los casos el proceso de educcin se lleva a cabo en forma pasiva en relacin con el cliente y/o usuario, cuando en realidad debe ser afrontado en forma cooperativa. Ahora bien, en virtud del conjunto de limitaciones a las que hacen mencin Sommerville [1] y Christel [4], propias del proceso de educcin, es que surge la necesidad de explorar y analizar aquellas particularidades que son inherentes a este proceso y que, en tal sentido, contribuyen a caracterizarla. Caracterizada la tarea de educcin, se infiere que el eje de la misma se focaliza en la comunicacin que se establece entre el usuario y el Ingeniero de Requisitos (IR). Este, cuando desarrolla su trabajo de educcin, debe capturar y modelar una realidad que enmarca una problemtica, y cuya solucin, debe ser abordada a travs de un producto software. Siendo esta realidad un elemento intangible y, por lo general tambin compleja, es que tambin resulta difcil su captura. Ahora bien, la captura de esta realidad junto con su problemtica quedan plasmadas en el discurso del usuario, a partir del cual el IR debe confeccionar el universo de ese discurso (situaciones, hechos, objetos, entre otros., en los que se focaliza el estudio durante la educcin y que, en consecuencia, resultan ser sustanciales a la hora de abordar el desarrollo del futuro sistema software" [5]), a los efectos de poder alcanzar as los modelos conceptuales ya en la fase de anlisis de requisitos. Estos inconvenientes, propios del proceso de educcin, hacen que se dificulte la elaboracin del universo de

discurso por parte del IR, as como tambin la construccin de modelos conceptuales adecuados [6, 7]; es decir que estos problemas, que comienzan a manifestarse en el proceso de educcin de requisitos y a partir de la comunicacin entre el usuario y el IR, seguramente se propagarn en la actividad de construccin de los modelos conceptuales. Estos inconvenientes, confluirn de manera inexorable, hacia la obtencin de un software de baja calidad [8]. En este contexto, se describe el problema abordado (seccin 2), se propone un proceso de conceptualizacin de requisitos (seccin 3) y las tcnicas asociadas (seccin 4), se dan conclusiones y se sealan las futuras lneas de trabajo (seccin 5). 2. DESCRIPCIN DEL PROBLEMA El problema abierto que se identifica en la presente seccin, consiste en la necesidad de estructurar y categorizar la masa de informacin proveniente del proceso de educcin a los efectos de facilitar la comprensin del problema manifestado por el usuario [9, 10, 11]. En otros trminos, conceptualizar los requisitos. La insuficiencia en el tratamiento de la complejidad contenida en el discurso del usuario en la literatura correspondiente, y la necesidad de cubrirla, ha sido resaltada por diversos autores [2, 5, 9, 10, 1217]. Estos autores mencionan las dificultades para la construccin de los modelos conceptuales a partir de la informacin recogida en el proceso de educcin y plasmada en el discurso de usuario. Asimismo cabe resaltar, que dichas dificultades dotan al proceso de Anlisis de un grado tal de inmadurez que hace que sea difcil llevar a cabo en forma efectiva esta actividad, al mismo tiempo que dificulta la adopcin de este enfoque en las organizaciones [18]. Por consiguiente y en virtud de todo lo expuesto, el problema abierto que se aborda en este trabajo, consiste en una brecha conceptual, lo que se denomina un gap [3, 9, 12] en la transicin de un proceso (Educcin de Requisitos) a otro proceso (Modelado Conceptual). A causa de lo expuesto, se manifiesta la necesidad de conceptualizar los requisitos manifestados por el usuario en su discurso antes de pasar a la construccin de los modelos conceptuales, con el objeto de reducir la complejidad mencionada y favorecer la comprensin del problema planteado por el usuario, contribuyendo as a la obtencin de Modelos Conceptuales de mayor calidad [6, 19]. Asimismo, es importante sealar la muy escasa cantidad de trabajos referidos a la elaboracin de representaciones intermedias de los caudales de informacin obtenidos por el IR en el proceso de educcin. En otras palabras, trabajos que estn orientados a la bsqueda de reduccin de la complejidad de la realidad y su problemtica expresada por el usuario en su discurso. En este sentido, se pueden citar algunos principios fundamentales de estructuracin de la informacin Particin, Abstraccin y Proyeccin los cules proporcionan una

15

estructura de conocimiento a fin de contribuir a una visin simplificada de la realidad y su problemtica [9]. Si bien estos principios ofrecen su aporte a los efectos de precisar un mejor entendimiento de sus requisitos, son de carcter muy general y de poco nivel de detalle. 3. PROPUESTA PROCESO DE CONCEPTUALIZACIN DE REQUISITOS La solucin que se propone en este trabajo, consiste en la insercin de una actividad de Conceptualizacin de Requisitos, la cual tiene como finalidad actuar a modo de puente o enlace (link) entre las actividades de educcin de requisitos y las actividades de modelado conceptual, facilitando de esta manera la comprensin del problema manifestado por el usuario y, en consecuencia, la obtencin de Modelos Conceptuales de mayor calidad [2, 6, 9, 17, 19]. A partir de la implementacin de esta actividad de conceptualizacin de requisitos es posible la consecucin de un conjunto de Representaciones Intermedias de los Requisitos de Usuario (RIRU), a partir de las cuales es posible caracterizar la informacin contenida en el discurso del usuario (por lo general en formato de lenguaje natural y es as como se la supone presentada en este trabajo), a los efectos de que sea ms sencillo su procesamiento para la construccin de los modelos conceptuales. Estas

representaciones intermedias estarn conformadas por un conjunto de representaciones grficas: los Escenarios de Usuario Refinados (EUR), los cuales enlazados en forma adecuada a travs del Mapa Unificado de Escenarios de Usuario (MUEU) permiten caracterizar el discurso del usuario en una forma alternativa al lenguaje natural clsico. Es importante aclarar que cuando se hace referencia a los Escenarios de Usuario Refinados (EUR) se quiere significar que los mismos ya fueron revisados en forma conjunta por el IR y el usuario antes de su aprobacin definitiva. El proceso de conceptualizacin de requisitos propuesto se lleva a cabo por medio de un proceso dual llamado Proceso de Conceptualizacin de Requisitos el cual se estructura en dos fases: (a) Anlisis Orientado al Problema: cuyo objetivo es la comprensin del problema planteado por el usuario en el dominio en el cual este tiene lugar; y (b) Anlisis Orientado al Producto: cuyo objetivo es la obtencin de las funcionalidades que el usuario pretende obtener del producto software a desarrollar, teniendo en cuenta la vinculacin de estas funcionalidades con la realidad manifestada por el usuario en su discurso. La Figura 1 representa el proceso de conceptualizacin de requisitos propuesto destacando la interdependencia conceptual entre las fases, tareas y productos.

Fig. 1: Proceso de conceptualizacin de requisitos detallando fases, tareas y productos

La fase de Anlisis Orientado al Problema se estructura en tres tareas: (a) Segmentacin del Discurso de Usuario; (b) Anlisis Cognitivo de los Segmentos de Texto; (c) Construccin del Espacio Problema en Escenarios de Usuario. El Discurso de Usuario en Lenguaje Natural (al que de ahora en adelante en este trabajo se lo llamar Discurso de Usuario) constituye la entrada para la tarea Segmentacin del Discurso de Usuario que produce como resultado los Segmentos de Texto correspondientes a dicho discurso. Estos segmentos sern el material a partir del cual mediante la tarea Anlisis Cognitivo de los Segmentos de Texto se generan los respectivos Tipos de Conocimiento.

Los Segmentos de Texto y los Tipos de Conocimiento son los insumos de la tarea Construccin del Espacio Problema en Escenarios de Usuario que derivar en Espacio Problema en Escenarios de Usuario. La fase de Anlisis Orientado al Producto se estructura en tres tareas: (a) Construccin de Escenarios de Usuario; (b) Refinamiento de Escenarios de Usuario; y (c) Construccin del Mapa Unificado de Escenarios de Usuario. El Discurso de Usuario, los Segmentos de Texto; y los Espacio Problema en Escenarios de Usuario (producto final de la fase Anlisis Orientado al Problema) constituyen las entradas para la tarea

16

Construccin de Escenarios de Usuario que produce como resultado los Escenarios de Usuario. Estos escenarios junto con el Discurso de Usuario respectivo, sern el material a partir del cual mediante la tarea Refinamiento de Escenarios de Usuario se generan los respectivos Escenarios de Usuario Refinados. Estos, y los Segmentos de Texto son los

insumos de la tarea Construccin del Mapa Unificado de Escenarios de Usuario que derivar en el Mapa Unificado de Escenarios de Usuario. Las tcnicas utilizadas y representaciones de las tareas se resumen en la Figura 2.

Fig. 2: Fases, tareas y productos

4. TCNICAS PROPUESTAS PARA FASE ANLISIS ORIENTADO AL PROBLEMA En esta seccin se presentan las tcnicas correspondientes a la fase de Anlisis Orientado al Problema, que son: Tcnica de Segmentacin del Discurso de Usuario (TSDU) para la implementacin de la tarea Segmentacin del Discurso de Usuario (SDU) (seccin 4.1), Tcnicas Cognitivas de Identificacin de Conocimientos Factuales, Procedurales, Contextuales y de Asociacin (TCICFPCA) para la implementacin de la tarea Anlisis Cognitivo de los Segmentos de Texto (ACST) (seccin 4.2) y Tcnica de Construccin del Diagrama de Espacio Problema de Escenarios de Usuario (TCDEPEU) para la implementacin de la tarea Construccin del Espacio Problema de Escenarios de Usuario (CEPEU) (seccin 4.3). 4.1 Tcnica de Segmentacin del Discurso de Usuario (TSDU) Por medio de esta tcnica se implementa la primera tarea que debe llevar a cabo el IR en la fase de Anlisis Orientado al Problema, denominada Segmentacin del Discurso de Usuario (SDU). Para la aplicacin de la TS DU el IR cuenta con el Discurso de Usuario (DU) en lenguaje natural como producto de entrada, y comienza por una segmentacin de dicho DU frase por frase [8], luego procede a integrar estas frases en Segmentos

de Texto (ST) que identifiquen situaciones de la realidad descripta por el usuario, y finalmente obtener ST asociados a los diferentes Escenarios de Usuario (EU). Los ST con los EU asociados constituyen el producto de salida que proporciona esta tcnica, la cual se resume en la Tabla 1. La tcnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 3.
Tabla 1. Tcnica TSDU
Tcnica: Entradas: Salidas: Paso 1. Paso 2. Paso 3. Segmentacin del Discurso de Usuario (TSDU) Discurso de Usuario (DU) ST Asociados a los EU Segmentacin del DU Frase por Frase Integracin de las Frases en ST Asociacin de los ST a EU

Fig. 3: Esquema y subproductos de TSDU

17

4.2 Tcnica Cognitiva de Identificacin de Conocimientos Factuales, Procedurales, Contextuales y de Asociacin (TCICFPCA) Por medio de esta tcnica se implementa la segunda tarea que debe llevar a cabo el IR en la fase de Anlisis Orientado al Problema, denominada Anlisis Cognitivo de los Segmentos de Texto (ACST). Para la aplicacin de la TCICFPCA el IR dispone como producto de entrada de cada uno de los ST asociados a los EU que fueron obtenidos a partir de la aplicacin de la tcnica anterior (TSDU); estos segmentos se procesan con la idea de identificar en los mismos diferentes Tipos de Conocimiento (TC), los cuales se encuentran presentes en el Modelo Mental elaborado por el usuario a partir de un proceso mental indexado por vivencias y experiencias que son de carcter netamente personal y que tienen lugar en determinados contextos [9]. Para comenzar a aplicar la TCI CFPCA el IR comienza por la identificacin de TC Contextual en los ST, para luego continuar con los TC Factual, Procedural y de Asociacin. Finalmente, el IR integra estos TC con los ST a los efectos de establecer que TC se corresponden con cada ST. Los TC identificados en cada uno de los ST constituyen el producto de salida que proporciona esta tcnica, la cual se resume en la Tabla 2. La tcnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 4.

4.3 Tcnica de Construccin del Diagrama de Espacio Problema en Escenarios de Usuario (TCDEPEU) Por medio de esta tcnica se implementa la tercera tarea que debe llevar a cabo el IR en la fase de Anlisis Orientado al Problema, denominada Construccin del Espacio Problema en Escenarios de Usuario (CEPEU). Para la aplicacin de la TCDEPEU el IR dispone como productos de entrada de cada uno de los ST asociados a los EU obtenidos a partir de la aplicacin de la tcnica TSDU, y de los TC identificados en cada uno de los ST obtenidos a partir de la aplicacin de la tcnica TCI CFPCA. Para comenzar a aplicar la TCDEPEU el IR procede a hacer uso de los TC identificados en cada ST (dejando el TC de Asociacin para la Fase de Anlisis Orientado al Producto) para poder obtener los distintos elementos que componen los EPEU, los cuales son: Actores, Relaciones, Atributos, Acciones e Interacciones. A continuacin, el IR procede a identificar el Marco Contextual Base (MCB) en el que se desenvolvern los actores en el EPEU construyndose un primer diagrama de EPEU a tal efecto. Finalmente, el IR confecciona los restantes diagramas de EPEU encargados de reflejar las distintas realidades proporcionadas por los ST. Los diagramas correspondientes a los EPEU constituyen el producto de salida que proporciona esta tcnica, la cual se resume en la Tabla 3. La tcnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 5.
Tabla 3. Tcnica TCDEPEU
Tcnica: Entradas: Salidas: Paso 1. Construccin del Diagrama de Espacio Problema en Escenarios de Usuario (TCDEPEU) ST Asociados a los EU y Tabla de STTC Diagramas de EPEU Uso de los TC para la identificacin de los elementos de EPEU 1.1. Uso de TC Factual 1.2. Uso de TC Procedural 1.3. Uso de TC Contextual Construccin del Diagrama de EPEU correspondiente al MCB 2.1. Incorporacin de Actores al Diagrama de MCB 2.2. Incorporacin de Relaciones al Diagrama de MCB Construccin de los restantes Diagramas de EPEU 3.1. Incorporacin de Actores al Diagrama 3.1.1. Incorporacin de Atributos de actores al Diagrama 3.1.2. Incorporacin de valores de Atributos de actores al Diagrama 3.2. Incorporacin de Relaciones al Diagrama 3.3. Incorporacin de Acciones al Diagrama 3.3.1. Incorporacin de Atributos de acciones al Diagrama 3.3.2. Incorporacin de valores de Atributos de acciones al Diagrama 3.4. Incorporacin de Interacciones al Diagrama 3.4.1. Incorporacin de Atributos de interacciones al Diagrama 3.4.2. Incorporacin de valores de Atributos de interacciones al Diagrama

Paso 2.

Paso 3.

Fig. 4: Esquema y subproductos de TCICFPCA Tabla 2. Tcnica TCICFPCA

Tcnica: Entradas: Salidas: Paso 1. Cognitiva de Identificacin de Conocimientos Factuales, Procedurales, Contextuales y de Asociacin (TCI-CFPCA) ST Asociados a los EU TC Identificados en los ST Identificacin de TC en los ST 1.1. Identificacin de TC Contextual en los ST 1.2. Identificacin de TC Factual en los ST 1.3. Identificacin de TC Procedural en los ST 1.4. Identificacin de TC de Asociacin en los ST Integracin entre los ST y TC

Paso 2.

18

obtenidos a partir de la aplicacin de la tcnica TCD EPEU. Para comenzar a aplicar la TCDEU el IR procede a hacer uso de los ST con TC de Asociacin que le permiten obtener las Funcionalidades del problema planteado por el usuario, as como tambin identificar aquellos actores del EPEU que son necesarios para que el sistema realice estas funcionalidades. Con estas funcionalidades y los diagramas de EPEU en los cuales se identifiquen funcionalidades asociadas, el IR confecciona los diagramas correspondientes a los bloques del Espacio Producto de Escenarios de Usuario (EPrEU) para estos EPEU [5]. Finalmente, el IR realiza un proceso de asociacin a los efectos de obtener los vnculos existentes entre los elementos de los bloques de EPEU y EPrEU, obteniendo as un nico diagrama para cada EU conformado por ambos bloques. Los diagramas correspondientes a los EU constituyen el producto de salida que proporciona esta tcnica, la cual se resume en la Tabla 4. La tcnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 6.
Tabla 4. Tcnica TCDEU
Tcnica: Entradas: Salidas: Paso 1. Construccin del Diagrama de Escenarios de Usuario (TCDEU) ST con TC de Asociacin (de la Tabla STTC) y Diagramas de EPEU Diagramas de EU Uso del TC de Asociacin 1.1. Identificacin de Funcionalidades 1.2. Identificacin de Actores necesarios para realizar las funcionalidades Construccin de los Diagramas de EPrEU para cada EPEU Vinculacin de los elementos de los bloques de EPEU y EPrEU para cada EU

Paso 2.

Fig. 5: Esquema y subproductos de TCDEPEU

Paso 3.

5. TCNICAS APLICADAS EN LA FASE DE ANLISIS ORIENTADO AL PRODUCTO En esta seccin se presentan las tcnicas correspondientes a la fase de Anlisis Orientado al Producto, que son: Tcnica de Construccin del Diagrama de Escenarios de Usuario (TCDEU) para la implementacin de la tarea Construccin de Escenarios de Usuario (CEU), Tcnica de Refinamiento del Diagrama de Escenarios de Usuario (TRDEU) para la implementacin de la tarea Refinamiento de Escenarios de Usuario (REU) y Tcnica de Construccin del Diagrama del Mapa Unificado de Escenarios de Usuario (TCDMUEU) para la implementacin de la tarea Construccin del Mapa Unificado de Escenarios de Usuario (CMUEU). 5.1 Tcnica de Construccin del Diagrama de Escenarios de Usuario (TCDEU) Por medio de esta tcnica, se implementa la primera tarea que debe llevar a cabo el IR en la fase de Anlisis Orientado al Producto, denominada Construccin de Escenarios de Usuario (CEU). Para la aplicacin de la TCDEU el IR dispone como productos de entrada de aquellos ST asociados a los EU que contienen TC de Asociacin, obtenidos a partir de la aplicacin de la tcnica TSDU, y de cada uno de los Diagramas de EPEU

Fig. 6: Esquema y subproductos de TCDEU

5.2 Tcnica de Refinamiento del Diagrama de Escenarios de Usuario (TRDEU) Por medio de esta tcnica se implementa la segunda tarea que debe llevar a cabo el IR en la fase de Anlisis

19

Orientado al Producto, denominada Refinamiento de Escenarios de Usuario (REU). La TRDEU la aplican en forma conjunta el IR y Usuario. Los productos de entrada son el Discurso de Usuario (DU) original y los EU obtenidos en la tarea anterior. Como producto de salida, se obtienen los Escenarios de Usuario Refinados (EUR). El sub-paso de aplicacin de TRDEU incluye revisin conjunta (Usuario e IR) del DU original, el cual se lleva a cabo en base a un Anlisis de Consistencia del mismo tendientes a identificar inconsistencias, que se clasifican en incompletitudes y contradicciones. Dichas inconsistencias son depuradas para obtener un DU refinado. Con base en este DU refinado, Usuario e IR realizan una validacin y depuracin de los ST y TC a los efectos de depurar a estos elementos de las inconsistencias provenientes del DU. Luego, Usuario e IR realizan una validacin de los diagramas de EU para obtener los diagramas de EUR. Finalmente, Usuario e IR efectan una revisin final de los EUR; si ambos otorgan conformidad para los EUR obtenidos culmina la aplicacin de la tcnica, caso contrario, se vuelve al paso 1 para comenzar a aplicarla nuevamente. En este sentido y en virtud de la importancia que reviste la implementacin con xito de la presente tcnica, y dado que la misma debe asegurar la consistencia y robustez de los correspondientes diagramas de EU; cabe mencionar que el soporte conceptual de dicha implementacin consiste en la puesta en prctica de un Ciclo de Prototipado Evolutivo, a partir del cual se pretende obtener un adecuado grado de consenso entre Usuario e IR acerca de los diagramas de EU obtenidos. Los diagramas correspondientes a los EUR constituyen el producto de salida que proporciona esta tcnica, la cual se resume en la Tabla 5. La tcnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 7.
Tabla 5. Tcnica TRDEU
Tcnica: Entradas: Salidas: Paso 1. Refinamiento del Diagrama de Escenarios de Usuario (TRD EU) Discurso de Usuario (DU) y Diagramas de EU Diagramas de EUR Anlisis de Consistencia del DU 1.1. Validacin y Depuracin Incompletitudes del DU 1.2. Validacin y Depuracin Contradicciones del DU 1.3. Validacin y Depuracin del DU Validacin y Depuracin de los ST y TC Validacin y Depuracin de los EU Revisin Final de los EUR

salida se obtiene el Diagrama de Mapa Unificado de Escenarios de Usuario (MUEU).

Fig. 7: Esquema y subproductos de TRDEU

Paso 2. Paso 3. Paso 4.

El diagrama de MUEU representa una secuencia espaciotemporal acerca de cmo el usuario entiende el problema a resolver y la realidad en la que se encuadra dicho problema. El sub-paso de aplicacin de TCD MUEU incluye un Anlisis de Transicin de Escenarios de Usuarios (EU) mediante el cual se identifican los Disparadores de Escenarios de Usuario (EU), los cuales permiten identificar las correspondientes relaciones de precedencia entre EU. A partir de estos disparadores el IR est en condiciones de establecer los correspondientes vnculos entre EU que le conducen al Diagrama de MUEU. El diagrama correspondiente al MUEU constituye el producto de salida que proporciona esta tcnica, la cual se resume en la Tabla 6. La tcnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 8.
Tabla 6. Tcnica TCDMUEU
Tcnica: Entradas: Salidas: Paso 1. Construccin del Diagrama del Mapa Unificado de Escenarios de Usuario (TCDMUEU) Segmentos de Texto Asociados a los EU y Diagramas de EUR Diagrama de MUEU Anlisis de Transicin de EU 1.1. Identificacin de Cambio de Contexto 1.2. Identificacin de Cambio de Estado en Actores 1.3. Identificacin de Nuevos Actores Construccin del Diagrama de MUEU

5.3 Tcnica de Construccin del Diagrama del Mapa Unificado de Escenarios de Usuario (TCD MUEU) Por medio de esta tcnica se implementa la tercera y ltima tarea que debe llevar a cabo el IR en la fase de Anlisis Orientado al Producto, denominada Construccin del Mapa Unificado de Escenarios de Usuario (CMUEU). Para la aplicacin de la TCDMUEU el IR dispone como productos de entrada de cada uno de ST asociados a los EU y de los EUR obtenidos de la aplicacin de la tcnica anterior. Como producto de

Paso 2.

20

de control, (b) la validacin emprica de las tcnicas propuestas en un conjunto amplio y representativo de dominios de aplicacin, (c) la validacin emprica del proceso de conceptualizacin de requisitos mediante la incorporacin de otros discursos de usuario que aporten una visin diferente acerca del mismo producto software que se pretende desarrollar. 7. AGRADECIMIENTOS Las investigaciones que se reportan en este artculo han sido financiadas parcialmente por el Proyecto de Investigacin 33A105 de la Secretaria de Ciencia y Tcnica y del Departamento de Desarrollo Productivo y Tecnolgico de la Universidad Nacional de Lans y por el proyecto CCG10-UPM/TIC-5694 del Gobierno Autnomo de Madrid. 8. REFERENCIAS
[1] [2] Fig. 8: Esquema y subproductos de TCDMUEU Sommerville, I. 2005. Ingeniera de Software. Add.Wesley. Chatzoglou, P. & Soteriou, A. 1999. A DEA framework to assess the efficiency of the software requirements capture and analysis process. Decision-Sciences. 30(2), 503-31. Robertson S. 2002. Project Sociology: Identifying and involving the stakeholders. ICFAI University Press. Christel, M. & Kang, K. 1992. Issues in Requirements Elicitation. Technical Report CMU/SEI-92-TR-12. Software Engineering Institute. Carnegie Mellon

[3] [4]

6. CONCLUSIONES La principal contribucin de este artculo es la presentacin de un proceso metodolgico llamado Conceptualizacin de Requisitos, el cual se estructura en dos fases llamadas Anlisis Orientado al Problema y Anlisis Orientado al Producto y cuyo objetivo consiste en estructurar y caracterizar la masa de informacin proveniente de la actividad de educcin y contenida en el discurso del usuario. Complementariamente se proponen seis tcnicas para operacionalizar las actividades asociadas a las fases del modelo de proceso de conceptualizacin de requisitos propuesto. Para cada tcnica se identifican, mediante esquemas, el flujo de trabajo con detalle de los insumos y los producidos intermedios y finales. Asimismo, cabe destacar la aplicacin de tcnicas pertenecientes a otros campos disciplinares, tales como la tcnica de Anlisis de Protocolo (AP) [20] proveniente de la Ingeniera del Conocimiento y cuya aplicacin ha sido de gran utilidad en el desarrollo de la primera tarea de Segmentacin del Discurso de Usuario (SDU); y la tcnica de Anlisis Cognitivo del DU proveniente de las Teoras Cognitivas de la Educacin, las cuales basan su potencial en la identificacin y uso de los diferentes Tipos de Conocimiento (TC) que se encuentran embebidos en los distintos segmentos de texto del DU. La aplicacin de la tcnica de Anlisis Cognitivo del DU ha contribuido al desarrollo de las tareas segunda y tercera del proceso (Anlisis Cognitivo de los Segmentos de Texto (ACST) y Construccin del Espacio Problema en Escenarios de Usuario (CEPEU)). Se prev como siguientes pasos de esta investigacin: (a) la validacin emprica del proceso de conceptualizacin de requisitos mediante la tcnica de muestras apareadas basadas en grupos experimental y

University.
[5] [6] Wieringa, R. 1995. Requirements Engineering: Frameworks for Understanding. John Wiley. Van der Vos, B.; Gulla, J. & Van de Riet, R. 1997. Verification of Conceptual Models based in Linguistic Knowledge. Data & Knowledge Engineering, 21(2), 147163. Loucopoulos, P. & Karakostas, V. 1995. System Requirements Engineering. McGraw-Hill. Zave, P. 1990. A Comparison of the Major Approaches to Software Specification and Design. In Thayer, R. H. & Dorfman, M. (Eds.), System and Software Requirements Engineering, 197-199. IEEE Computer Society Press. Davis, A. 1993. Software Requirements: Objects, Functions and States. Prentice-Hall International. Faulk, S. R. 1997. Software Requirements: A Tutorial. In Thayer, R. & Dorfman, M. (Eds.) Software Requirements Engineering, 1-33. IEEE Computer Society press. Kaindl, H. 1999. Difficulties in the transition from OO analysis to design. IEEE Software, 16(5), 94-102. Sutcliffe, A. & Maiden, N. 1992. Analysing the Novice Analyst: Cognitive Models in Software Engineering. International Journal of Man-Machine Studies, 36(5), 719-740. Yu, E. & Mylopoulos, J. 1994. Uderstanding Why in Software Process Modelling, Analysis and Design. Proceedings of the 16th International Conference on Software Engineering, 159-168. Holtzblatt, K. & H. Beyer. Requirements Gathering: The Human Factor. Communications of the ACM, 38(5), 3132. Beringer, D. 1995. The Model Architecture Frame: Quality Management in a Multi Method Environment. In Brebbia, C. A. et al (Eds.), Information and Communication Technologies volume 13, 1-12.

[7] [8]

[9] [10] [11] [12]

[13]

[14] [15]

21

[16] Jalote, P. 1997. An Integrated Approach to Software Engineering. Springer-Verlag. [17] Juristo, N. & Moreno, A. 2000. Introductory paper: Reflections on Conceptual Modeling. Data and Knowledge Engineering, 33(2), 103-117. [18] Moreno, A., 1999. Mtodo Formal de Modelizacin Conceptual para Sistemas Software. Tesis Doctoral Universidad Politcnica de Madrid, Espaa.

[19] Chen, P. 1990. Entity-relationship Approach to Data Modeling. In Thayer, R. & Dorfman, M. (Eds.) Software Requirements Engineering, 109-114. [20] Hossian, A. et al. 2007. Hacia una Metodologa Orientada al Conocimiento para la Educcin de Requisitos en Ingeniera del Software. Proceedings VI Ibero-American Symposium on Software Engineering, 107-114.

22

Behavioral Variability of Clustering and Induction Based on Domain Features Variabilidad del Comportamiento de Agrupamiento e Induccin Basado en las Caractersticas del Dominio
Programa de Magister en Ingeniera en Sistemas de informacin. Escuela de Posgrado. Facultad Regional Buenos Aires. Universidad Tecnolgica Nacional. Buenos Aires, Argentina. zappapet@yahoo.com. 2 Grupo de Investigacin en Sistemas de Informacin. Departamento de Desarrollo Productivo y Tecnolgico. Universidad Nacional de Lans. Buenos Aires, Argentina. rgarcia@unla.edu.ar.
1

Marcelo Lpez N.1, Ramn Garcia-Martinez2

INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo: Recibido: 23/04/2012 Correcciones: 29/05/2012 Aceptado: 31/05/2012 Palabras clave Explotacin de Informacin, caracterizacin de dominios, agrupamiento, induccin, generacin de dominios. Categories and Subject Descriptors H.2.8 [Database Applications]: Data mining General Terms Algorithmic Analysis Keywords Information Mining, domains characterization, clustering, induction, domains generation procedure.

ABSTRACT The information mining processes use different algorithms for data mining for obtaining patterns of knowledge from the examples (instances) of the problem domain. One of the hypotheses in which these algorithms are based, is that the complexity of the domain on which they are working, has no bearing on the quality of the patterns of knowledge obtained. One of the processes of information mining of interest is the rules discovery of group membership which uses clustering algorithms and induction algorithms. In this research we characterize the complexity of the domains in terms of pieces of knowledge that describe them and that processes of information mining seek to discover. We use an experiment to demonstrate that in the case of the information mining process of rules discovery of group membership, the quality of patterns of knowledge obtained differ according to the algorithms used in the process and to the complexity of the domains to which they are applied. RESUMEN Los procesos de explotacin de informacin utilizan distintos algoritmos de minera de datos para obtener patrones de conocimiento a partir de los ejemplos (instancias) que se tienen sobre el dominio de problema Una de las hiptesis con las que trabajan estos algoritmos es que la complejidad del dominio sobre cuya informacin se trabaja, no incide sobre la calidad de los patrones obtenidos. Uno de los procesos de explotacin de informacin de inters es el de descubrimiento de reglas de pertenencia a grupos que utiliza algoritmos de agrupamiento (clustering) y algoritmos de induccin. En este trabajo se caracteriza la complejidad de los dominios en trminos de las piezas de conocimiento que los describen y que los procesos de explotacin de informacin buscan descubrir. Se demuestra mediante un experimento que, en el caso del proceso de descubrimiento de reglas de pertenencia a grupos la calidad, los patrones que se obtienen difieren en funcin de los algoritmos que se utilizan en el proceso y de la complejidad de los dominios al cual aplican.

1. INTRODUCCIN Varios autores [1-5] han sealado la necesidad de disponer de procesos de explotacin de informacin que permitan obtener conocimiento a partir de las grandes masas de informacin disponible, su caracterizacin y tecnologas involucradas. En [6] se han definido cinco procesos de explotacin de informacin: descubrimiento de reglas de comportamiento, descubrimiento de grupos, descubrimiento de atributos significativos, descubrimiento de reglas de pertenencia a grupos y ponderacin de reglas de comportamiento o de pertenencia a grupos. Los procesos de explotacin de informacin utilizan distintos algoritmos de minera de datos para obtener patrones de conocimiento a partir de los ejemplos (instancias) que se tienen sobre el dominio de problema [7]. Una de las hiptesis implcitas con las que trabajan estos algoritmos es que fijados los algoritmos para el proceso de explotacin de informacin, la complejidad del dominio sobre cuya informacin se trabaja, no incide sobre la calidad de los patrones obtenidos. Sin embargo, hay indicios [8] que muestran que la complejidad de los dominios en trminos de las piezas

de conocimiento que los describen y que los procesos de explotacin de informacin buscan descubrir, emerge como un componente no despreciable al momento de analizar la calidad de los resultados a obtener. En este contexto, se demuestra mediante un experimento que para el caso del proceso de explotacin de informacin descubrimiento de reglas de pertenencia a grupos, la calidad de los patrones que se obtiene difiere en funcin de la complejidad de los dominios a los cuales se aplica y de los algoritmos que se utilizan en el proceso. En suma, en este artculo se caracterizan los distintos tipos de complejidad de dominios (seccin 2), las preguntas de investigacin s 2. CLASIFICACION DE DOMINIOS POR COMPLEJIDAD Para abordar el tema de la complejidad de los dominios, en [9] se propone caracterizar a los mismos en trminos de piezas de conocimiento (reglas) que explican la pertenencia de una determinada instancia (ejemplo) a un determinado dominio. Es as que la complejidad del dominio queda caracterizada por la cantidad de clases que lo describe, la cantidad de reglas que definen la pertenencia a cada clase, la cantidad de atributos que

23

puede tener cada regla y la cantidad de valores (distintos) que puede tener cada atributo. Con base en los atributos de clasificacin enunciados y el protocolo de clasificacin de dominios propuesto en [8] se pueden clasificar los dominios en funcin de su complejidad en los siguientes tipos: Dominios de Complejidad Simple: son aquellos dominios en que el aumento de la cantidad de ejemplos por regla, mejora el cubrimiento de reglas (independientemente de las dems dimensiones utilizadas. Dominios de Complejidad Mediana: son aquellos dominios que se explican con ejemplos con pocos atributos y pocas clases, o pocos atributos y muchas clases o pocas clases y pocas reglas por clase. Dominios Oscilantes: son aquellos dominios que se explican con ejemplos donde pueden variar el nmero de atributos por ejemplo, o cantidad de ejemplos soportados por una regla, o valores comunes de atributos en un conjunto de ejemplos cubiertos por la misma regla. Dominios Complejos: son aquellos dominios que se explican con ejemplos con pocos atributos y muchos valores posibles por atributo, o con muchos atributos y pocos valores posibles por atributo, o con muchos atributos y muchos valores posibles por atributo. Dominios Hipercomplejos: son aquellos dominios que se explican con ejemplos donde pueden variar la cantidad de posibles valores que pueden tomar los atributos, el nmero de atributos que cubren ejemplos, la cantidad de las reglas que cubren ejemplos, o la cantidad de clases 3. REGLAS DE PERTENENCIA A GRUPOS Uno de los procesos de explotacin de informacin de inters es el de descubrimiento de reglas de pertenencia a grupos que utiliza algoritmos de agrupamiento (clustering) y algoritmos de induccin. El proceso de descubrimiento de reglas de pertenencia a grupos aplica cuando se requiere identificar cules son las condiciones de pertenencia a cada una de las clases en una particin desconocida a priori, pero presente en la masa de informacin disponible sobre el dominio de problema. Son ejemplos de problemas que requieren este proceso: tipologa de perfiles de clientes y caracterizacin de cada tipologa, distribucin y estructura de los datos de un website, segmentacin etaria de estudiantes y comportamiento de cada segmento, clases de llamadas telefnicas en una regin y caracterizacin de cada clase, entre otros [10]. Este proceso y sus subproductos pueden ser visualizados grficamente en la Figura 1.
Fig. 1: Esquema y subproductos resultantes de Agrupamiento e Induccin

El proceso se puede describir de la siguiente manera [6]: en primer lugar se identifican todas las fuentes de informacin (bases de datos, archivos planos, entre otras), se integran entre s formando una sola fuente de informacin a la que se llamar datos integrados. Con base en los datos integrados se aplica Agrupamiento. Como resultado de la aplicacin de Agrupamiento se obtiene una particin del conjunto de registros en distintos grupos a los que se llama grupos identificados. Se generan los archivos asociados a cada grupo identificado. A este conjunto de archivos se lo llama grupos ordenados. El atributo grupo de cada grupo ordenado se identifica como el atributo clase de dicho grupo, constituyndose este en un archivo con atributo clase identificado (GR). Se aplica Induccin sobre el atributo clase de cada grupo GR y se obtiene un conjunto de reglas que definen el comportamiento de cada grupo. 4. PREGUNTAS DE INVESTIGACIN En este proyecto se han planteado las siguientes preguntas de investigacin: Es correcta la suposicin que la performance de los algoritmos utilizados para agrupamiento e induccin es independiente de la complejidad del dominio? En caso de falseamiento de la suposicin previa: Cul es el par <algoritmo de agrupamiento, algoritmo de induccin> que mejor performance proporciona dada la complejidad del dominio? 5. DISEO EXPERIMENTAL Se consideraron de inters para el estudio los siguientes dominios: Dominios de Complejidad Mediana, Dominios Oscilantes, Dominios Complejos, Dominios Hipercomplejos. En orden a dar respuesta las preguntas de investigacin se ha diseado un experimento estructurado en tres pasos. El primer paso consiste en la preparacin del experimento e involucra: (a) generacin del dominio, basado sobre la generacin de las clases y reglas que indican la pertenencia a cada clase y (b) generacin de ejemplos que sean cubiertos por cada regla. La salida de este paso es un conjunto de reglas de pertenencia a cada clase y un conjunto de ejemplos del

24

dominio. El segundo paso consiste en la ejecucin del experimento. Este paso involucra: (a) aplicar el proceso de agrupamiento al conjunto de ejemplos del dominio para obtener el conjunto de grupos de ejemplos y (b) aplicar a cada grupo de ejemplos el proceso de induccin para obtener reglas que caractericen la pertenencia a cada grupo, obteniendo as el conjunto de reglas descubiertas. El tercer y ltimo paso consiste en la comparacin entre el conjunto de reglas de clasificacin generadas en el primer paso y las reglas descubiertas en el segundo paso. El porcentaje de reglas descubiertas de forma correcta, define el xito del experimento [11]. Las variables independientes del experimento son: (a) cantidad de clases que rigen el dominio, (b) cantidad de reglas que indican la pertenencia a cada clase, (c) cantidad de atributos en cada regla, (d) cantidad de posibles valores que puede tomar cada atributo, (e) cantidad de ejemplos de cada regla y (f) el porcentaje sobre la cantidad total de valores posibles que puede tomar cada atributo. La variable dependiente del experimento es porcentaje de reglas pertenecientes al conjunto de reglas original que se encuentra en el conjunto de reglas descubiertas. Un esquema de representacin se muestra en la Figura 2.

(e) aplicacin de induccin a los grupos obtenidos, (g) generacin de reglas descubiertas y (f) comparacin de ambos conjuntos de reglas. Para el experimento se utilizaron los siguientes algoritmos de agrupamiento: SOM [12], KMEANS [13], NNC [14]; y los siguientes algoritmos de induccin: M5 [15], CN2 [16] y AQ15 [17]. 6. DESARROLLO DEL EXPERIMENTO Se llevaron a cabo 210 corridas del banco de pruebas, utilizando para ello los 7 atributos antes descritos para cada uno de los escenarios que surgen de las combinaciones de atributos representativas de los cuatro dominios en estudio. Los escenarios utilizados en las experiencias, con su correspondiente grupo se presentan en la Tabla 1.
Tabla 1. Descripcin de los distintos tipos de escenarios utilizados en la experimentacin
CANTIDAD DE EJEMPLOS UTILIZADOS PARA CADA REGLA 1 10 20 1 10 20 1 10 20 1 10 20 1 10 20 1 10 20 1 10 20 1 10 20 1 10 20 CANTIDAD DE POSIBLES VALORES QUE PUEDEN TOMAR LOS ATRIBUTOS CANTIDAD DE ATRIBUTOS DE CADA EJEMPLO CANTIDAD DE REGLAS QUE INDICAN LA PERTENENCIA A CADA CLASE GRUPO AL QUE PERTENECE CANTIDAD DE CLASES QUE RIGEN LOS EJEMPLOS

Fig. 2: Esquema de los pasos experimentales

Para llevar adelante la experimentacin se utiliza entonces el banco de pruebas para la generacin de dominios en condiciones de laboratorio, la generacin de ejemplos en dichas condiciones, el agrupamiento por parte de diversos algoritmos de agrupamiento, la induccin de reglas sobre el conjunto de grupos de ejemplos, la obtencin de reglas de pertenencia a grupos por parte de los distintos algoritmos de induccin, y finalmente la contrastacin de las reglas obtenidas en el segundo paso con las reglas creadas en el primer paso, con el fin de establecer el porcentaje de reglas correctamente cubiertas. La dinmica de trabajo que tiene el banco de pruebas puede ser descrita entonces de la siguiente manera: (a) generacin de clases, (b) generacin de reglas de pertenencia a cada clase, (c) generacin de ejemplos, (d) agrupamiento de ejemplos,

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

NMERO DE SECTOR

3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 5 5 5 5 5 5 5 5 5 10 10 10 10 10 10 10 10 10 1 1 1

1 1 1 5 5 5 15 15 15 1 1 1 5 5 5 15 15 15 1 1 1 5 5 5 15 15 15 1 5 10

1 10 20

A A A C C C D D D B B B C C C C C C B B B C C C C C C C C C

Se aplic en cada una de las corridas los 9 pares <algoritmo de agrupamiento, algoritmo de induccin> que ya se mencionaron en el presente trabajo. A cada dominio generado se le aplic el proceso de descubrimiento de reglas de pertenencia a grupos utilizando cada uno de los nueve pares <algoritmo de agrupamiento, algoritmo de induccin>.

25

Se analizaron los resultados obtenidos para los distintos tipos de dominios: mediano, oscilante, complejo e hipercomplejo y se verific el porcentaje de reglas correctamente cubiertas para cada una de las

combinaciones posibles de variables. Se utilizaron Diagramas de Kiviat [18] para graficar los resultados [8], lo que se muestra en la Figura 3.

Fig. 3: Resultados descriptos en trminos de Diagramas de Kiviat

Como resultado del anlisis sobre los resultados de la experimentacin emergieron las siguientes proposiciones experimentales: 1. Proposicin Experimental 1: Para dominios de tipo mediano (pertenecientes al grupo A), se verific experimentalmente que la combinacin que ofrece mejor cubrimiento de reglas es el par SOM VS AQ15, con un valor cercano al 86 por ciento en promedio. Esto verifica la Proposicin Experimental 1. 2. Proposicin Experimental 2: Para dominios de tipo hipercomplejo (pertenecientes al grupo B), se verific experimentalmente que la combinacin que ofrece mejor cubrimiento de reglas es tambin SOM VS AQ15,, pero con un rendimiento ms bajo, cercano al 65 por ciento en promedio. Esto verifica la Proposicin Experimental 2. 3. Proposicin Experimental 3: Para dominios de tipo complejo (pertenecientes al grupo C), se verific experimentalmente que la combinacin que ofrece mejor cubrimiento de reglas es SOM VS AQ15, con 49 por ciento como valor promedio. Esto verifica la Proposicin Experimental 3.

4. Proposicin Experimental 4: Para dominios de tipo oscilante (pertenecientes al grupo D), se verific experimentalmente que la combinacin que ofrece mejor cubrimiento de reglas es SOM VS M5, con 60 por ciento en promedio. Esto verifica la Proposicin Experimental 4. 5. Proposicin Experimental 5: Se observa y se determina experimentalmente que las caractersticas del dominio subyacente tienen influencia sobre el resultado experimental obtenido. 6. Proposicin General: Se observa tambin que los valores obtenidos experimentalmente se ajustan sobremanera a lo que se postul a priori en la clasificacin terica realizada a los distintos dominios segn su complejidad. 7. En relacin al rendimiento en trminos de cubrimiento de reglas de los algoritmos de agrupamiento e induccin combinados se han obtenidos resultados que falsean la suposicin que la performance de los algoritmos utilizados para agrupamiento e induccin es independiente de la complejidad del dominio.

26

La Tabla 2 muestra los resultados para los Dominios Medianos, resultando la mejor combinacin (con ms cubrimiento) AQ15 y SOM.
Tabla 2. Resultados de mejor cubrimiento para los Dominios Medianos DOMINIOS MEDIANOS M5 CN2 AQ15 SOM 37,34 30,46 38,26 KMEANS 37,53 30,57 37,05 NNC 37,19 30,29 36,61

7. CONCLUSIONES Ha quedado demostrado empricamente que la suposicin sobre que la performance de los algoritmos utilizados para agrupamiento e induccin es independiente de la complejidad del dominio es falsa. Se ha encontrado que: [a] para Dominios Medianos, Complejos e Hipercomplejos la combinacin de algoritmos con ms cubrimiento es la de AQ15 y SOM; y [b] para Dominios Oscilantes la combinacin de algoritmos con ms cubrimiento es la de M5 y SOM. Con lo expuesto se logra identificar el par <algoritmo de agrupamiento, algoritmo de induccin> que mejor performance proporciona dada la complejidad del dominio. Se observa que con independencia del algoritmo de agrupamiento, el algoritmo de induccin M5 es el que mejor funciona para Dominios Oscilantes y el algoritmo CN2 es el que mejor funciona para Dominios Complejos. Como futuras lneas de investigacin se prev extender en una primera etapa estos estudios a la combinacin de otros algoritmos de agrupamiento e induccin; y en una segunda etapa a otros procesos de explotacin de informacin. 8. AGRADECIMIENTOS Las investigaciones que se reportan en este artculo han sido financiadas parcialmente por los proyectos UNLa 33A105 y UNLa 33B102 de la Universidad Nacional de Lans. 9. REFERENCIAS
[1] Chen, M.; Han, J. & Yu, P. 1996. Data Mining: An Overview from a Database Perspective. IEEE Transactions on Knowledge and Data Engineering, 8(6), 866-883. [2] Chung, W.; Chen, H. & Nunamaker, J. 2005. A Visual Framework for Knowledge Discovery on the Web: An Empirical Study of Business Intelligence Exploration. Journal of Management Information Systems, 21(4), 5784. [3] Chau, M. et al. 2007. Redips: Backlink Search and Analysis on the Web for Business Intelligence Analysis. Journal of the American Society for Information Science and Technology, 58(3), 351-365. [4] Golfarelli, M.; Rizzi, S. & Cella, L. 2004. Beyond data warehousing: what's next in business intelligence? Proceedings 7th ACM international workshop on Data warehousing and OLAP, 1-6. [5] Koubarakis, M. & Plexousakis, D. 2000. A Formal Model for Business Process Modeling and Design. Lecture Notes in Computer Science, 1789, 142-156. [6] Britos, P. 2008. Procesos de explotacin de informacin basados sobre sistemas inteligentes. Tesis presentada para obtener el grado de Doctor en Ciencias Informticas, Facultad de Informtica, Universidad Nacional de La Plata, Argentina. [7] Britos, P. & Garca-Martnez, R. 2009. Propuesta de Procesos de Explotacin de Informacin. Proceedings XV Congreso Argentino de Ciencias de la Computacin. Workshop de Base de Datos y Minera de Datos, 10411050.

La Tabla 3 muestra los resultados para los Dominios Complejos, resultando la mejor combinacin (con ms cubrimiento) AQ15 y SOM.
Tabla 3. Resultados de mejor cubrimiento para los Dominios Complejos DOMINIOS COMPLEJOS M5 CN2 AQ15 SOM 39,55 26,86 51,10 KMEANS 34,46 20,05 47,96 NNC 34,65 17,95 47,76

La Tabla 4 muestra los resultados para los Dominios Hiper Complejos, resultando la mejor combinacin (con ms cubrimiento) AQ15 y SOM.
Tabla 4. Resultados de mejor cubrimiento para los Dominios Hiper Complejos DOMINIOS HIPER COMPLEJOS M5 CN2 AQ15 SOM 46,74 41,12 49,02 KMEANS 42,46 36,23 46,09 NNC 42,58 36,22 44,59

La Tabla 5 muestra los resultados para los Dominios Osciantes, resultando la mejor combinacin (con ms cubrimiento) M5 y SOM.
Tabla 5. Resultados de mejor cubrimiento para los Dominios Oscilantes DOMINIOS OSCILANTES M5 CN2 AQ15 SOM 60,68 18,88 25,44 KMEANS 54,75 21,01 24,65 NNC 53,84 20,96 22,04

Los resultados mostrados en las Tabla anteriores se pueden resumir en la Tabla 6, que es la combinacin de los algoritmos estudiados que mejor resulta (reglas generadas con mayor cubrimiento) en funcin de la complejidad de cada dominio.
Tabla 6. Rendimiento de los algoritmos en trminos del cubrimiento de las reglas que generan M5 CN2 AQ15 SOM Oscilantes Complejos Complejos KMEANS Oscilantes Complejos Hiper Complejos NNC Oscilantes Complejos Hiper Complejos

27

[8] Lopez-Nocera, M. et al. 2011. Un Protocolo de Caracterizacin Emprica de Dominios para Uso en Explotacin de Informacin. Proceedings XVII Congreso Argentino de Ciencias de la Computacin, pp. 1047-1055. [9] Rancan, C.; Pesado, P. & Garca-Martnez, R. 2010. Issues in Rule Based Knowledge Discovering Process. Advances and Applications in Statistical Sciences Journal, 2(2), 303314. [10] Britos, P. et al. 2005. Minera de Datos Basada en Sistemas Inteligentes. Editorial Nueva Librera. [11] Kogan, A. et al. 2007. Algunos resultados experimentales de la integracin de agrupamiento e induccin como mtodo de descubrimiento de conocimiento. Proceedings IX Workshop de Investigadores en Ciencias de la Computacin, 11-15. Universidad Nacional de la Patagonia San Juan Bosco, Trelew, Argentina. [12] Kohonen, T. (2001). Self-Organizing Maps. Springer series in information sciences. Ed Springer, Helsinki University of Technology Neural Networks Research Centre P.O. Box 5400 02, 3rd Edition.

[13] McQueen, J. 1967. Some Methods for Classification and Analysis of Multivariate Observation. 5th Berkeley Proceedings of Simposium on Mathematics, Statistics and Probability, 1, 281-297. [14] Yang, Y. 1999. An evaluation of statistical approaches to text categorization. Information Retrieval, 1(1-2), 6990. [15] Witten, I. H. & Frank, E. 2005. Data Mining Practical Machine Learning Tools and Techniques. Ed. Morgan Kaufmann. [16] Clark, P. & Niblett, T. The CN2 Induction Algorithm. Machine Learning, 3(4), 261-283. [17] Michalski, R. et al. 1986. The Multi-Purpose Incremental Learning System AQ15 and Its Testing Application to Three Medical Domains. Proceedings of AAAI-86, 10411045. [18] Soman, K. P.; Diwakar, S. & Ajay, V. 2006. Insight into Data Mining: Theory and Practice. Prentice-Hall.

28

Comparison of Estimation Metrics for Information Mining Projects Comparacin de Mtricas de Estimacin para Proyectos de Explotacin de Informacin
Programa de Doctorado en Ciencias Informticas. Facultad de Informtica. Universidad Nacional de La Plata. Argentina. ppytel@gmail.com 2 Grupo de Investigacin en Explotacin de Informacin. Laboratorio de Informtica Aplicada. Universidad Nacional de Ro Negro. Argentina. paobritos@gmail.com 3 Grupo Investigacin en Sistemas de Informacin. Departamento Desarrollo Productivo y Tecnolgico. Universidad Nacional de Lans. Argentina. rgarcia@unla.edu.ar
1

Pablo Pytel1, Paola Britos2, Ramn Garca-Martnez3

INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo Recibido: 23/04/2012 Correcciones: 29/05/2012 Aceptado: 31/05/2012 Palabras clave Aseguramiento de calidad, mtricas mtodos de estimacin de esfuerzo, explotacin de informacin, ingeniera en software. Categories and Subject Descriptors D.2.8 [Software Engineering]: Metrics Process metrics. General Terms Software Engineering, Validation Keywords Quality assurance, metrics, effort estimation method, information mining, software engineering.

ABSTRACT Software Quality Assurance Software is a "protection activity" that applies through the whole process of software engineering. Among other mechanisms, it includes the metric measurement of the product and project. On the other hand, to improve processes of Information Mining projects it is necessary to register quality metrics as the models for assessing project productivity that can be used to establish targets for improvement. These models need the estimation of the activities effort at the beginning of the project. In this context, this paper has the objective of analysing two existing estimation methods for Information Mining Projects, a method oriented to relatively large-sized projects and another oriented to small-sized projects which are normally required by the Small and Medium Enterprises (SMEs). RESUMEN El Aseguramiento de la Calidad del Software es una actividad de proteccin que se aplica a lo largo de todo el proceso de ingeniera software incluyendo entre otros los mecanismos de medicin sobre mtricas del producto y del proyecto. Por otro lado, para mejorar los procesos correspondientes al desarrollo de Proyectos de Explotacin de Informacin se identifica la necesidad de registrar mtricas de calidad como los modelos para evaluar la productividad del proyecto que permiten establecer objetivos de mejora. Para ello es necesario estimar los esfuerzos al comienzo del proyecto. De esta manera, en este contexto, este trabajo tiene el objetivo de analizar dos mtodos de estimacin existentes para Proyectos de Explotacin de Informacin, uno orientado a proyectos con tamao relativamente grande y otro orientado a proyectos pequeos que son los normalmente requeridos por las Pequeas y Medianas Empresas (PyMEs).

1. INTRODUCCIN El Aseguramiento de la Calidad del Software (SQA) es una actividad de proteccin que se aplica a lo largo de todo el proceso de ingeniera software [1] incluyendo entre otros los mecanismos de medicin sobre mtricas del producto y del proyecto. Estas mtricas comprenden un amplio rango de actividades que incluyen el aseguramiento y control de calidad, modelos de fiabilidad, modelos para evaluacin de ejecucin y modelos para evaluar la productividad del proyecto. Al conocer el estado actual de desarrollo, permite establecer objetivos de mejora [2]. Por otro lado, la Explotacin de Informacin es una subdisciplina de la informtica relativamente nueva y vinculada a la Inteligencia de Negocio [3]. Esta disciplina engloba un conjunto de tcnicas encaminadas a la extraccin de conocimiento procesable, implcito en el almacn de datos de la organizacin. Dicho conocimiento es previamente desconocido y puede resultar til para algn proceso [4, 5]. Al intentar llevar adelante diferentes Proyectos de Explotacin de Informacin con un alto grado de previsibilidad y

calidad se utilizan distintos modelos de produccin y metodologas [6]. Esto incluye el registro de mtricas para suministrar informacin relevante a tiempo y para intentar mejorar tanto los procesos como los productos. Dentro de las mtricas a utilizar se destaca la medicin del esfuerzo del proyecto para evaluar la productividad del proyecto. Para ello se debe realizar estimaciones al comienzo del proyecto, las cuales son comparadas con los valores reales del proyecto a su finalizacin. De esta manera se destaca la necesidad de contar con mtodos de estimacin de esfuerzo confiables para Proyectos de Explotacin de Informacin. Dada las diferencias que existen entre un proyecto convencional de construccin de software y un proyecto de explotacin de informacin, los mtodos usuales de estimacin no son aplicables ya que los parmetros a ser utilizados son de naturalezas diferentes. Por ejemplo, las herramientas de estimacin de software convencional como COCOMO II [7] o PRICE-S [8] utilizan como parmetros la cantidad de lneas de cdigo, la experiencia del equipo de trabajo, caractersticas de la plataforma de desarrollo, entre otras. Sin embargo, en

29

proyectos de explotacin de informacin existen otras caractersticas que deben ser consideradas para la estimacin, como por ejemplo, cantidad de fuentes de informacin, nivel de integracin de los datos, el tipo de problema a ser resueltos, entre las ms representativas de este tipo de proyectos. Por otro lado, en [9] se propone un mtodo analtico de estimacin para proyectos de explotacin de informacin el cual se denomina Matemtico Paramtrico de Estimacin para Proyectos de Data Mining (en ingls Data Mining Cost Model, o DMCoMo). Pero segn sus autores este mtodo se puede considerar confiable en un rango de esfuerzo muy superior al de los proyectos pequeos que son los que usualmente requieren las Pequeas y Medianas Empresas [10]. Por lo tanto, en este contexto este trabajo tiene el objetivo de analizar dos mtodos de estimacin existentes para Proyectos de Explotacin de Informacin. Para ello primero se realiza un anlisis del mtodo de estimacin DMCoMo (seccin 2), luego se describe un nuevo mtodo de estimacin orientado a las Pequeas y Medianas Empresas (PyMEs) propuesto por los autores (seccin 3) realizando una comparacin de ambos mtodos utilizando datos de proyectos reales (seccin 4). Finalmente se indican algunas conclusiones y las futuras lneas de trabajo (seccin 5). 2. ANLISIS DEL MTODO DMCoMo En esta seccin se realiza el anlisis del mtodo de estimacin Matemtico Paramtrico de Estimacin para Proyectos de Data Mining (en ingls Data Mining Cost Model, o DMCoMo). Primero se realiza una breve descripcin del mtodo (seccin 2.1) se delimita el problema detectado (seccin 2.2) y se presentan los resultados del anlisis realizado (2.3) con sus conclusiones (2.4). 2.1 Descripcin del Mtodo DMCoMo El mtodo DMCoMo [9] es un modelo analtico de estimacin de la familia de COCOMO [7] que permite estimar los meses/hombre que sern necesarios para desarrollar un proyecto de explotacin de informacin desde su concepcin hasta su puesta en marcha. Los modelos de estimacin analticos se definen a travs de la aplicacin de mtodos de regresin en datos histricos para obtener relaciones matemticas entre las variables (tambin llamadas factores de costo) representadas en ecuaciones matemticas. DMCoMo define 23 factores de costo los cuales estn vinculados a las caractersticas ms importantes de los proyectos de explotacin de informacin. Estos factores de costo se clasifican en seis categoras que se indican en la Tabla 1. Una vez que los valores de los factores de costo son definidos, se ingresan en las ecuaciones matemticas suministradas por el mtodo. DMCoMo dispone de dos frmulas (Tabla 2), una que utiliza 23 factores de costo como variables (frmula denominada como MM23) que puede ser utilizada cuando el proyecto est bien definido y otra de 8 factores de costo como variables

(frmula MM8) que puede utilizarse cuando no todos los datos del proyecto se encuentran definidos. Como resultado de ingresar los valores a la ecuacin correspondiente, se obtiene la cantidad de meses/hombre correspondiente al proyecto.
Tabla 1. Categoras y Factores de Costo de DMCoMo
CATEGORA FACTOR DE COSTO Cantidad de Tablas (NTAB) Cantidad de Tuplas de las Tablas (NTUP) Cantidad de Atributos de las Tablas (NATR) Grado de Dispersin de los Datos (DISP) Porcentaje de valores NULL (PNUL) Grado de Documentacin de las Fuentes de Informacin Grado de Integracin de Datos Externos (DEXT) Cantidad de Modelos a ser Creados (NMOD) Tipo de Modelos a ser Creados (TMOD) Cantidad de Tuplas de los Modelos (MTUP) Cantidad y Tipo de Atributos por cada Modelo (MATR) Cantidad de Tcnicas Disponibles para cada Modelo
(MTEC) Relacionados al Desarrollo de la Plataforma Relacionados a las Tcnicas y Herramientas (DMOD)

Relacionados a los Datos

Relacionados a los Modelos

Cantidad y Tipo de Fuentes de Informacin Disponibles Distancia y Medio de Comunicacin entre Servidores de
Datos (SCOM) (NFUN)

Herramientas Disponibles para ser Usadas (TOOL) Grado de Compatibilidad de las Herramientas con Otros Nivel de Formacin de los Usuarios en las Herramientas
(NFOR) Software (COMP)

Cantidad de Departamentos Involucrados en el Proyecto

Relacionados al Proyecto Relacionados al Equipo de Trabajo

Grado de Documentacin que es necesario generar (DOCU) Cantidad de Sitios donde se realizar el Desarrollo y su
Grado de Comunicacin (SITE)

(NDEP)

Grado de Familiaridad con el Tipo de Problema (MFAM) Grado de Conocimiento de los Datos (KDAT) Actitud de los Directivos (ADIR)

Tabla 2. Frmulas de DMCoMo

MM23 = 78,752 + 2,802 x NTAB + 1,953 x NTUP + 2,115 x NATR + 0,345 x PNUL + ( - 2,656 ) x DMOD + 2,586 x DEXT + ( -0,456 ) x NMOD + 6,032 x TMOD + ( -4,543) x MFAM + 4,312 x MTUP + 4,966 x MATR + ( -2,591 ) x MTEC + 3,943 x NFUN + 0,896 x SCOM + ( -4,615 ) x TOOL + ( -1,831 ) x COMP + ( -4,689 ) x NFOR + ( -3,756) x ADIR + 2,931 x NDEP + ( -0,892 ) x DOCU + 2,135 x SITE + ( -0,214 ) x KDAT MM8 = 70,897 + 2,368 x NTAB + ( -3,275) x MFAM + 2,885 x NATR + 4,792 x DISP + ( -3,842 ) x NFOR + 2,713 x DEXT + 7,257 x TMOD + 4,615 x MATR

2.2 Problema Detectado del Mtodo DMCoMo El problema identificado es motivado por la propia limitacin sealada en [9] debido a las caractersticas de los 15 proyectos utilizados para la validacin del mtodo. Los autores declaran que DMCoMo se considera confiable para estimar el esfuerzo de proyectos de explotacin de informacin que se encuentren en el rango de esfuerzo de 90 a 185 meses/hombre (es decir 7,5 a 15,42 aos/hombre). Si el esfuerzo del proyecto se encuentra fuera de este rango, el comportamiento del mtodo es desconocido. Sin embargo, por experiencia se conoce que los proyectos de explotacin de informacin utilizados en las PyMEs poseen un esfuerzo mucho menor a los 90 meses/hombre. Para realizar una revisin inicial del comportamiento de DMCoMo se ha utilizado un proyecto de tamao pequeo.

30

A partir de las caractersticas del proyecto, se definen los valores de los factores de costo y se calculan los esfuerzos correspondientes a las frmulas (ver Tabla 3). El objetivo del proyecto era la deteccin de evidencias de causalidad entre Satisfaccin General e Internet, y fue desarrollado por 3 personas en 4 meses (es decir que el esfuerzo total es 12 meses/hombre). Como se puede ver, el mtodo DMCoMo sobreestima el esfuerzo requerido para el proyecto en aproximadamente un 630%, con un error para la frmula MM23 de 64,56 meses/hombre, y de 63,86 meses/hombre para MM8.
Tabla 3. Revisin inicial de DMCoMo
Factor de Costo
ADIR COMP DEXT DISP DMOD DOCU KDAT MATRn MATRt MFAM MTEC MTUP

Para realizar un anlisis ms detallado del comportamiento de las frmulas por tamao de proyecto se utilizan grficos Boxplot (ver Tabla 5). Estos grficos permiten ver en un nico grfico los datos correspondientes a los lmites superior e inferior (valores mximo y mnimo), el desvo mximo (media ms la desviacin estndar) y mnimo (media menos la desviacin estndar) y la media de los resultados obtenidos en el experimento.
Tabla 5. Grficos Boxplot por frmula
Frmula

Valor
1 3 2 1 5 5 2 3 1

Factor de Costo
NFOR NFUN NMOD NTAB NTUP PNUL SCOM SITE TMOD

Valor
3 3 3 0 1 2 4 3 1

MM23

4 TOOL 1 2 NATR 1 2 NDEP 2 Esfuerzo Real del Proyecto = 12 meses/hombre Esfuerzo Estimado por MM23 = 76,56 meses/hombre Esfuerzo Estimado por MM8 = 75,86 meses/hombre

MM8

Por lo tanto, se considera necesario realizar un estudio detallado del comportamiento de DMCoMo con una particular focalizacin en proyectos pequeos. Para ello se ha utilizado el mtodo de simulacin Monte Carlo [11] generando en forma pseudo-aleatoria un banco de pruebas con los datos de 30.000 proyectos de explotacin de informacin (distribuidos en forma equitativa en tres rangos de tamao: Proyectos Pequeos, Medianos y Grandes). Luego se han aplicado las frmulas MM23 y MM8 definidas por DMCoMo para calcular los esfuerzos estimados (Datos disponibles en http://tinyurl.com/DMCoMoData). 2.3 Resultados del Anlisis Realizado para DMCoMo A partir del banco de prueba con los proyectos generados en forma pseudo-aleatoria se procede a realizar un anlisis estadstico de los mismos. En la Tabla 4 se indica la media estadstica obtenida por cada una de las frmulas de DMCoMo y tamao de proyecto. De esta tabla se puede ver que la media de la frmula MM23 en proyectos medianos es un 52% ms grande que la de proyectos pequeos y la media de los proyectos grandes es un 42% ms grande que los proyectos medianos (o sea un 117% con respecto a los proyectos pequeos). Por otro lado, la frmula MM8 posee un crecimiento menor por escalones de aproximadamente el 22% con respecto al tamao anterior.
Tabla 4. Media por frmula y tamao de proyecto
MEDIA (en meses/hombre) Proyectos Pequeos Proyectos Medianos Proyectos Grandes MM23 84,41 128,89 183,45 MM8 102,59 126,30 148,51

Al realizar la primera observacin de estos grficos, se nota que los costos de ambas frmulas poseen un solapamiento entre s, siendo mayor para la frmula de 8 factores de costo (variable MM8) que la de 23 factores de costo (MM23). Adems se puede observar que los valores de MM23 poseen costos estimados dispersos entre 33,16 meses/hombre (valor mnimo para proyectos pequeos) y 234,14 meses/hombre (valor mximo para proyectos grandes) y los valores de MM8 se encuentran comprendidos entre 71,45 y 183,09 meses/hombre. Entonces, debido a que al variar el tamao del proyecto la frmula MM23 crece aproximadamente el doble con respecto a MM8, se puede decir que es ms conservadora. Al observar en los grficos el desvo estndar donde estn contenidos la mayor cantidad de los proyectos (ms del 70% de los proyectos para cada muestra de 10.000 proyectos) se confirma este comportamiento. 2.4 Conclusiones para DMCoMo A partir de los anlisis realizados se puede indicar que para los proyectos medianos el costo estimado por ambas frmulas es muy similar (casi idntico en algunos casos), pero esto no sucede en los otros tamaos de proyectos. En los proyectos pequeos los valores estimados por la frmula MM8 siempre son superiores a los estimados por MM23, mientras que en los proyectos grandes sucede lo contrario. En todos los casos los mnimos valores estimados son de 33,16 meses/hombre para MM23 y 71,45 meses/hombre para MM8. Por lo que se puede concluir que DMCoMo siempre tiende a

31

sobreestimar los esfuerzos de los proyectos. Esto significa que a pesar de que se podra aplicar para proyectos medianos y grandes, el mtodo no es recomendable para proyectos pequeos. 3. MTODO DE ESTIMACIN PARA PyMEs Debido a la necesidad detectada de contar con un mtodo de estimacin fiable para proyectos de tamao pequeo, los autores han propuesto un nuevo mtodo de estimacin analtico con nfasis en las caractersticas de las PyMEs. Para ello primero se identifican y describen las principales caractersticas de los proyectos en PyMEs que son utilizadas para identificar los factores de costo del mtodo propuesto y luego se procede a especificar la frmula mediante regresin Tanto para la definicin del mtodo propuesto y su posterior validacin se ha utilizado informacin de 44 proyectos reales de explotacin de informacin (http://tinyurl.com/proy-PYMES) que fueron recolectados por investigadores del Grupo de Investigacin en Sistemas de Informacin del Departamento de Desarrollo Productivo y Tecnolgico de la Universidad Nacional de Lans (GISI-DDPyTUNLa), investigadores del Grupo de Estudio en Metodologas de Ingeniera de Software de la Facultad Regional Buenos Aires de la Universidad Tecnolgica Nacional (GEMIS-FRBA-UTN), e investigadores del Grupo de Investigacin en Explotacin de Informacin de la Sede Andina (El Bolsn) de la Universidad Nacional de Ro Negro (SAEB-UNRN). Debe notarse que todos estos proyectos fueron realizados utilizando la metodologa CRISP-DM [12], por lo que el mtodo propuesto se considera confiable para proyectos de explotacin de informacin a ser desarrollados con dicha metodologa. 3.1 Principales Caractersticas de Proyectos de Explotacin de Informacin en PyMEs Segn el informe de las PyMEs y el reporte de espritu empresarial [13] de la Organizacin para la Cooperacin y el Desarrollo Econmico (OCDE) las PyMEs constituyen la forma dominante de organizacin empresarial en todos los pases de todo el mundo, representando ms del 95% y hasta el 99% de la poblacin de empresas segn el pas. Sin embargo, a pesar de que es conocida la importancia de las PyMEs, no existe un criterio universal para identificarlas. Dependiendo de cada pas y regin se utilizan diferentes criterios cuantitativos y cualitativos para reconocer a una organizacin como PyME. De esta forma, en Latinoamrica cada pas tiene una definicin diferente [14]: Argentina identifica como PyME a las empresas autnomas que poseen una facturacin menor a US$ 20.000 por ao (monto mximo que depende de la actividad realizada); Brasil incluye a todas las compaas con 500 empleados o menos mientras que Colombia considera como PyME a las empresas que poseen hasta 200 empleados y activos menores a los US$ 6.500. En este sentido la Organizacin Internacional para la Estandarizacin

(ms conocida como International Organization for Standardization o ISO) ha reconocido la necesidad de especificar definir los perfiles de ciclos de vida para proyectos de ingeniera en software en pequeas entidades (denominadas en ingls Very Small Entities o VSE) y se encuentra trabajando en el estndar ISO/IEC 29110 [15]. El trmino VSE fue definido por el grupo de trabajo 24 de SO/IEC JTC1/SC7 como cualquier empresa, organizacin, departamento o proyecto que cuenta con a lo ms 25 personas [16]. A partir de estas definiciones y nuestra propia experiencia, en este trabajo contempla que un proyecto de explotacin de informacin para PyMEs se encuentra demarcado como un proyecto realizado en una empresa de 250 empleados o menos donde los gerentes de alto nivel (por lo general los propietarios de la empresa) necesitan obtener conocimiento no trivial extrado de las bases de datos disponibles para resolver un problema de negocio especfico, sin riesgos especiales en juego. Como normalmente los miembros de la empresa no tienen los conocimientos necesarios, el proyecto es realizado por consultores especializados contratados para llevar adelante el proyecto. Desde nuestra experiencia podemos restringir al equipo del proyecto en un mximo de 25 personas (incluyendo tanto los consultores subcontratados y al personal de la empresa involucrada) para realizar el proyecto en menos de un ao. Las primeras tareas de un proyecto de explotacin de informacin son similares a las de un proyecto de desarrollo de software convencional, dado que se deben educir las necesidades y deseos de los interesados (stakeholders) de la organizacin. Pero, en estos proyectos, adems se necesita conocer las fuentes de informacin disponibles en la organizacin por lo que es preciso relevar los repositorios existentes junto con su estructura. Como estos repositorios suelen no estar correctamente documentados, es necesario entrevistar tambin a los expertos en datos de la organizacin. Ya que estos expertos son escasos y con poca disponibilidad, ser necesario entonces requerir a su buena disposicin (y la de sus jefes) para que participen en las sesiones de educcin para identificar las caractersticas de la organizacin y de los repositorios a ser utilizados. Por otro lado, la infraestructura de la Tecnologas de la Informacin y la Comunicacin (TIC) de las PyMEs es analizada. En [17] se indica que en Latinoamrica ms del 70% de las PyMEs cuentan con una infraestructura informtica, pero slo el 37% posee servicios automatizados y/o software propio para realizar sus actividades. En general, hacen uso de aplicaciones comerciales (sobre todo manejadores de planillas de clculo y de documentos) para registrar la informacin comercial y operativa. Esto significa que los repositorios a ser utilizados en el proyecto estarn implementados en diferentes formatos y tecnologas. Aunque estos repositorios no suelen ser grandes (normalmente no superan el milln de registros), las tareas de

32

preparacin de datos (es decir, limpieza, formateo e integracin de los datos) tendrn un esfuerzo considerable. Este esfuerzo puede reducirse si se dispone de una herramienta software que las posee ya implementadas. En ese caso no se necesitar desarrollar un software especfico para realizarlas. 3.2 Identificacin de los Factores de Costo del Mtodo de Estimacin Propuesto para PyMEs Teniendo en cuenta las caractersticas de los proyectos de Explotacin de Informacin para PyMEs que se indican en la seccin 3.1, se definen ocho factores de costos. Se han definido pocos factores de costo, ya que como se demuestra en [18], al momento de crear un nuevo mtodo de estimacin es preferible ignorar muchos de los datos no significativos para evitar que el modelo sea demasiado complejo y por lo tanto poco prctico. De esta manera se busca eliminar las variables tanto irrelevantes como dependientes, y adems reducir la varianza y el ruido. Los factores de costo han sido seleccionados teniendo en cuanta las tareas ms crticas de la metodologa CRISP-DM: en [19] se indica que actualmente la construccin de los modelos de minera de datos y buscar los patrones es bastante simple, pero el 90% de los esfuerzos del proyecto estn incluidos en el pre-procesamiento de los datos (es decir la fase de Preparacin de los Datos de CRISP-DM). A partir de nuestra experiencia, las otras tareas crticas se relacionan con la fase de Comprensin del Negocio (entre las que se destacan el entendimiento del negocio y la identificacin de los goles del proyecto). Los factores de costos propuestos se encuentran agrupados en tres grupos dependiendo de su naturaleza: Factores de costo relacionados al proyecto: Tipo de objetivo de explotacin de informacin (OBTY). Este factor de costo analiza el objetivo del proyecto de Explotacin de Informacin considerando el tipo de proceso a ser aplicado para obtenerlo de acuerdo a la definicin realizada en [20]. Los posibles valores de este factor de costo se indican en la Tabla 6.
Tabla 6. Valores del factor de costo OBTY
Valor
1 2 3 4 5

datos. Se sobreentiende que si un proyecto de explotacin de informacin fue contratado, por lo menos la alta gerencia va a apoyar el mismo. Los posibles valores de este factor de costo se indican en la Tabla 7.
Tabla 7. Valores del factor de costo LECO
Valor
1 2 3 4

Descripcin
Tanto los directivos como el personal poseen buena disposicin para colaborar en el proyecto. Slo los directivos poseen buena disposicin para colaborar en el proyecto mientras que el personal es indiferente al proyecto. Slo la alta gerencia posee buena disposicin para colaborar en el proyecto mientras que la gerencia media y el personal es indiferente. Slo la alta gerencia posee buena disposicin para colaborar en el proyecto pero la gerencia media no desea colaborar.

Factores de costo relacionados a los datos: Cantidad y tipo de los repositorios de datos disponibles (AREP). Se analizan los repositorios de datos disponibles (es decir sistemas gestores de bases de datos, planillas de clculos, documentos entre otros). En este caso interesa saber tanto la cantidad de repositorios disponibles (pblicos o privados de la organizacin) como la tecnologa en que se encuentran implementadas. No interesa conocer la cantidad de tablas que posee cada repositorio dado que se entiende que la integracin de los datos dentro de un repositorio es relativamente sencilla (sobre todo al utilizar sistemas gestores de bases de datos por poder ser realizada con un comando query). Sin embargo, dependiendo de la tecnologa, la complejidad de las tareas de integracin de los datos puede ser mayor o menor. Criterios recomendados: Si todos los repositorios estn implementados con la misma tecnologa, entonces se consideran como compatibles para la integracin. Si todos los repositorios permiten exportar los datos en un formato comn, entonces pueden ser considerados como compatibles para la integracin al realizar la integracin con estos datos exportados. Por otro lado, si existen repositorios que no estn en forma digital (es decir impreso en papel) se considera que la tecnologa ser no compatible pero el mtodo de estimacin no puede predecir el tiempo requerido para realizar la digitalizacin de esta informacin ya que esto puede variar de acuerdo a muchos factores externos (como son la longitud, diversidad, formato entre otros). Los posibles valores de este factor se indican en la Tabla 8.
Tabla 8. Valores del factor de costo AREP
Valor
1 2 3 4 5

Descripcin
Se desea conocer los atributos que caracterizan el comportamiento o la descripcin de una clase ya conocida. Se desea dividir los datos disponibles en grupos sin poseer una clasificacin conocida previamente. Se desea conocer los atributos que caracterizan a grupos sin poseer una clasificacin conocida previamente. Se desea conocer los atributos que poseen mayor frecuencia de incidencia sobre un comportamiento o la identificacin de una clase conocida. Se desea conocer los atributos que poseen mayor frecuencia de incidencia sobre la identificacin de una clase desconocida previamente.

Grado de apoyo de los miembros de la organizacin (LECO). El grado de apoyo y participacin de los miembros de la organizacin se analiza viendo si la alta gerencia (normalmente los dueos de la PyME), la gerencia media (supervisores y/o jefes de rea) y/o el resto del personal estn dispuestos a ayudar al equipo de trabajo para comprender el negocio y los

Descripcin
Slo 1 repositorio disponible Entre 2 y 4 repositorios con tecnologa compatible para integracin Entre 2 y 4 repositorios con tecnologa no compatible para integracin Ms de 5 repositorios con tecnologa compatible para integracin Ms de 5 repositorios con tecnologa no compatible para integracin la la la la

33

 Cantidad de tuplas disponibles en la tabla principal (QTUM). Este factor de costo considera la cantidad total de tuplas (registros) disponibles en la tabla principal utilizada para aplicar los algoritmos de minera de datos. Los posibles valores de este factor de costo se indican en la Tabla 9.
Tabla 9. Valores del factor de costo QTUM
Valor
1 2 3 4 5 6

Descripcin
Hasta 100 tuplas en la tabla principal Entre 101 y 1.000 tuplas en la tabla principal Entre 1.001 y 20.000 tuplas en la tabla principal Entre 20.001 y 80.000 tuplas en la tabla principal Entre 80.001 y 5.000.000 tuplas en la tabla principal Ms de 5.000.000 tuplas en la tabla principal

tener un mnimo conocimiento y experiencia en el desarrollo de proyectos de explotacin de informacin. No obstante pueden poseer o no experiencia en proyectos similares en el mismo tipo de negocio y los datos a ser utilizados. Por lo tanto se debe evaluar el conocimiento y experiencia previa en proyectos anteriores similares al que se est llevando a cabo con respecto al tipo de negocio, los datos a ser utilizados y los objetivos que se esperan lograr. Los valores de este factor se indican en la Tabla 12.
Tabla 12. Valores del factor de costo KEXT
Valor
1

Descripcin
El equipo ha trabajado en tipos de organizaciones y con datos similares para obtener los mismos objetivos El equipo ha trabajado en tipos de organizaciones similares pero con datos diferentes para obtener los mismos objetivos El equipo ha trabajado en otros tipos de organizaciones y con datos similares para obtener los mismos objetivos El equipo ha trabajado en otros tipos de organizaciones y con datos diferentes para obtener los mismos objetivos El equipo ha trabajado en tipos de organizaciones diferentes, con datos diferentes y otros objetivos

Cantidad de tuplas disponibles en tablas auxiliares (QTUA). Esta variable considera la cantidad aproximada de tuplas (registros) disponibles en las tablas auxiliares (si existieran) que son utilizadas para agregar informacin a la tabla principal (como es la tabla que define las caractersticas del producto a partir de su identificador en la tabla de ventas). Estas tablas auxiliares normalmente suelen tener menos registros que la tabla principal. Los posibles valores de este factor se indican en la Tabla 10.
Tabla 10. Valores del factor de costo QTUA
Valor
1 2 3 4

2 3 4 5

Descripcin
No se utilizan tablas auxiliares Hasta 1.000 tuplas en las tablas auxiliares Entre 1.001 y 50.000 tuplas en las tablas auxiliares Ms de 50.000 tuplas en las tablas auxiliares

Funcionalidad de las herramientas disponibles (TOOL). Finamente, este factor de costo evala las caractersticas de las herramientas disponibles para realizar el proyecto. Para ello se analiza tanto las funcionalidades de preparacin de los datos como los algoritmos de minera de datos que posee implementadas. Sus posibles valores de este factor de costo se indican en la Tabla 13.
Tabla 13. Valores del factor de costo TOOL
Valor
1 2 3 4 5

Nivel de conocimiento sobre los datos (KLDS). Considera el nivel de documentacin existente sobre los repositorios de datos. Es decir, se analiza si existe un documento donde se indique la tecnologa en que estn implementados, los campos que componen sus tablas y la forma en que los datos son creados, modificados, y/o eliminados. En caso de que esta informacin no se encuentre, ser necesario realizar reuniones con los expertos (encargados de la administracin y mantenimiento de los repositorios). Los valores de este factor se indican en la Tabla 11.
Tabla 11. Valores del factor de costo KLDS
Valor
1 2 3 4 5 6

Descripcin
La herramienta posee funciones tanto para el formateo e integracin de los datos (permitiendo importar ms de una tabla de datos) como para aplicar las tcnicas de minera de datos. La herramienta posee funciones tanto para el formateo como para aplicar las tcnicas de minera de datos, y permite importar ms de una tabla de datos en forma independiente. La herramienta posee funciones tanto para el formateo como para aplicar las tcnicas de minera de datos, pero slo permite importar una tabla de datos. La herramienta posee funciones slo para aplicar las tcnicas de minera de datos, y permite importar ms de una tabla de datos. La herramienta posee funciones slo para aplicar las tcnicas de minera de datos y slo permite importar una tabla de datos.

Descripcin
Todas las tablas y repositorios estn correctamente documentados Ms del 50% de las tablas y repositorios estn correctamente documentados y existen expertos en los datos disponibles para explicarlos Menos del 50% de las tablas y repositorios estn correctamente documentados pero existen expertos en los datos disponibles para explicarlos Las tablas y repositorios no estn documentadas pero existen expertos en los datos disponibles para explicarlos Las tablas y repositorios no estn documentados y existen expertos en los datos pero no estn disponibles para explicarlos Las tablas y repositorios no estn documentados y no existen expertos en los datos para explicarlos

3.3 Especificacin de la Ecuacin del Mtodo de Estimacin Propuesto para PyMEs Una vez que los factores de costo fueron definidos, se han utilizado para caracterizar 34 proyectos reales de explotacin de informacin recolectados junto con su esfuerzo real (provistos por colegas como se ha indicado anteriormente). Un mtodo de regresin lineal multivariante [21] fue aplicado sobre estos datos para obtener una ecuacin lineal de la forma utilizada por los mtodos de la familia COCOMO. Como resultado del proceso de regresin se obtiene la frmula indicada en la Tabla 14.
Tabla 14. Frmula del mtodo propuesto para PyMEs
PEM = 0.80 OBTY + 1.10 LECO 1.20 AREP 0.30 QTUM 0.70 QTUA + 1.80 KLDS 0.90 KEXT + 1.86 TOOL 3.30 donde: - PEM es el esfuerzo estimado por el mtodo de estimacin para PyMEs (en meses/hombre) - OBTY, LECO, AREP, QTUM, QTUA, KLDS, KEXT y TOOL son los valores correspondientes de los factores de costo definidos en las tablas 8 a 16.

Factores de costo relacionados a los recursos: Nivel de conocimiento y experiencia del equipo de trabajo (KEXT). Analiza la capacidad del equipo de trabajo que se ocupar del proyecto. El equipo de trabajo contratado para realizar el proyecto debe

34

4. COMPARACIN DE LOS MTODOS Para comparar el comportamiento del mtodo DMCoMo (descripto en la seccin 2) y el mtodo de estimacin orientado para PyMEs (descripto en la seccin 3) se utiliza la informacin de otros 10 proyectos reales recolectados (provistos por colegas como se ha indicado anteriormente). Con esta informacin primero se ha calculado los esfuerzos por el mtodo DMCoMo mediante la definicin de cada uno de los factores de costo y su aplicacin en las frmulas MM23 y MM8. De la misma manera, se realiza el mismo procedimiento para calcular el esfuerzo para el mtodo propuesto para PyMEs con frmula PEM definida en la seccin 3. Con los esfuerzos ya calculados se completa la Tabla 15 donde se muestra por cada proyecto su esfuerzo real (EfR), los esfuerzos calculados por el mtodo DMCoMo (MM8 y MM23) y por el mtodo propuesto para PyMEs (PEM) indicando tambin los errores absolutos (es decir la diferencia entre el esfuerzo real y el calculado por cada mtodo) y los errores relativos (ErRel que es calculado como el error absoluto dividido por el esfuerzo real del proyecto).

Para mayor claridad, esta comparacin se refleja en un grfico boxplot (Figura 1) donde el comportamiento del esfuerzo real y los calculados se muestran indicando los valores mnimos y mximos, el rango del desvo estndar y el valor medio para cada uno.

Fig. 1: Comportamiento del Esfuerzo Real, el mtodo DMCoMo y el Mtodo de Estimacin

Tabla 15. Comparacin de los esfuerzos calculados (en meses/hombre)

# EfR MM8 84,23 67,16 67,16 118,99 110,92 80,27 96,02 116,87 97,63 105,32 EfR - MM8 -81,82 -60,16 -65,52 -115,34 -101,57 -68,65 -89,29 -111,47 -89,26 -103,75 88,68 380,28 DMCoMo ErRel MM23 MM8 -3.400% 94,88 -859% 51,84 -3.991% 68,07 -3.160% 111,47 -1.087% 122,52 -590% 81,36 -1.328% 92,49 -2.064% 89,68 -1.066% 98,74 -6.640% 103,13 EfR - MM23 -92,47 -44,84 -66,43 -107,82 -113,17 -69,73 -85,76 -84,28 -90,36 -101,56 85,64 428,99 ErRel MM23 -3.843% -641% -4.047% -2.954% -1.211% -600% -1.275% -1.561% -1.079% -6.500% PEM Mtodo para PyMEs ErRel PEM EfR - PEM -0,17 1,00 0,16 1,97 -0,45 6,53 2,95 0,52 -0,33 0,48 1,46 3,98 -7,2% 14,3% 9,8% 54,0% -4,8% 56,1% 43,8% 9,6% -3,9% 30,9%

P1 2,41 P2 7,00 P3 1,64 P4 3,65 P5 9,35 P6 11,63 P7 6,73 P8 5,40 P9 8,38 P10 1,56 Error Medio Varianza del Error

2,58 6,00 1,48 1,68 9,80 5,10 3,78 4,88 8,70 1,08

Al analizar los resultados de la Tabla 15, se puede observar que el error promedio es muy grande (86 meses/hombre, o 7 aos/hombre, para ambas frmulas) con un desvo estndar de aproximadamente 20 meses/hombre respectivamente, DMCoMo siempre tiende a sobreestimar el esfuerzo del proyecto (por lo que los valores de error son siempre negativos) con una proporcin mayor al 590% (menor diferencia para el proyecto #6 y frmula MM8). Por otro lado, al analizar los resultados del mtodo de estimacin para PyMEs (PEM) en la tabla 15, se puede observar que produce un error promedio de aproximadamente 1,46 meses/hombre con un desvo estndar para el error de aproximadamente 2 meses/hombre. Para poder analizar en forma ms detallada este mtodo se muestra en la Figura 2 un grfico boxplot mostrando el comportamiento del esfuerzo real y el calculado por PEM. De este segundo grfico se nota que el mtodo propuesto tiende a generar estimaciones inferiores a las reales con una diferencia general de un mes/hombre (el

promedio del esfuerzo real es de 5,77 meses/hombre y la del mtodo propuesto es de 4,51 meses/hombre).

Fig. 2: comportamiento del Esfuerzo Real y el Mtodo de Estimacin

35

Finalmente, si el esfuerzo real y el estimado para cada proyecto se comparan con diagrama de barras (Figura 3), se puede observar que el mtodo propuesto no es completamente exacto en sus estimaciones: Los proyectos #1, #3, #5, #8 y #9 tienen un esfuerzo estimado con un error absoluto menor a un mes/hombre y un error relativo menor al 10%. Los proyectos #4, #6 y #7 tienen un error relativo mayor al 35% (y menor al 60%) con un error absoluto mximo de 7 meses/hombre (en el caso del proyecto #6). Por ltimo, los proyectos #2 y #10 tienen un error relativo entre 10% y 35% con un error mximo a un mes/hombre (proyecto #2).

estimaciones poseen un error relativo menor al 10%. Estos errores se podran deben a la existencia de factores que estn afectando el clculo del esfuerzo que no han sido considerados por el mtodo de estimacin. 6. AGRADECIMIENTOS El trabajo de investigacin presentado en este artculo ha sido parcialmente financiado por los proyectos 33A105 and 33B102 de la Universidad Nacional de Lans, por los proyectos 40B133 y 40B065 de la Universidad Nacional de Ro Negro, y el proyecto EIUTIBA11211 de la Universidad Tecnolgica Nacional Facultad Regional Buenos Aires. Adems, los autores desean agradecer a los investigadores que han provisto la informacin de proyectos reales en PyMEs utilizados en este trabajo. 7. REFERENCIAS
[1] [2] Pressman, R. 2005. Ingeniera de Software: Un enfoque prctico. McGraw-Hill. Kan, S. H.; Parrish, J. & Manlove, D. 2001. In-process metrics for software testing. IBM Systems Journal, 40(1): 220-241. Burstein, F. et al. 2008. Business Intelligence. Handbook on Decision Support Systems 2, Intl Handbooks on Information Systems, 175-193. Springer. Ferreira, J. E.; Takai, O. K. & Pu, C. 2005. Integration of business processes with autonomous information systems: a case study in government services. Proceedings Seventh IEEE International Conference on E-Commerce Technology, 2005. System Sciences, 471474. Kanungo, S. 2005. Using Process Theory to Analyze Direct and Indirect Value-Drivers of Information Systems. Proceedings 38th Annual Hawaii International Conference on System Sciences, 2005, 231-240 Garca-Martnez, R. et al 2011. In Zapata, J. C. M. et al. (Eds.), Towards an Information Mining Engineering. Software Engineering, Methods, Modeling and Teaching. Editorial Universidad de Medelln, 83-99. Boehm, B. W. et al. 2000. Software Cost Estimation with Cocomo II. Prentice Hall. PRICE System. 1997. PRICE-S Reference Manual Version 3.0. Lockheed-Martin. Marbn, O.; Menasalvas, E. & Fernndez-Baizn, C. 2008. A cost model to estimate the effort of data mining projects (DMCoMo). Information Systems, 33(1), 133150. Garca-Martnez, R.; Lelli, R. & Merlino, H. 2011. Ingeniera de Proyectos de Explotacin de Informacin para PYMES. Proceedings XIII Workshop de Investigadores en Ciencias de la Computacin, 253-257. Kalos, M. H. & Whitlock, P. A. 1986. Monte Carlo Methods. Vol I. Basics. Wiley & Sons. Chapman P. et al. 2000. CRISP-DM 1.0 Step-by-step data mining guide. The CRISP-DM consortium. OECD. 2005. OECD SME and Entrepreneurship Outlook 2005. OECD Publishing. lvarez, M. & Durn, J. 2009. Manual de la Micro, Pequea y Mediana Empresa. Una contribucin a la mejora de los sistemas de informacin y el desarrollo de las polticas pblicas. CEPAL - Naciones Unidas. ISO. 2011. ISO/IEC DTR 29110-1 Software Engineering Lifecycle Profiles for Very Small Entities (VSEs) - Part 1: Overview. Inter. Organization for Standardization.

[3] Fig. 3: Comparacin del EfR y el estimado

5. CONCLUSIONES Dentro de los mecanismos de Aseguramiento de Calidad se incluyen las mtricas. Entre ellas se incluyen los modelos para evaluar la productividad del proyecto que permiten establecer objetivos de mejora. Los Proyectos de Explotacin de Informacin no escapan de dicha necesidad. Para ello se debe realizar estimaciones al comienzo del proyecto, las cuales son comparadas con los valores reales del proyecto a su finalizacin. De esta manera se destaca la necesidad de contar con mtodos de estimacin de esfuerzo confiables para Proyectos de Explotacin de Informacin de tamao pequeo. Este trabajo describe y analiza dos mtodos de estimacin existentes para Proyectos de Explotacin de Informacin: el mtodo de estimacin DMCoMo y el otro un mtodo de estimacin orientado a las PyMEs. Del estudio del mtodo DMCoMo se puede ver que este mtodo genera estimaciones superiores a los 5 aos/hombres, umbral de esfuerzo muy superior al real vinculado a proyectos de PyMEs. Al comparar este mtodo con los esfuerzos de proyectos pequeos se puede ver que tiende a sobrestimar el esfuerzo en casi seis veces ms el real. Por lo tanto se puede indicar que este mtodo slo puede ser utilizado para proyectos con tamao grande. Por otro lado, el mtodo de estimacin orientado a PyMEs produce resultados ms precisos que DMCoMo para proyectos pequeos. Aunque el comportamiento general de este mtodo tiende a ser similar al de los proyectos reales, tiene una leve inclinacin a calcular un esfuerzo inferior al real. De todas formas se destaca que el error medio es de aproximadamente 1,5 meses/hombre y que para los datos de validacin utilizados el 50% de las

[4]

[5]

[6]

[7] [8] [9]

[10]

[11] [12] [13] [14]

[15]

36

[16] Laporte, C.; Alexandre, S. & Renault, A. 2008. Developing International Standards for VSEs. IEEE Computer, 41(3): 98-110 [17] Ros, M. D. 2006. El Pequeo Empresario en ALC, las TIC y el Comercio Electrnico. ICA. [18] Chen, Z. et al. 2005. Finding the right data for software cost modeling. Software, IEEE, 22(6), 38-46.

[19] Domingos, P. et al. 2006. 10 challenging problems in data mining research. International Journal of Information Technology & Decision Making, 5(4), 597-604. [20] Garca-Martnez, R. et al. 2011. Information Mining Processes Based on Intelligent Systems. Proceedings II International Congress on Computer Science and Informatics, 87-94. [21] Weisberg, S. 1985. Applied Linear Regression. Wiley.

37

A process model for requirements elicitation in information mining projects Modelo de proceso para elicitacin de requerimientos en proyectos de explotacin de informacin
Diego Mansilla1, Florencia Pollo-Cattaneo2, Paola Britos3, Patricia Pesado2, Ramn GarcaMartnez 4
1

Grupo de Estudio en Metodologas de Ingeniera de Software. Facultad Regional Buenos Aires. Universidad Tecnolgica Nacional. Buenos Aires, Argentina. dmansilla@educ.ar. 2 Programa de doctorado en Ciencias informticas. Facultad e Informtica. Universidad Nacional de La Plata. La Plata. Buenos Aires. Argentina. fpollo@posgrado.frba.utn.edu.ar. 3 Grupo de Investigacin en Explotacin de informacin. Sede Andina. Universidad Nacional de Ro Negro. Argentina. paobritos@gmail.com. 4 Grupo Investigacin en Sistemas de Informacin. Departamento Desarrollo Productivo y Tecnolgico. Universidad Nacional de Lans. Lans, Argentina. rgarcia@unla.edu.ar. INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo: Recibido: 30/03/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Proceso, elicitacin, requerimientos, proyecto explotacin de informacin. Categories and Subject Descriptors D.2.1 [Requirements/Specifications]: Methodologies General Terms Requirements Engineering. Keywords Process, elicitation, information mining projects, requirements. ABSTRACT A problem addressed by an information mining project is transforming existing business information of an organization into useful knowledge for decision making. Thus, traditional software development process for requirements elicitation, by focusing on the software product and not in information, cannot be used to acquire required information for information mining process. In this context, a process for requirements gathering for information mining projects is presented, emphasizing the following phases: conceptualization, business definition and information mining process identification. RESUMEN La problemtica abordada en los proyectos de explotacin de informacin se basa en transformar la informacin existente de una organizacin en conocimiento til para la toma de decisiones. Los modelos tradicionales de educcin de requisitos, al enfocarse en el producto, no pueden ser utilizados para obtener la informacin requerida para los procesos de explotacin de informacin. En este contexto, se presenta un proceso para elicitacin de requerimientos en proyectos de explotacin de informacin haciendo nfasis en las fases de: conceptualizacin, definicin de negocio e identificacin de procesos de explotacin de informacin.

1. INTRODUCCIN La Ingeniera de Software tradicional ofrece una serie de herramientas y procesos para la elicitacin de requerimientos software que son utilizadas en proyectos de creacin de sistemas de informacin automatizados. Se entiende por requerimientos a la especificacin de lo que debe ser implementado. Ellos son descripciones de cmo debe comportarse el sistema [1]. Los requerimientos suelen clasificarse de diferentes formas, siendo una de las clasificaciones ms consensuada la organizacin de acuerdo al nivel del requerimiento, dividindose en requerimientos de negocio, requerimientos de usuario, requerimientos funcionales y requerimientos de sistema [2]. Las herramientas de elicitacin de la Ingeniera de Software se enfocan en la descripcin de los diferentes tipos de requerimientos, haciendo hincapi en las caractersticas que debe cumplir el producto final. Tradicionalmente, los proyectos de desarrollo de software comienzan por obtener un entendimiento del

dominio del negocio y de las reglas que lo rigen. El entendimiento del dominio permite diferenciar requerimientos, a nivel producto o a nivel dominio del negocio [3], que delimitan el producto a construir respecto del contexto donde ser utilizado. Modelos como el Diagrama de Contexto, Diagramas de flujos de datos, diagramas de secuencia, entre otros, sirven para representar grficamente los procesos de negocio relevado y son utilizados como herramientas para la validacin de los mismos. El analista funcional, que define los requerimientos del producto software a construir, utiliza estas herramientas con el objetivo de definir qu es lo que debe hacer el sistema software y no el cmo hacerlo. Adems, la recopilacin de la informacin est orientada a los datos de entradas y salidas de los productos a desarrollar y cmo esa informacin ser transformada por el sistema. En etapas posteriores del proyecto, se trabaja en el cmo hacer para que el producto software satisfaga las necesidades planteadas por el negocio y en la construccin del mismo. El producto obtenido es, entonces, un sistema software que cumple con las caractersticas esperadas para el contexto en que ser utilizado.

38

A diferencia de los proyectos de desarrollo de software, la problemtica abordada en los proyectos de inteligencia de negocio se basa en transformar la informacin existente en una organizacin en conocimiento til para la toma de decisiones, mediante el uso de herramientas analticas [4]. Los modelos de elicitacin de requerimientos y de gestin de proyectos, al enfocarse en el producto software a construir, no pueden ser utilizados para obtener la informacin requerida por los procesos de explotacin de informacin. En este contexto, se hace necesario transformar la experiencia existente en el uso de las herramientas de elicitacin de requerimientos en el dominio de sistemas software tradicionales en conocimiento que pueda ser utilizado para el armado de los modelos utilizados en la inteligencia de negocio y en los procesos de explotacin de informacin [5-7]. En este trabajo se describir el problema (seccin 2), se presentar un proceso para elicitacin de requerimientos en proyectos de explotacin de informacin (seccin 3), haciendo nfasis en la fase de conceptualizacin (seccin 3.1), en la fase de definicin de negocio (seccin 3.2) y en la identificacin de procesos de explotacin de informacin (seccin 3.3). Luego se propone el estudio de un caso (seccin 4) y se proponen algunas conclusiones y futuras lneas de trabajo (seccin 5). 2. DESCRIPCIN DEL PROBLEMA Actualmente, diversas disciplinas se han estandarizado para poder incorporar buenas prcticas provenientes de las experiencias adquiridas y de la incorporacin de nuevos descubrimientos. La disciplina de gestin de proyectos, por ejemplo, gener un cuerpo de conocimiento donde definen las diferentes reas del proceso de gestin de proyectos. La Ingeniera en software defini diferentes metodologas de desarrollo de sistemas, entre las cuales se establece el proceso de Desarrollo de requerimientos, donde definen las etapas de Elicitacin, Anlisis, Especificacin y Validacin como las actividades a realizar para obtener los requerimientos de un sistema software [1]. Por otro lado, en lo relacionado a proyectos de inteligencia de negocios, existe la metodologa para el desarrollo de sistemas de explotacin de informacin, CRISP-DM [8], P3TQ [9] y SEMMA[10]. En el campo de la explotacin de informacin no existe un nico proceso definido para gestionar los proyectos [11]. Sin embargo, existen aproximaciones que tratan de integrar el conocimiento adquirido en los diferentes proyectos tradicionales de desarrollo de software, como ser el ciclo de vida Kimball [12] y, abordajes para proyectos en el marco de las PyMes [13]. El ciclo de vida Kimball es utilizado en iniciativas de Data Warehouse/Business Intelligence (DW/BI) y se basa en el concepto que los proyectos de DW/BI se componen de diferentes piezas y, slo si stas se completan en

forma apropiada y se integran correctamente, el sistema de DW/BI tendr xito. El problema encontrado es que dichas aproximaciones mencionadas hacen hincapi en metodologas de trabajo asociadas a los proyectos de explotacin de informacin y no adaptan las tcnicas de elicitacin de requerimientos tradicionales de la Ingeniera en Software a las necesidades requeridas por los procesos de explotacin de informacin. Ante esta situacin, es necesario comprender qu pasos se deberan llevar a cabo y, qu tcnicas de elicitacin tradicionales podran adaptarse en proyectos de explotacin de informacin. 3. PROCESO DE ELICITACIN DE REQUERIMIENTOS El proceso que se presenta define un conjunto de actividades de alto nivel que se deben realizar como parte de la etapa de entendimiento del negocio, presentada en la metodologa CRISP-DM, que puede ser utilizada en la definicin de requerimientos de negocio del ciclo de vida de Kimball. El modelo de proceso propuesto descompone la problemtica de la elicitacin de requerimientos para proyectos de explotacin de informacin en diferentes fases, que irn transformando el conocimiento adquirido en cada fase previa. Para cada fase del proceso se identifican qu tcnicas de elicitacin de requerimientos pueden ser utilizadas para resolver la problemtica presentada para cada fase. Este modelo de proceso se contextualiza dentro del concepto de proyecto que, segn el Project Management Institute, es un emprendimiento temporario para crear un producto, resultado o servicio nico [14]. Para los proyectos de explotacin de informacin, el objetivo planteado es identificar requerimientos de informacin y utilizar dicha informacin en la toma de decisiones. En [15] se plantea una propuesta operativa sobre la ejecucin de proyectos de explotacin de informacin, pero sin entrar en el detalle de qu tcnicas de elicitacin pueden utilizarse en el proyecto. Se debe comenzar definiendo diferentes capas dentro de un proyecto de explotacin de informacin. Cada una de estas capas tendr un objetivo y una serie de actividades a realizar, y a su vez, podr seguir descomponindose en capas ms especficas. Para cada actividad se plantea una adaptacin de una tcnica tradicional de elicitacin de requerimientos.
Gestin de Proyecto

Comprensin del Negocio

Entendimiento de los datos

Preparacin de datos

Modelado

Evaluacin

Implantacin

Conceptualizacin del dominio de negocio

Definicin del Negocio

Identificacin de Procesos de Explotacin de Informacin

Fig. 1: Fases propuestas

La Figura 1 refleja las fases estratgicas de un proyecto de explotacin de informacin, enfocndose en las actividades de elicitacin de requerimientos propuestas. La capa de gestin de proyecto se encarga de la coordinacin de las diferentes actividades necesarias para alcanzar los objetivos planteados, es la aplicacin

39

del conocimiento, habilidades y herramientas para alcanzar los requerimientos planteados [14]. La disciplina de gestin de proyectos est definida por el Project Management Institute [14] pero dichas actividades estn fuera del alcance de este proceso. Este trabajo identifica las actividades relacionadas con el proceso expuesto en [12], las que pueden utilizarse como gua de las actividades a realizar dentro de un proyecto de Explotacin de Informacin. El primer paso de dicho proceso es la fase de Conceptualizacin del Negocio. Su objetivo es identificar el vocabulario de negocio y los procesos del mismo, con el fin de poder establecer un lenguaje comn entre el equipo de proyecto y el interlocutor del negocio. La necesidad de establecer este vocabulario radica en que las metodologas de DM-BI han tenido dificultades con el grupo de usuarios respecto del lxico utilizado por los equipos de DM-BI [15]. Esta fase generar los casos de uso del negocio en estudio. Una vez concluida la Conceptualizacin del Negocio, comenzar la fase de Definicin del Negocio cuyo objetivo es definir los conceptos, datos y repositorios de informacin afectados en los diferentes procesos de negocio, utilizando los conceptos identificados en la fase anterior y sus relaciones. Se definir entonces, el vocabulario de conceptos que ser utilizado como lenguaje de comunicacin entre los interlocutores del negocio y los analistas de DM-BI y el modelo conceptual del mismo. Tambin se identificarn los diferentes repositorios de informacin que posee la organizacin, los que almacenan datos relacionados con los conceptos identificados. La fase de Identificacin de Procesos comienza una vez formalizadas las definiciones asociadas al negocio e identificados los repositorios de informacin. Su objetivo es definir la lista de problemas de informacin a resolver y los procesos de explotacin de informacin que debern ser utilizados para cada problema de inteligencia de informacin encontrado. 3.1 Fase de Conceptualizacin La Conceptualizacin es la fase del proceso de elicitacin que ser utilizada por el analista para comprender el lenguaje de la organizacin y los vocabularios especficos del negocio. Esta fase es crucial en el proyecto, ya que la informacin recopilada y las decisiones que se establezcan como resultado de esta fase afectarn al alcance del proyecto y a las soluciones que sern construidas por el mismo [12]. Los proyectos se inician con la identificacin de los interesados en el mismo. De acuerdo a [14], deben identificarse los patrocinadores del proyecto, que son las personas que proveen de apoyo financiero o recursos y los usuarios, que sern los beneficiados por el proyecto. La Figura 2 refleja las diferentes actividades y productos de la fase de conceptualizacin y la Tabla 1 resume las principales entradas y salidas de la misma.

Lista de usuarios a relevar Comprensin del Negocio Relevamiento de Procesos

Documentacin de Relevamiento Elaboracin de Modelos

Modelo de Casos de Uso

Fig. 2: Fase de Conceptualizacin Tabla 1. Entradas y salidas de Fase de Conceptualizacin

Productos Entrada Fase Tarea Entrada Comprensin del Negocio Conceptualizacin Relevamiento de procesos Elaboracin de modelos Formalizacin de proyecto Lista de usuarios a relevar Informe de relevamiento Representacin Documento de Inicio de Proyecto Plantilla de lista de usuarios Plantilla de Informe de Relevamiento Tcnica de Transformacin a utilizar Anlisis de sponsors de proyecto Entrevistas Workshops Otros. Anlisis de relevamiento Productos de salida Salida Lista de usuarios a relevar Informe de relevamiento Documento de Casos de Uso Representacin Plantilla de lista de usuarios Plantilla de Informe de Relevamiento Modelo de Casos de Uso

Los patrocinadores de proyectos pueden seleccionarse de acuerdo al conocimiento que tienen sobre la informacin que administra el negocio, las visiones estratgicas de la organizacin, los problemas de operatoria en los procesos de negocio, entre otros. Depender principalmente quin es el patrocinador del proyecto y qu problemticas de informacin se tratarn de resolver. Inicialmente, se comenzar con un grupo reducido de personas que tengan una visin estratgica del negocio y luego en diferentes iteraciones se podr ir profundizando en niveles ms operativos. La actividad debe generar un listado de usuarios que sern relevados durante la actividad de Relevamiento de procesos de Negocio. Una vez identificados los usuarios principales, se proceder al relevamiento de los procesos de negocio y su modelado en casos de uso. Un proceso de negocio se puede definir como el proceso de utilizacin del negocio por parte de un cliente y cmo va realizando los diferentes flujos de eventos en el sistema, los cuales le permiten al cliente iniciar, llevar a cabo y completar el proceso de negocio [16]. Es una serie de tareas relacionadas que permiten producir un producto o servicio que le es til a un cliente del negocio. Diferentes tcnicas de elicitacin de requerimientos software tradicionales pueden ser de utilidad para la recopilacin de datos relacionados con el funcionamiento del negocio. Si bien estas tcnicas son necesarias para el desarrollo del software a construir, no satisfacen las necesidades de los proyectos de Explotacin de Informacin, ya que stos requieren definir problemticas del negocio en cuanto a informacin existente y disponible en la organizacin, y no las caractersticas que deben tener los sistemas software que almacenan dicha informacin. Las tcnicas de elicitacin de proyectos de desarrollo software enfocan su atencin en los requerimientos de usuario, los cuales tienden a representar las necesidades de los mismos en cuanto a expectativas de funcionalidad, performance, usabilidad y otros atributos relacionados con el software a construir, tienden a definir qu es lo que el usuario espera del sistema. Dentro de las tcnicas tradicionales para recopilacin de informacin podemos mencionar: las entrevistas, la observacin y los talleres de dominio [3]. La informacin obtenida se suele modelar mediante Casos

40

de Uso o lista de eventos [2], siendo estos modelos la base de los procesos de desarrollo de Software. Las tcnicas enfocadas a obtener informacin de negocio y no de producto, pueden utilizarse en los proyectos de explotacin de informacin. En la Elicitacin de Requerimientos de Software se establece el concepto de Usuario de Producto campen. Es la persona que sirve de interlocutor entre los diferentes usuarios y el analista de requerimientos. Es quien tiene una visin clara de lo que el nuevo sistema software har [2]. En proyectos de Explotacin de Informacin se deben identificar estos usuarios campeones, pero en vez de ser interlocutores, sern aquellos usuarios que conozcan el funcionamiento completo del proceso de negocio, independientemente de los sistemas software que soporten al proceso de negocio. Durante la actividad de Elicitacin, el analista de negocio deber enfocarse en la descripcin de las distintas funciones que el negocio realiza. Debe dejar que el interlocutor del negocio exprese sus necesidades en el vocabulario que utiliza habitualmente. El analista deber recopilar tambin las palabras especficas utilizadas en el negocio con el fin de obtener tanto una descripcin de las diferentes tareas que se realizan en cada funcin, como as tambin la terminologa utilizada en cada caso. Esta actividad podr ser documentada mediante la descripcin de los casos de uso, donde el caso corresponder a la definicin de la estructura de pasos que los usuarios del negocio realizan para completar su actividad. Este enfoque difiere del utilizado en el desarrollo de software en el cual el objetivo es describir el negocio y sus flujos de trabajo y no la interaccin del usuario con el sistema software, como se utiliza tradicionalmente al modelo. Por lo tanto, el caso de uso es la secuencia de transacciones en un sistema [17] cuya tarea es producir un resultado de valor medible para un actor individual del sistema, que en el caso de estudio sera el cliente del negocio. La tarea del modelado de casos de uso utiliza la informacin obtenida de los relevamientos de negocio y genera en la ltima actividad de la fase, la elaboracin de modelos. 3.2 Fase de Definicin de Negocio Concluida la actividad de identificacin de los conceptos asociados al negocio en estudio, se comienza a definirlo en trminos de relacin de conceptos, vocabulario y fuentes de informacin que dan soporte a los procesos de negocio. La fase de Definicin de Negocio requiere como entrada los casos de uso definidos en la fase de Conceptualizacin. La Figura 3 refleja las actividades y productos de la fase y la Tabla 2 resume las principales entradas y salidas.
Modelo de Casos de Uso Elaborar Diccionario Diccionario de Conceptos Relacionar Conceptos Mapa de Conceptos Elaborar Mapa de Repositorios Mapa de Repositorios

Tabla 2. Entradas y salidas de la Definicin de Negocio

Productos Entrada Fase Tarea Entrada Elaborar Diccionario Relacionar Definicin de Negocio Elaborar Mapa de Repositorios Mapa de Conceptos Plantillas de Mapas de conceptos Anlisis de relevamiento Mapa de Repositorios Conceptos Documento de Casos de Uso Diccionario de conceptos Representacin Modelo de Casos de Uso Estructura de Concepto Tcnica de Transformacin a utilizar Anlisis del Caso de Uso Modelo de clases Productos de salida Salida Diccionario de conceptos Mapa de Conceptos Representacin Estructura de Concepto Plantillas de Mapas de conceptos Plantilla de Mapa de repositorios

La primera tarea del analista ser elaborar el diccionario de conceptos de los procesos de negocio. El concepto de diccionario es utilizado en metodologas estructuradas para la definicin de las estructuras de los flujos de datos existentes entre los procesos, y que no necesariamente representan los conceptos utilizados en el negocio. La propuesta de trabajo es utilizar los conceptos definidos por la herramienta de Diccionario de Datos y expandir su uso hacia los procesos de Negocio. El objetivo es documentar los conceptos relevados en la fase de Conceptualizacin. La estructura de un concepto podr ser definida de acuerdo con la Tabla 3.
Tabla 3. Estructura de un concepto
Elemento de la estructura Concepto Definicin Estructura de datos Relaciones Procesos Descripcin Trmino que se desea definir. Descripcin del significado del concepto. Definicin de la estructura de los datos existentes en el concepto definido Lista de relaciones con otros conceptos Lista de los procesos de negocio que hacen uso del concepto

En este diccionario de conceptos se podrn identificar las diferentes entidades que forman parte del proceso de negocio. Otras representaciones han sido propuestas para poder documentar la informacin relevada [10]. Como objetivo secundario de esta actividad se encuentra el descubrimiento de sinnimos de conceptos. Los procesos de negocio hacen uso de un mismo concepto pero cada uno de ellos puede considerar caractersticas y condiciones diferentes para dicho concepto. Por ejemplo, un cliente para un rea de preventa puede diferir del concepto de cliente para un rea de soporte, siendo que en el primer caso el cliente puede ser una persona que an no tenga servicios y, en el segundo caso sea cliente slo aquella persona que ya ha adquirido un servicio. Estas diferencias en condiciones y caractersticas de los conceptos deben ser disipadas en esta fase. Con los conceptos definidos, el analista deber realizar el modelo de dominio de negocio, mediante un modelo conceptual del mismo. Las tcnicas de modelado de clases y de Entidad/Relacin pueden ser utilizadas como base del modelo. El objetivo es abstraerse de la implementacin en software de dichos conceptos y focalizarse en su relacin a nivel negocio. El analista trabajar sobre la vinculacin que existe entre los diferentes conceptos definidos en el diccionario, con los

Fig. 3: Fase de Definicin de Negocio

41

casos de uso identificados y podr obtener as el modelo conceptual de dominio para los procesos de negocio. Una vez que completado el mapa, se comienzan a relevar los diferentes repositorios de informacin de la organizacin. Aqu se requiere de la participacin de diferentes personas (roles) de la organizacin. Podemos mencionar a: los analistas de software, los administradores de base de datos y los responsables de las metodologas y procesos de negocio. Para obtener los datos requeridos por los procesos de Explotacin de Informacin, en caso de existir modelos estructurados de anlisis de los sistemas de informacin existentes en la organizacin, la identificacin de donde se encuentran las implementaciones fsicas del concepto de demora puede ser base del descubrimiento. Otra opcin puede ser la identificacin de sistemas de informacin (tanto software como manuales) que den soporte de informacin a los procesos de negocio. Es importante obtener el volumen de informacin de dichos repositorios, ya que son necesarios para poder definir qu procesos de Explotacin de Informacin pueden ser aplicados en el proyecto. Con la informacin obtenida, se arma un mapa que relaciona los casos de uso del negocio, con los conceptos que el negocio define y en el repositorio en que son almacenados. Esta triple relacin puede ser utilizada como base por cualquiera de las tcnicas de procesos de Explotacin de Informacin. 3.3 Fase de Identificacin de procesos de Explotacin de Informacin La fase de Identificacin de Procesos de explotacin de Informacin tiene como objetivo definir qu procesos de explotacin de informacin resolvern los problemas identificados en los procesos de negocio. Existen diversos procesos que pueden ser utilizados [18-19], entre los que se encuentran: Descubrimiento de reglas de comportamiento (DRC) Descubrimiento de grupos (DDG) Ponderacin de interdependencia de atributos (PIA) Descubrimiento de reglas de pertenencia al Grupo (DRPG) Ponderacin de reglas de comportamiento o de Pertenencia a Grupos (PRC) Esta fase no requiere entradas previas, puede realizarse en paralelo junto con la fase de Conceptualizacin del dominio. Incluso, durante la actividad de relevamiento de procesos, se podr realizar la actividad de identificacin de problemas de negocio. La Figura 4 refleja las actividades y productos de la fase y la Tabla 4 identifica las entradas y salidas de las tareas.
Diccionario de Conceptos Proceso de Explotacin Seleccionar proceso de explotacin

Tabla 4. Entradas y salidas de la fase de Definicin

Productos Entrada Fase Tarea Entrada Identificar problemas de Identificacin de Procesos de Seleccionar Explotacin de proceso de Informacin explotacin de conceptos informacin a utilizar diccionario informacin Diccionario de Plantilla de de Problemas problemas del lenguaje explotacin negocio Lista de Formalizacin de proyecto Representacin Documento de Inicio de Proyecto Plantilla de Lxico Extendido Tcnica de Transformacin a utilizar Anlisis de documentacin Salida Lista de Problemas de negocio Proceso de Representacin Plantilla de problemas de negocio Productos de salida

Para poder definir qu tcnica utilizar, se comienza con el relevamiento de los problemas que el usuario detecta en su negocio y se utiliza la informacin generada en las fases previas como fuente de informacin para la aplicacin de las tcnicas mencionadas. Al igual que en la fase de Conceptualizacin, pueden utilizarse las tcnicas tradicionales de recopilacin de informacin, enfocando la problemtica en las necesidades de informacin de los diferentes usuarios de negocio. La lista de problemas debe ser priorizada y estar en lenguaje natural, expresado con el vocabulario de usuario, identificando los problemas ms importantes segn su criterio. Ejemplos de problemas que deben ser reflejados en esta lista: Contexto de negocio: Inmobiliaria Recibe una nueva casa para la venta y desea conocer qu clientes podran estar interesados en ella. Contexto de negocio: Banco Tiene usuarios categorizados en grupos y se desea saber cuando llega un nuevo cliente, a qu grupo se debe asignarlo. Una vez definida la lista de problemas, se procede al anlisis de los mismos. Este anlisis se realiza mediante la utilizacin del modelo de Lxico Extendido del Lenguaje (LEL) [20]. El modelo LEL se obtiene del dominio del negocio, aplicando un conjunto de reglas para su construccin. Se han realizado trabajos sobre el enfoque LEL en el anlisis de situaciones de negocio [21], y que puede ser utilizado como base del trabajo que se debe realizar en esta fase: descomponer el problema en los diferentes smbolos presentados en el modelo LEL. El modelo presenta 4 tipos generales de smbolos, smbolo sujeto, smbolo objeto, smbolo verbo y smbolo estado. Para poder definir qu tcnica puede ser utilizada, se propone una tabla de decisin que analice las estructuras LEL, los conceptos identificados en la fase de Conceptualizacin, los repositorios de informacin existentes y las acciones que se desean resolver y en funcin de esa informacin, ofrecer qu tcnica de explotacin sera la ms adecuada para el proyecto en cuestin. La Tabla 5 muestra qu condiciones se evalan y las reglas que fueron identificadas como base para este trabajo. Como observaciones, se entiende como descubrimiento de conceptos sujeto a la bsqueda de sujetos o conceptos que no hayan sido identificados como parte del dominio relevado.

Identificar Problemas de Negocio

Lista de Problemas

Fig. 4: Fase de Definicin de Negocio

42

Tabla 5. Seleccin de proceso de Explotacin

Condiciones Existen los conceptos identificados como objeto en algn repositorio de Informacin del negocio? Existen conceptos identificados como Objeto que no se encuentren en ningn repositorio? La accin representada por el verbo, Denota descubrimiento de conceptos Sujeto? Existen conceptos objetos asociables a Factores? Los factores requeridos, Se encuentran identificados? Los factores identificados, Pueden deducirse de la informacin existente en los repositorios? La accin representada por el verbo, Asocia Sujetos con Objetos? Se requiere analizar la incidencia de los factores para obtener un grupo de sujetos u objetos? Acciones Se recomienda aplicar
DRC DDG PIA DRP PRC

R01 SI NO SI SI SI SI SI NO

R02 SI NO NO SI SI SI NO SI

R03 SI NO NO SI NO NO NO SI

R04 NO SI NO NO NO NO SI SI

R05 NO SI SI SI NO NO SI SI

funcionamiento del negocio. Ese funcionamiento puede ser documentado en informes de relevamiento. La inmobiliaria se focaliza principalmente en el alquiler y venta de inmuebles. Si una persona se acerca a ofrecer su inmueble para la venta, el martillero realiza una tasacin del inmueble ofrecido. Se presenta dicha tasacin al cliente y si est de acuerdo con la misma, se establecen las condiciones en las que se realizar la venta. Cuando una persona presenta inters en comprar una casa, los vendedores completan una planilla con los datos de la persona y las caractersticas que debe cumplir el inmueble. Si existen inmuebles que cumplan con el criterio solicitado, se presentan los mismos a la persona. La inmobiliaria considera como clientes aquellas personas que tienen ofrecida una casa para vender y a las personas que ya iniciaron un proceso de compra de una casa ofrecida, y considera interesados a aquellas personas que estn consultando por los inmuebles ofertados o estn buscando inmuebles para comprar. Si los interesados acuerdan la compra de un inmueble, sern clientes de la inmobiliaria y se da comienzo al proceso de compra de inmuebles. La informacin de los clientes e inmuebles se almacena en un archivo Excel. El tercer paso implica el anlisis de la informacin relevada y su modelado en casos de uso. Con la informacin relevada podramos identificar los siguientes casos de uso de negocio: Vender Inmuebles, que refleja la accin de venta del inmueble por parte de una persona y gestionada por la inmobiliaria Comprar Inmuebles, que refleja la accin de compra por parte de una persona de un inmueble ofrecido por la inmobiliaria Ofrecer Inmuebles, que refleja la accin de mostrar los inmuebles que dispone para venta la inmobiliaria a los interesados. Este es un breve anlisis de los casos de uso identificados. Un trabajo ms exhaustivo detallara ms la informacin de cada caso de uso. Fase de Definicin de Negocio: El cuarto paso consiste en la elaboracin del diccionario de conceptos del negocio. Del relevamiento, podemos identificar los conceptos indicados en la Tabla 6.
Tabla 6. Conceptos identificados en la definicin
Cliente Vendedor Persona que ofrece un inmueble para la venta Estructura: Nombre y Apellido Documento Identidad Informacin de Contacto Relaciones: Inmueble Tasacin Procesos : Vender Inmueble Tasacin Valuacin del inmueble para su venta Estructura: Valor Tasacin (Numrico) Identificador de Inmueble Moneda Tasacin

Esta tabla tiene como objetivo poder decidir, mediante el anlisis de la informacin obtenida acerca del negocio en estudio, qu proceso de Explotacin de Informacin puede aplicarse en el proyecto. Es importante destacar que esta tabla de decisin incorporar nuevos conocimientos y nuevas reglas, con el fin de mejorar el criterio de seleccin de la tcnica. Con la incorporacin de ms proyectos y ms experiencia, se pueden refinar las reglas de las tablas y as lograr una mejor seleccin del proceso. Con la fase de Identificacin del Proceso de Explotacin de Informacin, se concluye la fase y el proceso. Las tareas posteriores dependern del proceso definido y de las actividades establecidas en el proyecto. 4. PRUEBA DE CONCEPTO 4.1 Descripcin del negocio Inmobiliaria del distrito federal Buenos Aires que trabaja en zonas residenciales de la ciudad. Dirigida por dos socios, dueos en partes iguales de la misma que publica las casas ofrecidas en su cartera en diferentes medios, principalmente en revistas locales de inmobiliarias. Las casas publicadas son de rango de clase media y media alta. Esta inmobiliaria no se dedica a la construccin de emprendimientos inmobiliarios aunque se asocia con otras inmobiliarias que s lo hacen y ofrecen dichos emprendimientos como productos para vender. Tiene una nica sucursal, donde trabajan todos sus empleados. Se cubren los roles de martillero, vendedores, administrativos, gestores de trmites y asesores de compra/venta. 4.2 Implementacin del proceso Fase de Conceptualizacin: El primer paso del proceso es identificar interesados del proyecto y armar la lista de interesados que sern relevados. De este paso, con el breve conocimiento que tenemos de la empresa, podemos definir 3 interesados: los dueos y el vendedor. El segundo paso es establecer una serie de entrevistas con los roles seleccionados y relevar el

43

Cliente Vendedor Persona que ofrece un inmueble para la venta Relaciones: Inmueble Cliente Procesos Vender Inmueble Ofrecer Inmueble

- Es un estado que tiene un cliente cuando una casa ofrecida cumple con sus expectativas Impacto - La casa ofrecida se muestra al interesado

El siguiente paso consiste en el armado de un modelo de relacin de los conceptos definidos. La Figura 5 muestra brevemente las relaciones existentes entre los conceptos identificados.

Con el anlisis LEL obtenido y la informacin de los repositorios y conceptos, determinamos qu proceso de Explotacin de Informacin se puede aplicar. Para ello, se utiliza como gua la Tabla 5 y se analiza la regla obtenida. El resultado del anlisis se ve en la Tabla 8.
Tabla 8. Resultado del anlisis LEL
Condiciones Regla Existen los conceptos identificados como objeto en algn SI repositorio de Informacin del negocio? Existen conceptos identificados como Objeto que no se NO encuentren en ningn repositorio? La accin representada por el verbo, Denota SI descubrimiento de conceptos Sujeto? Existen conceptos objeto asociables a Factores? SI

Fig. 5: Modelo de Conceptos identificados en el caso

El sexto paso del proceso implica identificar los repositorios donde la informacin asociada a los conceptos se encuentra almacenada. Del relevamiento obtenido, podemos identificar dos repositorios: la planilla de interesados y la planilla Excel de clientes e inmuebles. El sptimo paso es la identificacin de problemas de negocio. Esta identificacin se puede realizar junto con el segundo paso, durante el relevamiento del negocio. La lista debe identificar los problemas en el lenguaje del usuario. De un segundo relevamiento surge que uno de los problemas de la inmobiliaria es: cuando se recibe una nueva casa para la venta deseamos conocer qu clientes podran estar interesados en ella. La lista puede tener varios problemas. Cada problema debe ser priorizado y estar identificado unvocamente. Con los problemas identificados, se contina con el octavo paso, el anlisis LEL de los problemas. En este caso, el anlisis identifica (entre otros) los smbolos expresados en la Tabla 7.
Tabla 7. Smbolos asociados al problema de la inmobiliaria
Inmueble [Objeto] Nocin - Es el objeto que vende la inmobiliaria Impacto - Lo vende un cliente de la inmobiliaria Ofrecer una casa [Verbo] Nocin - Es la accin de presentarle una casa en venta a un cliente Impacto - La casa debe satisfacer los criterios de los interesados Cliente [Sujeto] Nocin - Persona que est interesada en comprar casa - Persona que vende la casa Impacto - Completa un formulario de criterios de compra - Establece lineamientos de la zona donde trabaja Interesado [Estado] Nocin

Los factores requeridos, Se encuentran identificados? Los factores identificados, Pueden deducirse de la informacin existente en los repositorios? La accin representada por el verbo, Asocia Sujetos con Objetos? Se requiere analizar la incidencia de los factores para obtener un grupo de sujetos u objetos? Acciones Aplicar:

SI SI SI NO DRC

5. CONCLUSIONES Este trabajo presenta una propuesta de proceso para la elicitacin de requerimientos en proyectos de Explotacin de Informacin y cmo utilizar tcnicas existentes de elicitacin de requerimientos, pero adaptndolas dichos proyectos. El proceso se descompone en 3 fases, donde se analiza el negocio en estudio (Fase de Conceptualizacin), se trata de armar un modelo del negocio y definirlo para poder comprender el alcance del mismo y la informacin que administra (Fase de Definicin de Negocio) y por ltimo, los problemas que los usuarios del negocio identifican y conociendo los conceptos y repositorios de informacin que administran, se presenta una herramienta para poder establecer qu tcnica de explotacin de informacin puede ser aplicada para un proyecto de explotacin de informacin (Fase de Identificacin de Procesos de Explotacin de Informacin). Como futuras lneas de trabajo se estn identificando diferentes casos para la contrastacin emprica del proceso propuesto con nfasis en la validacin de la tabla de decisin referida en la seccin 3.3. 6. REFERENCIAS
[1] Sommerville, I. & Sawyer, P. 1997. Requirements Engineering: A Good Practice Guide. Wiley & Sons. [2] Wiegers, K. 2003. Software Requirements. Microsoft Press. [3] Lauesen, S 2002. Software Requirements. Styles and Techniques. Pearson Education. [4] Pollo-Cattaneo, F. et al. 2010. Proceso de Educcin de Requisitos en Proyectos de Explotacin de Informacin. En Aguilar R. et al (Eds.), Ingeniera de Software e

44

[5]

[6]

[7] [8]

[9] [10]

[11]

[12] [13]

Ingeniera del Conocimiento: Tendencias de Investigacin e Innovacin Tecnolgica en Iberoamrica, 01-11. Alfaomega. Pollo-Cattaneo, F. et al. 2010. Ingeniera de Proyectos de Explotacin de Informacin. Proceedings XII Workshop de Investigadores en Ciencias de la Computacin, 172176. Pytel, P. et al. 2011. Ingeniera de Requisitos Basada en Tcnicas de Ingeniera del Conocimiento. Proceedings XIII WICC, 426-429. Chapman P. et al. 2000. CRISP-DM 1.0 Step-by-step data mining guide. The CRISP-DM consortium. Garca-Martnez, R. et al 2011. Information Mining Processes Based on Intelligent Systems. Proceedings of II International Congress on Computer Science and Informatics, 87-94. Pyle, D. 2003. Business Modeling and Business Intelligence. Morgan Kauffmann Publishers. SAS. 2011. SAS Enterprise Miner: SEMMA. Online: http://www.sas.com/offices/europe/uk/technologies/an alytics/datamining/miner/semma.html. [Jun. 2011]. Pollo-Cattaneo, F. et al. 2009. Metodologa para Especificacin de Requisitos en Proyectos de Explotacin de Informacin. Proceedings XI WICC, 333-335. Kimball, R. et al. 2011. The Data Warehouse Lifecycle Toolkit. Wiley & Sons. Vanrell, J.; Bertone, R. & Garca-Martnez, R. 2010. Modelo de Proceso de Operacin para Proyectos de Explotacin de Informacin. Proceedings XVI Congreso argentino de ciencias de la computacin, 674-682.

[14] William, R. 1996. A Guide to the Project Management Body of Knowledge. PMI Publishing. [15] Britos, P.; Dieste, O. & Garca-Martnez, R. 2008. Requirements Elicitation in Data Mining for Business Intelligence Projects. En Avison, D. et al (Eds.), Advances in Information Systems Research, Education and Practice, 139-150. [16] Jacobson, I.; Ericsson, M. & Jacobson, A. 1995. The Object Advantage. Business Process Reengineering with Object Technology, 98. Addison Wesley Publishing Company. [17] Jacobson, I.; Ericsson, M. & Jacobson, A. 1995. The Object Advantage. Business Process Reengineering with Object Technology, 101. Addison Wesley Publishing Company. [18] Garca-Martnez, R. et al. 2011. Towards an Information Mining Engineering. In Zapata, J. C. M. et al. (Eds.), Software Engineering, Methods, Modeling and Teaching, 83-99. Editorial Universidad de Medelln. [19] Pollo-Cattaneo, F. et al. 2010. Ingeniera de Procesos de Explotacin de Informacin. En Aguilar, R.; Daz, J. & Gmez, G. (Eds.), Ingeniera de Software e Ingeniera del Conocimiento: Tendencias de Investigacin e Innovacin Tecnolgica en Iberoamrica, 252-263. Alfaomega. [20] Leite, J. C. S. P. 1994. Notas de Aula. Material del curso de Ingeniera de Requisitos. [21] Fresno, M. et al. 1998. Derivacin de objetos utilizando LEL y Escenarios en un caso real. Online: http://wer.inf.puc-rio.br/wer98/artigos/89.html. [Nov. 2011].

45

A Process Model for Data Mining Projects Un Modelo de Procesos para Proyectos de Explotacin de Informacin
Escuela de Postgrado, Universidad Tecnolgica Nacional. Ciudad Autnoma de Buenos Aires, Argentina. javanrell@gmail.com. Facultad de Informtica. Universidad Nacional de La Plata. La Plata, Argentina. pbertone@lidi.info.unlp.edu.ar 3 Grupo de Investigacin en Sistemas de Informacin. Departamento de Desarrollo Productivo y Tecnolgico. Universidad Nacional de Lans. Remedios de Escalada, Argentina. rgarcia@unla.edu.ar.
1 2

Juan A. Vanrell1, Rodolfo Bertone2, Ramn Garca-Martnez3

INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo: Recibido: 23/04/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Explotacin de informacin, modelo de procesos. Categories and Subject Descriptors: D.2.1 [Requirements/Specifications]: Methodologies. General Terms Documentation Keywords Data mining projects, process model.

ABSTRACT Data mining projects have very different characteristics from traditional software development projects. Classics steps of analysis, design, development, integration and testing do not fit the natural steps of development process of such projects. In this context, we developed a process model for data mining projects for SMEs following the guidelines of the process model for the software industry (COMPETISOFT). RESUMEN Los proyectos de explotacin de informacin poseen caractersticas muy distintas a las de los proyectos de desarrollo de software tradicionales. Las clsicas etapas de anlisis, diseo, desarrollo, integracin y testeo no encajan con las etapas naturales de los procesos de desarrollo de este tipo de proyectos. En este contexto, se desarroll un modelo de procesos para proyectos de explotacin de informacin para PyMEs siguiendo los lineamientos del modelo de procesos para la industria de software (COMPETISOFT).

1. INTRODUCCIN Actualmente existen en el mercado distintos modelos que ayudan a llevar a cabo proyectos con un nivel de calidad esperado en forma repetitiva como pueden ser el de la norma ISO/IEC15504 e ISO/IEC12207, el modelo CMM y su versin actual CMMI [1], MoProSoft [2] o su versin iberoamericana COMPETISOFT [3]. Todos estos son modelos genricos por lo cual pueden ser utilizados para la ejecucin de cualquier tipo de proyecto [4-5]. Dentro de los distintos proyectos que son llevados a cabo por empresas dedicadas al rea de tecnologas de la informacin se encuentra un conjunto denominado proyectos de explotacin de informacin. Como todo conjunto posee caractersticas propias que lo hacen diferenciarse del resto. Se considera que estas caractersticas son lo suficientemente significativas como para justificar la construccin de un modelo de procesos que se ajuste a este tipo de proyectos [6]. Siguiendo los lineamientos de los creadores de MoProSoft y COMPETISOFT para la definicin de un modelo que pueda ser utilizado por pequeas y medianas empresas (Pymes) que sern: fcil de entender, fcil de aplicar y relativamente econmicos en su implementacin, se decidi crear un modelo de procesos de explotacin de informacin orientado a Pymes tomando como base el modelo COMPETISOFT y adecundolo a los procesos utilizados para los proyectos de explotacin de informacin.

En este contexto haremos a continuacin una introduccin a COMPETISOFT y CRISP-DM (seccin 2), para luego presentar los problemas encontrados (seccin 3), la solucin propuesta (seccin 4) y un caso de estudio (seccin 5) incluyendo las principales conclusiones sobre este trabajo (seccin 6). 2. COMPETISOFT Y CRISP-DM En esta seccin se introduce el modelo de procesos COMPETISOFT (seccin 2.1) y la metodologa de explotacin de informacin CRISP (seccin 2.2). 2.1 Competisoft COMPETISOFT es la proyeccin a nivel iberoamericano del modelo de procesos para el desarrollo de software MoProSoft creado por encargo de la Secretara de Economa Mexicana para servir de base a la norma Mexicana para la Industria de Desarrollo y Mantenimiento de Software. El modelo inicial fue modificado y adecuado a las necesidades de otros pases, se le incorpor el modelo de evaluacin EvalProSoft [7] y se definieron niveles de madurez. Su propsito es fomentar la estandarizacin de las operaciones de pequeas y medianas empresas o departamentos internos de desarrollo, a travs de la incorporacin de las mejores prcticas en gestin e ingeniera de software, esperando elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. El modelo busca ser fcil de entender, fcil de aprender, no

46

costoso en su adopcin y ser la base para alcanzar evaluaciones exitosas con otros modelos o normas como ISO/IEC 15504, ISO/IEC 12207 o CMM. Este modelo puede ser utilizado tanto por organizaciones que no cuenten con procesos establecidos, ajustndolo de acuerdo a sus necesidades, como por organizaciones que ya poseen procesos establecidos que pueden utilizar como punto de referencia para identificar los elementos faltantes. Adems de definir procesos COMPETISOFT define un patrn que debe ser utilizado para documentar aquellos procesos que una empresa requiere agregar a los existentes en el modelo o para documentar la adecuacin de los que ya se encuentra en el mismo. Dicho patrn se encuentra constituido por tres partes: Definicin general del proceso, Prcticas y Guas de ajuste. El modelo a desarrollar pretende seguir este patrn para la documentacin de los procesos de explotacin de informacin. La estructura del modelo se encuentra dividida en tres categoras: Alta Direccin (DIR), Gerencia (GER) y Operaciones (OPE) reflejando la estructura de una organizacin. Estas categoras contienen los procesos de gestin de negocio (DIR), gestin de procesos, gestin de proyectos y gestin de recursos (GER) y administracin de un proyecto especfico, desarrollo de software y mantenimiento de software (OPE). En palabras de los creadores de COMPETISOFT la categora de Alta Direccin es la categora de procesos que aborda las prcticas de Alta Direccin relacionadas con la gestin del negocio y proporciona los lineamientos a los procesos de la Categora de Gerencia y se retroalimenta con la informacin generada por ellos, la categora de gerencia es la categora de procesos que aborda las prcticas de gestin de procesos, proyectos y recursos en funcin de los lineamientos establecidos en la Categora de Alta Direccin, adems proporciona los elementos para el funcionamiento de los procesos de la Categora de Operacin, recibe y evala la informacin generada por stos y comunica los resultados a la Categora de Alta Direccin y la Categora de Operacin es la categora de procesos que aborda las prcticas de los proyectos de desarrollo y mantenimiento de software, adems esta categora realiza las actividades de acuerdo a los elementos proporcionados por la Categora de Gerencia y entrega a sta la informacin y productos generados. 2.2 CRISP-DM La metodologa CRISP-DM [8] se encuentra definida en base a un modelo jerrquico de procesos. El foco se pondr en los procesos del nivel superior que son lo suficientemente genricos como para cubrir todas las posibles aplicaciones de explotacin de informacin. Esta metodologa define un ciclo de vida de los proyectos de explotacin de informacin que define las principales fases de un proyecto de este tipo. Estas fases

son: Entendimiento de Negocios, Entendimiento de los Datos, Preparacin de los Datos, Modelado, Evaluacin y Despliegue. Claramente estas fases difieren de las fases definidas para un proyecto de desarrollo de software clsico (inicio, requerimientos, anlisis y diseo, construccin, integracin y pruebas y cierre). A continuacin se presenta el concepto de cada una de las fases identificadas por CRISP-DM. En la fase de Entendimiento del Negocio se deben entender los objetivos del proyecto y los requerimientos desde una perspectiva del negocio y luego convertir este conocimiento en una definicin de un problema de explotacin de informacin y disear un plan preliminar para lograr dichos objetivos. El Entendimiento de los Datos comienza con la recoleccin inicial de datos y procede con las acciones para familiarizarse con ellos, identificar problemas de calidad, identificar primeras pautas en los datos o detectar subconjuntos interesantes de las hiptesis de informacin oculta. La fase de Preparacin de los Datos cubre todas las actividades para construir el conjunto de datos final desde los datos iniciales, las tareas de esta fase pueden ser realizadas muchas veces y sin un orden preestablecido, incluye tanto la seleccin de tablas, registros y atributos como transformacin y limpieza de datos para herramientas de modelado. El Modelado incluye la seleccin de tcnicas de modelado y la calibracin de sus parmetros a los valores ptimos, suelen existir distintas tcnicas para un mismo problema de explotacin de informacin y cada una de ellas suele tener ciertos requisitos sobre los datos, muchas veces es necesario volver a la fase de preparacin de los datos. La Evaluacin requiere la construccin de uno o varios modelos que aparentan tener la mayor calidad desde una perspectiva de anlisis, requiere la evaluacin del modelo y revisin de los pasos ejecutados para la construccin del modelo para asegurarnos de lograr los objetivos de negocio, al final de esta fase se debera poder tomar una decisin respecto de la utilizacin de los resultados. Por ltimo, la fase de despliegue puede ser tan simple como generar un reporte o tan compleja como implementar un proceso de explotacin de informacin repetible a travs de toda la empresa. 3. PROBLEMA Al desarrollar diferentes proyectos de explotacin de la informacin con un alto grado de previsibilidad y calidad se utilizan distintos modelos de produccin y metodologas. Estas herramientas permiten controlar la calidad final de producto a desarrollar estableciendo controles sobre cada una de las etapas que interviene el en proceso productivo, entendiendo por proceso productivo no solo la produccin en si misma, sino

47

tambin las tareas relacionadas a la gestin de un proyecto y de la empresa que lo desarrolla. En el caso de proyectos clsicos existen, como se mencion al principio de esta Tesis, modelos bien probados como puede ser CMM o el modelo para PyMEs COMPETISOFT. Estos modelos han sido utilizados en suficientes proyectos de forma que pueden ser considerados modelos estables y altamente testeados (en el caso de COMPETISOFT se puede considerar al modelo MoProSoft como el ms testeado). Sin embargo, se considera que estos modelos no son adecuados para empresas que se dedican a llevar a cabo proyectos de explotacin de informacin. Por otro lado existen metodologas que acompaan el desarrollo de proyectos de explotacin de informacin entre las cuales destacamos a CRISP-DM, PTQ y SEMMA que si bien fueron probadas y tienen un buen nivel de madurez en cuanto al desarrollo del proyecto, dejan de lado aspectos a nivel gestin de proyectos y de empresa. Aceptando que los proyectos de desarrollo de software tradicional poseen caractersticas muy distintas a los proyectos de explotacin de informacin, sobre todo en la parte operativa de un proyecto [9], una lectura rpida a la documentacin del modelo de procesos de desarrollo de software, COMPETISOFT, muestra grandes diferencias en cuanto a los procesos naturales de los proyectos de explotacin de informacin. La diferencia ms significativa se presenta en los procesos de desarrollo y mantenimiento de software en los cuales COMPETISOFT define como proceso natural el ciclo de fases de un proyecto de software tradicional. Las fases de Inicio, Requisitos, Anlisis y Diseo, Construccin, Integracin, Pruebas y Cierre no resultan naturales en un proyecto de explotacin de informacin. En la misma lnea, al evaluar las principales metodologas existentes para los proyectos de explotacin de informacin mencionados anteriormente, se observa la falta de herramientas que permitan soportar de forma completa la fase de administracin de proyectos. Esta fase se encuentra bien definida y agrupada en el proceso de Administracin de Proyectos Especficos dentro de la metodologa COMPETISOFT. Sin embargo se encuentran algunas definiciones de tareas o actividades que pertenecen a este proceso como puede ser la construccin de un plan de desarrollo, definir el protocolo de entrega con el cliente, establecer el equipo de trabajo, definir el plan de manejo de riesgos, Teniendo en cuenta estos dos problemas esta Tesis se orienta a acercar los procesos de la categora de operacin definidos en COMPETISOFT con los procesos requeridos por los proyectos de explotacin ya sea adecuando las fases definidas en COMPETISOFT a las necesarias para los proyectos de explotacin de informacin, eliminando las fases que no son adecuadas o proponiendo nuevas fases en su reemplazo. En este trabajo se utiliza como metodologa de referencia a CRISP-DM dado que, al comparar las tres metodologas

mencionadas anteriormente [10], se pudo observar que esta ltima contena todos los elementos a nivel operacin de las otras. 4. SOLUCIN PROPUESTA Se propone como solucin a los problemas mencionados en la seccin anterior, mantener los procesos de la categora de Operacin definidos en COMPETISOFT, como Administracin de Proyectos y Desarrollo de Proyectos readecundolos a los proyectos de explotacin de informacin. Las categoras de Alta Direccin y Gerencia se mantienen invariables basndose en el modelo COMPETISOFT dado que se definen a un nivel empresarial y no a un nivel de produccin con lo cual pueden ser adecuadas para cualquier tipo de proyecto. Como se menciona anteriormente la metodologa CRISPDM no hace distincin entre procesos sino que posee un nico proceso en el cual se definen todas las tareas dividindolas en fases, ya sea las relacionadas con la administracin como las relacionadas con el desarrollo. Esta divisin es necesaria ya que ambos procesos deben ser ejecutados en forma concurrente, por un lado se debe desarrollar el proyecto propiamente dicho y al mismo tiempo se deben ejecutar tareas de administracin del proyecto para controlar su avance, realizar correcciones y recolectar datos para futuros proyectos. La reestructuracin de estos dos procesos en el desarrollo de proyectos de Explotacin de Informacin brindar mayor claridad a las tareas de administracin ya que, como se menciona anteriormente, las tareas de administracin que se encuentran mencionadas en las metodologas evaluadas se encuentran dentro de un mismo proceso de desarrollo. Esta divisin no se limita a separar las tareas existentes en las metodologas sino que se construye el nuevo proceso basndose en el proceso de administracin utilizado para el desarrollo de software clsico, especficamente el definido en el modelo COMPETISOFT, lo cual enriquece el proceso de administracin de proyectos. A este proceso se lo adecu para responder a las exigencias de los proyectos de Explotacin de Informacin. La incorporacin del proceso de administracin del proyecto, y su concepcin como un proceso distinguible del de desarrollo, constituye una aportacin a la gestin de los proyectos de Explotacin de Informacin, ya que ninguna de las metodologas evaluadas, incluyendo a CRISP-DM, hace una separacin clara entre las tareas que se deben llevar a cabo para la administracin del proyecto y las que se llevan a cabo para su desarrollo. Partiendo del proceso definido para COMPETISOFT, se defini uno nuevo que incorpora las tareas definidas en las fases de CRISP-DM que se consideraron fuertemente ligadas a los procesos de administracin, estas tareas

48

son las de Determinar los objetivos del Negocio que se encuentra relacionada con la elicitacin de requerimientos y Evaluacin de la Situacin, ambas ubicadas en el subproceso de Planificacin / Entendimiento del Negocio, y Planear la entrega, la cual fue ubicada dentro del subproceso de Cierre/Entrega. El resto de las tareas definidas en el proceso de administracin pertenecen a COMPETISOFT. Junto con esta reestructuracin de tareas se agregaron actividades para llevar a cabo cada una de las etapas definidas en el proceso de administracin, para aquellos casos en los que no exista ya un conjunto de actividades definidas, como puede observarse en las tareas. Se definieron al mismo tiempo tcnicas que pueden ser aplicadas como recomendacin para llevar a cabo las actividades que se mencionan en el proceso de administracin de proyectos. Para el caso del proceso de desarrollo del proyecto, no se tomo como base el proceso de desarrollo definido en COMPETISOFT dado que, como se indic en el captulo anterior, las fases de
SUBPROCESO TAREA Entendimiento del negocio Definir el proceso especfico basado en la descripcin del proyecto y el proceso de desarrollo y mantenimiento Definir el protocolo de entrega con el cliente Definir ciclos y actividades con base en la descripcin del proyecto y en el proceso especfico Determinar tiempo estimado para cada actividad Elaborar plan de adquisiciones y capacitacin Establecer el equipo de trabajo Establecer el calendario de actividades Calcular el costo estimado del proyecto

desarrollo de los proyectos de Explotacin de Informacin no coinciden naturalmente con las fases mediante las cuales se desarrollan los proyectos de software clsicos. Si bien se mantuvo la estructura utilizada por COMPETISOFT, tanto la divisin de los subprocesos como las tareas a realizar en cada uno de ellos, fueron definidas a partir de las fases de desarrollo planteadas por la metodologa CRISP-DM. Se agregaron actividades faltantes para obtener un proceso coherente y detallado y se incorporaron a este proceso recomendaciones de las tcnicas a utilizar para cada una de las tareas definidas en los subprocesos del proceso de desarrollo del proyecto. El resultado de esta solucin puede verse en las Tablas 1 y 2, en las que se omite, por falta de espacio, la descripcin de las actividades necesarias para realizar cada tarea y las tcnicas sugeridas.

Tabla 1. Proceso de Administracin de Proyectos

SALIDA Conocimiento del negocio Objetivos del negocio Criterios de xito

Proceso Especifico (forma parte del Plan de Desarrollo) Plan de Entrega Proceso Especifico (forma parte del Plan de Desarrollo) Calendario de actividades (forma parte del Plan de Desarrollo) incorpora el
tiempo estimado en el Plan de Proyecto Plan de Adquisiciones y Capacitacin Equipo de trabajo (forma parte del Plan de Desarrollo) Calendario de actividades (forma parte del Plan de Desarrollo) Costo estimado (forma parte del Plan de Proyecto) Inventario de recursos Requerimientos, suposiciones y restricciones Riesgos y contingencias (forma parte del Plan de Proyecto nombrado como Plan de Manejo de Riesgos) Terminologa Costos y beneficios Plan de Proyecto, incluye ciclos y actividades, tiempo estimado, plan de adquisiciones y capacitacin, equipo de trabajo, costo estimado, calendario, plan de manejo de riesgos y protocolo de entrega Plan de Desarrollo (incluye descripcin del producto y entregables, proceso especfico, equipo de trabajo y calendario) Lista inicial de tcnicas y herramientas

Planificacin / Entendimiento del negocio

Evaluacin de la situacin

Producir un Plan de Proyecto

Producir un Plan de Desarrollo Formalizar el inicio de un nuevo ciclo del proyecto Acordar las tareas con el equipo de trabajo Acordar la distribucin de informacin Revisar con el responsable la descripcin del producto, el equipo de trabajo y el calendario Revisar cumplimiento del plan de adquisiciones y capacitacin Administrar subcontratos Recolectar reportes de actividades y mediciones y sugerencias de mejora y productos de trabajo Registrar costo real del proyecto Revisar el registro de rastreo basado en los productos de trabajo recolectados Revisar los productos terminados durante el proyecto Recibir y analizar las solicitudes de cambio del cliente Realizar reuniones con el equipo de trabajo y cliente para reportar avances y tomar acuerdos Evaluar el cumplimiento del plan de proyecto y plan de desarrollo Analizar y controlar los riesgos Generar el reporte de seguimiento del proyecto Formalizar la terminacin del proyecto o ciclo Llevar a cabo el cierre del contrato con subcontratistas Generar el reporte de mediciones y sugerencias de mejora Planear la entrega

Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de
Mediciones y Sugerencias de Mejora

Realizacin

Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de Seguimiento / Plan de monitoreo y mantenimiento
Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de Seguimiento / Plan de monitoreo y mantenimiento Reporte de Seguimiento / Plan de monitoreo y mantenimiento Documento de aceptacin

Evaluacin y Control

Cierre / Entrega

Reporte de mediciones y sugerencia de mejoras - Lecciones Aprendidas Plan de entrega (forma parte del Plan de Proyecto nombrado como protocolo
de entrega)

49

Tabla 2. Proceso de Desarrollo del Proyectos

SUBPROCESO Entendimiento del negocio TAREA Determinar las metas del Data Mining Reunir los datos iniciales Describir los datos Explorar los datos Verificar la calidad de los datos Tareas preparatorias Seleccionar los datos Limpiar los datos Construir los datos Integrar los datos Formatear los datos Seleccionar la tcnica de modelado Generar el diseo de test Modelado Construir el modelo Evaluar el modelo Evaluar resultados Evaluacin Revisar el proceso Determinar prximos pasos Entrega Producir un reporte final SALIDA Metas del Data Mining Criterios de xito del Data Mining Reporte de datos iniciales Reporte de descripcin de datos Reporte de exploracin de datos Reporte de calidad de los datos Datasets Descripcin de los Datasets Justificacin de inclusin / exclusin Reporte de limpieza de datos Atributos derivados Registros generados Datos combinados (combinacin de tablas y agregaciones) Datos formateados Tcnica de modelado Suposiciones de modelado Diseo de test Establecimiento de parmetros Modelos Descripcin del modelo Evaluacin del modelo Revisin de los parmetros establecidos Evaluacin de los resultados de Data Mining respecto a los criterios de xito

Entendimiento de los datos

Preparacin de los datos

Modelos aprobados Revisin del proceso Lista de posibles decisiones Decisiones Reporte final Presentacin final

5. CASO DE ESTUDIO En su Tesis de Maestra, Flores [11] desarrolla un proyecto de explotacin de informacin para detectar patrones en la produccin de daos y/o averas en la cadena de distribucin de la industria automotriz. Para llevar a cabo su trabajo el autor opt por el uso de la metodologa de desarrollo a CRISP-DM basndose en la independencia de esta metodologa con respecto a las herramientas tecnolgicas a utilizar en la explotacin de datos. Por ser sta de libre acceso, orientada al negocio y finalmente debido a ser la ms completa de las metodologas evaluadas ya que incluye, adems de los procesos de desarrollo, una fase preliminar dedicada al entendimiento del negocio que no es contemplada por el resto de las metodologas evaluadas. Se utiliz el trabajo de Flores para realizar una comparacin entre el uso de CRISP-DM y el uso del Modelo de Procesos propuesto como solucin de esta Tesis, destacando similitudes, diferencias y las ventajas que provee el nuevo modelo. Se dividi esta comparacin basndose en tres etapas en las que puede encontrarse un proyecto, ya que las actividades correspondientes a cada una de ellas pueden ser bien diferenciadas: Inicio, Ejecucin y Fin. Esta comparacin puede visualizarse en la Tabla 3, en la cual se muestran los procesos del nuevo modelo junto con las actividades realizadas mediante el uso de CRISPDM en la Tesis de Flores y las actividades que deberan ser realizadas en caso de utilizar el nuevo modelo. 6. CONCLUSIONES Durante la investigacin documental se encontraron diferencias importantes entre las PyMEs y las grandes empresas que justifican la creacin de un modelo de

procesos diferenciado y se reconocieron las diferencias entre el modelo COMPETISOFT y las metodologas para proyectos de explotacin de informacin. Se detectaron carencias en lo referente a la gestin de proyectos y de la empresa en las metodologas utilizadas para proyectos de explotacin de informacin, as como algunas herramientas bsicas de gestin pero integradas en un nico proceso de desarrollo que fueron consideradas insuficientes. Al mismo tiempo se consider como no adecuado el proceso de desarrollo de software clsico para llevar a cavo proyectos de explotacin de informacin. Como solucin a estos problemas se propuso el uso de COMPETISOFT como punto de partida para la construccin de un nuevo modelo de procesos que supla estas carencias utilizando CRISP-DM para readecuar los procesos reemplazando completamente el proceso de desarrollo definido en COMPETISOFT por el definido en CRISP-DM, incorporando actividades para lograr realizar cada una de las tareas del proceso y proponiendo herramientas para llevarlas a cabo. En lo referente al proceso de administracin se mantuvo el proceso definido por COMPETISOFT y se agregaron las tareas existentes en CRISP-DM con lo cual se logr independizar cada uno de los procesos. Finalmente se incorporaron al proceso de administracin las actividades necesarias para la realizacin de cada tarea y se propusieron herramientas para llevarlas a cabo. En la evaluacin de un caso de estudio se reconoci la falta de informacin histrica al ejecutar proyectos con CRISP-DM lo cual es solucionado en el modelo propuesto a travs del proceso de Administracin de Proyectos.

50

Tabla 3. Resumen de la Comparacin

CATEGORA Alta Direccin Gerencia PROCESO Todos Todos SUB-PROCESO Todos Todos CRISP-DM No se contempla No se contempla Descripcin de los objetivos de negocio. Descripcin del estado actual. Plantea-miento de objetivos generales y criterios de xito. Requerimientos, presunciones y restricciones. Plan de desarrollo. Evaluacin de riesgos. Planificacin de entregas. Plan de entrega. MODELO DE PROCESOS PARA PROYECTOS DE EXPLOTACIN DE INFORMACIN Introduce los procesos definidos por Competisoft Introduce los procesos definidos por Competisoft Tareas propuestas por CRISP-DM + Definicin de ciclos de desarrollo. Evaluacin de tiempos (uso de PERT). Desarrollo del calendario de actividades. Plan de adquisicin y capacitacin de personal (uso de Diagramas de Gantt). Estimacin de costos (DM-COMO o Tcnicas empricas). Identificacin de beneficios. Planificacin de planes de riesgos y contingencias. Planificacin de entregas. Plan de Proyecto. Formalizacin del inicio de cada ciclo Acordar tareas con el equipo de trabajo. Acordar la distribucin de informacin. Revisar con el responsable la descripcin del producto, el equipo de trabajo y el calendario. Revisar cumplimiento del plan de adquisiciones y capacitacin. Administrar subcontratos. Recolectar reportes de actividades y mediciones y sugerencias de mejora y productos de trabajo. Registrar costo real del proyecto. Revisar el registro de rastreo basado en los productos de trabajo recolectados. Revisar los productos terminados durante el proyecto. Recibir y analizar las solicitudes de cambio del cliente. Realizar reuniones con el equipo de trabajo y cliente para reportar avances y tomar acuerdos. Evaluar el cumplimiento del plan de proyecto y plan de desarrollo. Analizar y controlar los riesgos. Generar el reporte de seguimiento del proyecto. Modelo de Procesos para Proyectos de Explotacin de Informacin Tareas propuestas por CRISP-DM + Formalizar la terminacin del proyecto o ciclo. Llevar a cabo el cierre del contrato con subcontratistas Tareas propuestas por CRISP-DM + Ejecucin de tareas de administracin en un proceso aparte. Se sigue una gua de actividades para cumplir con las tareas. Tcnicas propuestas Tareas propuestas por CRISP-DM + Tcnicas propuestas Tareas propuestas por CRISP-DM + Se sigue una gua de actividades para cumplir con las tareas. Tcnicas propuestas Tareas propuestas por CRISP-DM + Tcnicas propuestas Tareas propuestas por CRISP-DM + Se sigue una gua de actividades para cumplir con las tareas. Tcnicas propuestas Tareas propuestas por CRISP-DM + Las tareas de administracin se ejecutan en un proceso aparte. Se sigue una gua de actividades para cumplir con las tareas. Tcnicas propuestas

Planificacin/ Entendimiento del negocio

Operacin

Administracin del Proyecto Realizacin No se contempla

Evaluacin y control Proceso Administracin de Proyectos (cont.) Subproceso Cierre / Entrega Entendimiento del negocio Entendimiento de los datos Categora Desarrollo del Proyecto / Fases Incluidas en CRISP-DM Preparacin de los datos Modelado Evaluacin

No se contempla CRISP-DM Planear la entrega. Generar el reporte de mediciones y sugerencias de mejora. Uso del subproceso definido en CRISP-DM (incluye tareas propias de la administracin mencionadas en el proceso correspondiente) Uso del subproceso definido en CRISP-DM Uso del subproceso definido en CRISP-DM Uso del subproceso definido en CRISP-DM Uso del subproceso definido en CRISP-DM Uso del subproceso definido en CRISP-DM (incluye tareas propias de la adminis-tracin mencionadas en el proceso correspondiente)

Entrega

Con el uso del modelo propuesto podemos asegurar una mejora en el control de avance y performance de los proyectos en ejecucin permitiendo que el xito de un proyecto se base en el ajuste constante del proceso de desarrollo basado en experiencias pasadas. Como futura lnea de investigacin y desarrollo se prev trabajar en un anlisis de los resultados de aplicacin del modelo de procesos propuesto con el objetivo de evaluar ventajas y desventajas del mismo al momento de considerar su puesta en produccin. 7. AGRADECIMIENTOS Las investigaciones que se reportan en este artculo han sido financiadas parcialmente por el Proyecto de Investigacin 33A105 del Departamento de Desarrollo Productivo y Tecnolgico de la Universidad Nacional de Lans. 8. REFERENCIAS
[1] SEI 2006. CMMI for Development, Version 1.2. Carnegie Mellon University, Software Engineering Institute.

[2] Oktaba, H. et al. 2005. Modelo de Procesos para la Industria de Software. Secretara de Economa de Mxico. [3] Oktaba, H. et al. 2008. Competisoft, Mejora de Procesos Software para Pequeas y Medianas Empresas y Proyectos. Ra-Ma. [4] Vanrell, J. A. et al. 2010. Un Modelo de Procesos de Explotacin de Informacin. Proceedings XII Workshop de Investigadores en Ciencias de la Computacin, 167171. [5] Garca-Martnez, R. et al 2011. Towards and Information Mining Engineering. In Zapata, J. C. M. et al. (Eds.), Software Engineering, Methods, Modeling and Teaching, 83-99. Editorial Universidad de Medelln. [6] Vanrell, J. A. 2009. Elementos para un Modelo de Procesos de Explotacin de Informacin para PyMES. Trabajo de Especialidad en Ingeniera en Sistemas de Informacin. Escuela de Posgrado. Facultad Regional Buenos Aires. Universidad Tecnolgica Nacional. [7] Oktaba, H. et al. 2004. Mtodo de Evaluacin de Procesos para la Industria de Software. Secretara de Economa de Mxico. [8] Chapman P. et al. 2000. CRISP-DM 1.0 Step-by-step data mining guide. The CRISP-DM consortium. [9] Vanrell, J. A., et al. 2010. Modelo de Proceso de Operacin para Proyectos de Explotacin de Informacin. Anales del XVI Congreso Argentino de Ciencias de la Computacin, 674-682.

51

[10] Britos, P. et al. 2008. Requeriments Elicitation in Data Mining for Business Inteligence Projects. In Avison, D. et al (Eds.), Advances in Information Systems Research, Education and Practice, 139-150. Springer.

[11] Flores, D. 2009. Deteccin de Patrones de Daos y Averas en la Industria Automotriz. Tesis de Maestra en Ingeniera en Sistemas de Informacin. Universidad Tecnolgica Nacional. Facultad Regional Buenos Aires.

52

Anti-patterns catalog to use when specifying functional requirements with use cases Catlogo de anti-patrones al especificar requisitos funcionales usando casos de uso
Juan B. Quintero1, Diana M. Hernndez2, Pamela Rucinque3
1 2

Arquitecto en ABC-Flex Ltda. Docente en Universidad de Antioquia y Universidad EAFIT. Medelln, Colombia. jbq@abcflex.net. Analista de Requisitos en ABC-Flex Ltda. Medelln, Colombia. dianahdez@abcflex.net. 3 Analista de Desarrollo en PSL. Medelln, Colombia. prucinque@psl.com.co. INFORMACIN DEL ARTCULO Tipo de artculo: Reflexin Historia del artculo: Recibido: 27/04/2012 Correcciones: 20/05/2012 Aceptado: 29/05/2012 ABSTRACT Problems during requirements specification diminish the chances of project success or the ability for the development process to run smoothly. This is why studying antipatterns in use cases is important as they raise more problems than they solve. This paper introduces an anti-pattern catalog with the single purpose of avoiding the bad practices they suggest for the specification of functional requirements using use cases. RESUMEN Los problemas en la especificacin de requisitos son un factor que afecta considerablemente las posibilidades de alcanzar el xito o de que el proceso transcurra con fluidez en el desarrollo de un proyecto de software, este es el motivo por el que es importante el estudio de los antipatrones en los casos de uso, como soluciones negativas que presentan ms problemas que los que solucionan. Este artculo presenta un catlogo de antipatrones para evitar las malas prcticas que estos siguieren en la especificacin de requisitos funcionales usando casos de uso.

Palabras clave Anti-patrones, casos de uso

patrones,

requisitos,

Categories and Subject Descriptors: D.2.1 [Software Engineering]: Elicitation methods, Methodologies. General Terms Requirements Engineering. Keywords Anti-patterns, patterns, requirements, use cases.

1. INTRODUCCIN A pesar del surgimiento de nuevas tcnicas en desarrollo de software y estrategias de gestin de proyectos, los factores por los que falla un proyecto de desarrollo, todava se encuentran muy relacionados con la gestin de requisitos. El prestigioso reporte caos, pone en evidencia esta situacin, que se ha presentado durante las ltimas dcadas, aunque cabe anotar que el porcentaje de proyectos exitosos ha aumentado [1]. Este planteamiento implica que para aumentar las posibilidades de xito en un proyecto de desarrollo de software, es necesario poner especial atencin en el anlisis de los requisitos. Los casos de uso constituyen unas de las tcnicas ms usadas para la especificacin de requisitos, es por esto que resulta de gran importancia conocer las buenas y malas prcticas al respecto, para mejorar los posibles resultados. En este sentido las buenas prcticas estn dadas por los patrones para definir casos de uso efectivos, mientras que las malas prcticas se plantean en los antipatrones para la especificacin de requisitos funcionales usando casos de uso. Para conocer bien los antipatrones en casos de uso, es necesario el buen conocimiento de los patrones en casos de uso, por tanto este artculo presenta un resumen de un reconocido catlogo de patrones para casos de uso efectivos detallado en el libro [2].

Por otro lado, el catlogo de antipatrones que se presenta en este artculo, proviene de un cuidadoso anlisis de los autores, acerca de los proyectos en los que han participado durante los ltimos aos, en los cuales los casos de uso han sido la tcnica de especificacin de casos de uso imperante. La labor docente de algunos de los autores, ha motivado la revisin de las situaciones que atentan contra el buen desempeo de un proyecto de software, a partir de las fallas en la especificacin de los casos de uso; la recopilacin de la informacin derivada de esta situacin fundamenta el desarrollo del catlogo de antipatrones para la especificacin de requisitos funcionales con casos de uso, planteado en este artculo. Para la presentacin del catlogo de antipatrones, este artculo se estructura de la siguiente forma: en el captulo 2 se revisa la disciplina del anlisis de requisitos y su relacin con los casos de uso, el captulo 3 presenta informacin de los patrones y los antipatrones, el captulo 4 resume el catlogo de patrones para casos de uso efectivos, el captulo 5 plantea el catlogo de antipatrones para especificar requisitos funcionales usando casos de uso, y el captulo 6 expone unas conclusiones al respecto.. 2. CASOS DE USO Y ANLISIS DE REQUISITOS El anlisis de requisitos es una disciplina o flujo de trabajo, posterior al modelado de negocio y previa al

53

anlisis y diseo, segn el proceso unificado de desarrollo tambin llamado RUP (por la sigla inglesa de Rational Unified Process) [3]. El principal artefacto a construir en este flujo es el documento de especificacin de requisitos, en el cual los casos de uso de requisitos juegan un papel fundamental, al punto que RUP plantea que es un proceso dirigido por los casos de uso. Otra de las caractersticas de RUP es que se define como un proceso centrado en la arquitectura; el principal artefacto en este frente es el documento de arquitectura; en este tambin aparecen los principales casos de uso primarios como parte de los conductores o drivers de la arquitectura. Esta importancia que se le da a los casos de uso dentro del proceso, es un factor que motiva un cuidadoso anlisis de las buenas y malas prcticas en este sentido. Un caso de uso se define como una coleccin de escenarios de xito y fracaso relacionados, que describe a los actores que usan un sistema para conseguir un objetivo, mientras que un escenario se define como una secuencia especfica de acciones e interaccin entre el usuario y el sistema bajo discusin [4]. Los elementos que se utilizan en la construccin de modelos de casos de uso, definen las categoras de los antipatrones en el catlogo planteado. Cabe aclarar que RUP tambin propone casos de uso de negocio los cuales se construyen en la disciplina de modelado de negocio, pero el catlogo de patrones planteado aqu se centra en los de requisitos. 3. LOS PATRONES Y LOS ANTI-PATRONES Un patrn presenta un esquema genrico de solucin probada, a un problema recurrente que surge en contextos especficos. El esquema de la solucin describe un conjunto de componentes, sus responsabilidades, las relaciones entre estos, y la forma en que dichos componentes colaboran entre s [5]. Existen diversos catlogos de patrones que tienen como propsito definir buenas prcticas en los diferentes frentes del desarrollo de software; el ms famoso es el catlogo GoF que define un conjunto de patrones para tratar problemas de diseo [6]. En contraposicin los antipatrones son soluciones negativas que presentan ms problemas que los que resuelven; extienden y complementan los patrones de forma natural. El estudio de los antipatrones permite conocer los errores ms comunes relacionados con la industria del software para intentar evitarlos o recuperarse de ellos [7]. Al ilustrar situaciones negativas, los antipatrones se documentan con cierto sarcasmo, lo que los hace graciosos y fciles de recordar, los nombres pueden aludir con algn grado de humor o cinismo al problema que presentan. Al igual que los patrones, los antipatrones se documentan mediante una plantilla que puede considerar diferentes elementos. Sin embargo, para el

caso especfico de los antipatrones para especificar requisitos con caso de uso, se debe tener en cuenta que corresponden a la disciplina de anlisis de requisitos y adicionalmente considerar que un buen anti-patrn explica por qu la solucin original parece atractiva, por qu se vuelve negativa y cmo recuperarse de los problemas que sta genera [8]. Con base en estos aspectos, se definen los siguientes tems para la plantilla de documentacin de los antipatrones:

Nombre: que ilustre con un toque de humor la situacin problemtica que se presenta. Nombre alterno: sinnimo para el nombre que motive su recordacin. Causas: situacin que motiva la aplicacin de la solucin negativa. Descripcin: explicacin del problema que se presenta. Factores que motivan su uso: situacin que hace que la solucin negativa parezca atractiva. Ejemplo y/o posible solucin: ejemplo para aclarar el problema de la solucin negativa y de su solucin, o en caso de que la situacin problemtica sea evidente, solo se plantea un posible esquema de solucin.

4. CATLOGO DE PATRONES EN LA ESPECIFICACIN DE CASOS DE USO Para definir un catlogo de antipatrones que presenta malas prcticas alrededor de los casos de uso, es fundamental conocer detalladamente las buenas prcticas y los catlogos de patrones acerca de casos de uso. Las buenas prcticas para escribir casos de uso efectivos, se compendiaron en el libro Writing effective use cases [9]; luego se formalizaron en el catlogo presentado en Patterns for Effective Use Cases [2]. La tabla 1 ilustra las categoras y patrones presentados en este catlogo:
Tabla 1. Catlogo de Patrones para Casos de Uso [2]
Categora Team Nombre del Patrn SmallWritingTeam ParticipatingAudience BalancedTeam BreadthBeforeDepth SpiralDevelopment MultipleForms TwoTierReview QuittingTime WritersLicense SharedClearVision VisibleBoundary ClearCastOfCharacters UserValuedTransactions EverUnfoldingStory CompleteSingleGoal VerbPhraseName ScenarioPlusFragments ExhaustiveAlternatives Adornments PreciseAndReadable DetectableConditions LeveledSteps ActorIntentAccomplished ForwardProgress TechnologyNeutral

Process

Use Case Set

Use Case

Scenarios and Steps

54

Use Case Relationships Editing Existing Use Cases

CommonSubBehavior InterruptsAsExtensions PromoteAlternative RedistributeTheWealth MergeDroplets CleanHouse

Para facilitar la comprensin de los patrones para casos de uso efectivos, presentados en el catlogo, a continuacin se hace un breve resumen de cada categora con el conjunto de patrones que le corresponden. 4.1 El Equipo El tamao del equipo, la retroalimentacin que reciben e incluso el background y personalidad de sus miembros son aspectos fundamentales en la conformacin de equipos de elicitacin de casos de uso ideales. Un equipo ideal sera aquel que no exceda el tamao de 3 miembros (SmallWritingTeam), que mantengan constante contacto con los posibles usuarios de los casos de uso en desarrollo (ParticipatingAudience) y sus miembros tengan diferentes especialidades y formas de pensar para as resolver problemas desde el mayor nmero de puntos de vista posible (BalancedTeam). 4.2 El Proceso Un buen proceso de requerimientos prioriza el valor de cada caso de uso sobre los detalles y tecnicismos. Obtener una visin general de la aplicacin resulta ms beneficioso que dedicarle tiempo a los detalles en una etapa temprana del proceso (BreadthBeforeDepth); una vez se conoce la aplicacin a alto nivel, se pueden desarrollar los casos de uso iterativamente (SpiralDevelopment) y detallarlos hasta que se considere necesario sin caer en el perfeccionismo (QuittingTime). Cada equipo debe ser libre de escoger el formato con el que se sientan mejor escribiendo, es ms productivo (MultipleForms); as como se debe entender que cada escritor tiene su estilo (WritersLicense), el formalismo no debe ser un impedimento; sin embargo estilos y formalismos muy dispares pueden causar dificultades en la comprensin. Finalmente, las revisiones deben ser en dos etapas: Detalladas, revisando forma y fondo, por un grupo interno y pequeo y luego la funcionalidad del caso de uso por parte de los dems involucrados (TwoTierReview). 4.3 El conjunto de Casos de Uso Tener un buen conjunto de casos de uso, organizados tal que sus nombres y orden puedan contar una historia (EverUnfoldingStory), garantiza una visin clara del proyecto por parte de todos los involucrados. Para empezar, la visin del proyecto debe apoyar la misin de la organizacin (SharedClearVision), y se debe establecer claramente cules son sus lmites (VisibleBoundary), una aplicacin no lo puede resolver todo, debe ser enfocada en resolver lo que realmente es de alto valor para los usuarios (UserValuedTransactions) y tener claro quines son los actores reales del sistema (ClearCastOfCharacters).

4.4 Los Casos de Uso Un caso de uso es una historia y debe ser escrito como tal, recordando que su audiencia es diversa (PreciseAndReadable). Su nombre debe generar recordacin, y ser en voz activa, un verbo en infinitivo seguido de un sustantivo y de ser necesario un corto complemento (VerbPhraseName); adems, el objetivo del caso de uso tiene que ser nico y claro (CompleteSingleGoal). Sus flujos alternos y excepciones deben ser, en su totalidad, incluidos (ExhaustiveAlternatives); pero no pueden interferir en la lectura del flujo principal (ScenarioPlusFragments). Tambin se deben crear campos en las plantillas que permitan incluir datos significativos que no distraigan de la descripcin del escenario (Adornments). 4.5 Escenarios y Pasos El caso de uso, al ser una historia, debe generar inters en el lector; que con cada paso escrito en forma simple, logre avanzar (ForwardProgress); describiendo claramente quien ejecuta la accin y cul es su intencin (ActorIntentAccomplished). Combinar condiciones que concluyan en la misma accin (DetectableConditions) y mantener el mismo nivel de abstraccin en la descripcin de cada paso, contribuye a la fluidez y simpleza del caso de uso (LeveledSteps). Es imperativo que el caso de uso se mantenga al margen de la tecnologa que se vaya a usar (TechnologyNeutral). 4.6 Las Relaciones de los Casos de Uso Los casos de uso pueden relacionarse entre s, dichas relaciones deben ser manejadas con cuidado. Cuando cierta funcionalidad es compartida por varios casos de uso, sta se extrae en otro y se incluye (include) desde el caso de uso padre o base (CommonSubBehavior). Si, por otra parte, hay una condicin que se repite en varios pasos y conduce a un flujo alterno (InterruptsAsExtensions) o hay un flujo alterno tan importante que parece relegar al flujo principal (PromoteAlternative), ste debe extraerse tambin en un caso de uso aparte, pero en este escenario el caso de uso nuevo extiende al padre o base (extend). 4.7 Editando Casos de Uso existentes Cuando los casos de uso no son legibles, ni cumplen con las buenas prcticas, pueden resultar en errores de implementacin. Es posible que un caso de uso largo en pasos, generalmente ms de nueve, tenga ms de un objetivo y sea candidato a dividirse (RedistributeTheWealth). Opuesto a esto, casos de uso pequeos que se relacionen con una misma meta y que por s solos no tengan objetivo de valor para el negocio deben ser agrupados (MergeDroplets). Por ltimo, aquellos casos de uso que no aaden valor al negocio o ya no sern tenidos en consideracin, deben ser eliminados para evitar distracciones de quien revisa el conjunto de casos de uso (CleanHouse). 5. CATLOGO DE ANTIPATRONES EN LA ESPECIFICACIN DE CASOS DE USO Teniendo en cuenta que ya existe un catlogo de patrones para especificar casos de uso efectivos; este

55

artculo no pretende ilustrar los antipatrones como la no aplicacin de estos patrones; en contraposicin pretende estudiar las situaciones que recurrentemente atentan contra una buena especificacin de casos de uso, dentro de los modelos de requisitos que se construyen en el desarrollo de un proyecto de software. Este es el motivo para que el nombre de los antipatrones planteados, no se derive de la no aplicacin de un patrn. Para la definicin de un catlogo de anti-patrones, es necesario revisar tanto las buenas prcticas como las malas prcticas que han sido estudiadas previamente por otros autores. En este frente nos encontramos con diversos trabajos: En [11] se hace un detallado anlisis de las 10 principales trampas en las que caen los analistas de requisitos que usan casos de uso cuando enfrentan proyectos reales. En [15] se muestran un conjunto de buenas y malas prcticas en la especificacin de requisitos usando casos de uso. En [16] se hace un anlisis de un asunto puntual pero muy recurrente en el anlisis de requisitos: Por qu los casos de uso nos son funciones?. El estudio de los referentes anteriores, y la experiencia derivada de la participacin en proyectos de software por parte de los autores, sirven de fundamentacin para el planteamiento de los anti-patrones propuestos en este catlogo, cuyos nombres se ilustran en la Tabla 1, clasificados en cuatro categoras, de acuerdo con el frente en particular donde se suelen presentar:
Tabla 1. Catlogo de Antipatrones en Casos de Uso [2]
Categora 1: en los conjunto de casos de uso PuntoDeEntrada (EntryPoint) ModeladoDesordenado (MessyModeling) Categora 2: en los casos de uso NombreConfuso (ConfusingName) AlcanceMezclado (MixedUpScope) GranularidadFueraDeLugar (MisplacedGranularity) CasoDeUsoImperativo (ImperativeUseCase) Categora 3: en los escenarios y pasos TiposDeFlujoIndeterminados (IndeterminateFlowTypes) EstiloDeEscrituraIndefinido (UndefinedWritingStyle) DesempoderamientoFuncional (FunctionalDisempowerment) Categora 4: en las relaciones RelacionesEnmaraadas (TangledRelationships) RelacionesRedundantes (RedundantRelationships) RelacionesIncorrectas (WrongRelationships)

denominacin que le dan a la ilustracin de este problema en [2]. Factores que motivan su uso: La necesidad de modelar el flujo de la interface de usuario y la navegacin, los cuales quedan muy claros usando esta estrategia; sin considerar las verdaderas implicaciones de las relaciones de dependencia entre los casos de uso. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, el caso de uso director pasa a ser parte del ttulo del lmite del sistema o paquete y el actor se relaciona directamente con los dems casos de uso, esto evita el modelado de la navegacin en la interface de usuario o la secuencialidad de los casos de uso, como lo recomienda [10]. La Figura 1 ilustra un diagrama en el que se presenta este anti-patrn y la forma en que se resuelve.

Fig. 1: PuntoDeEntrada y su solucin

5.1 Categora 1: En los conjuntos de casos de uso Esta categora se centra en los antipatrones que se presentan en un conjunto de casos de uso relacionados, que se suelen diagramar en un mismo modelo. Punto de Entrada Nombre: PuntoDeEntrada (EntryPoint) Nombre alterno: CasoDeUsoDirector (DirectorUseCase) Causas: Desconocimiento y modelado del flujo en la interface de usuario. Descripcin: Se presenta cuando el actor principal se relaciona con solo un caso de uso, el cual tiene relaciones de dependencia con los dems casos de uso. El nombre de Caso de Uso Director proviene de la

Modelado Desordenado Nombre: ModeladoDesordenado (MessyModeling) Nombre alterno: FormateoDifuso (DiffuseFormatting) Causas: Descuido y deficiencias en la arquitectura. Descripcin: Se presenta cuando los diagramas quedan desordenados, bien porque tienen muchos casos de uso o porque no se pone el lmite del sistema o mdulo; esto dificulta su comprensin, realizacin e implementacin. Factores que motivan su uso: La necesidad de representar lo que requiere el usuario por ms extenso o confuso que resulte, sin hacer un ejercicio de modularizacin que conduzca a una vista conceptual de la arquitectura con los paquetes relativos al usuario. Ejemplo y/o posible solucin: Para resolver la situacin de la falta de lmite y el desorden, a nivel del equipo de trabajo, se pueden hacer acuerdos en cuanto al modelado para usar el lmite del sistema o paquete y un nmero de casos de uso por diagrama. La Figura 2 ilustra un diagrama en el que se presenta este caso en el anti-patrn y la forma en que se resuelve.

Fig. 2: Caso 1 de ModeladoDesordenado y su solucin

Para resolver la situacin de muchos casos de uso en el mismo diagrama, a nivel de arquitectura, se puede hacer una modularizacin en paquetes y hacer un diagrama de

56

casos de uso para cada paquete, de esta forma se mejora la comprensin de los diagramas [11]. Inclusive se puede usar un Diagrama de Paquetes de Casos de Uso, basado en la estrategia diagramacin propuesta en [12]. La Figura 3 ilustra un diagrama en el que se presenta este caso en el anti-patrn y la forma en que se resuelve.

casos de uso. El modelo y la especificacin textual se vuelven confusos, ya que el conjunto de interacciones del cliente de negocio es diferente al de los actores del sistema informtico [11]. Factores que motivan su uso: La necesidad de que los casos de uso documenten completamente la empresa, sin diferenciar lo que quieren los diferentes tipos de actores. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se deben definir niveles de modelado para diferenciar casos de uso de requisitos y casos de uso del negocio, estos segundos se pueden articular con la arquitectura empresarial o artefactos similares. La Figura 4 ilustra un diagrama en el que se presenta este anti-patrn y la forma en que se resuelve.

Fig. 3: Caso 2 de ModeladoDesordenado y su solucin

5.2 Categora 2: En los casos de uso Esta categora se centra en los antipatrones que se presentan en cada caso de uso individualmente. Nombre Confuso Nombre: NombreConfuso (ConfusingName) Nombre alterno: NombreErrado (Misnomer) Causas: Descuido y deficiencias en gestin del equipo de trabajo. Descripcin: Se presenta cuando los nombres de los casos de uso se ponen desde la perspectiva del sistema y no del usuario, o cuando no se utiliza voz activa para su denominacin, sea que no se usa un verbo en infinitivo seguido de un sustantivo y de ser necesario un corto predicado, indicando de esta forma una accin. Factores que motivan su uso: La necesidad de que los casos de uso queden bien documentados y representen bien lo que se implementa, en lugar de representar lo que requiere el usuario. Ejemplo y/o posible solucin: Ejemplo de esta situacin podra ser un caso de uso llamado Matrcula Estudiante en una institucin educativa que permite a los estudiantes realizar la matrcula en lnea por Internet; primero su nombre se orienta ms al sistema que al actor, segundo no est en voz activa y por ende no indica una accin en s; en este caso lo correcto sera por ejemplo un caso de uso llamado Realizar Matrcula. Alcance Mezclado Nombre: AlcanceMezclado (MixedUpScope) Nombre alterno: NegocioOSistemaDeInformacion (BusinessOrComputerSystem) Causas: Desorganizacin y falta de niveles de abstraccin en el modelado. Descripcin: Se presenta cuando los modeladores tratan de mostrar tanto a los actores de la empresa como a los usuarios del sistema informtico en el mismo modelo de

Fig. 4: AlcanceMezclado y su solucin

Granularidad Fuera de Lugar Nombre: GranularidadFueraDeLugar (MisplacedGranularity) Nombre alterno: ObjetivoDeNegocioOAccinIncidental (BusinessGoalOrIncidentalAction) Causas: Descuido y falta de niveles de abstraccin en el modelado. Descripcin: Se presenta cuando los casos de uso constituyen procesos muy generales con granularidad muy gruesa, en este caso corresponden ms a objetivos en el modelado de negocio, que a requisitos en el anlisis. Tambin se presenta cuando los casos de uso constituyen operaciones muy puntuales con granularidad muy fina, en este caso corresponden ms a acciones incidentales en el diseo del sistema, que a requisitos en el anlisis. El trmino acciones incidentales proviene de la denominacin que le dan a la ilustracin de este problema en [11]. Factores que motivan su uso: La necesidad de que los casos de uso documenten completamente la empresa o cmo se implementarn funcionalidades muy puntuales, sin diferenciar lo que quieren los actores del sistema de informacin. Ejemplo y/o posible solucin: Los casos de uso en el anlisis de requisitos corresponden a Procesos Elementales de Negocio (Elementary Business Process) [4], por tanto se debe definir y revisar la granularidad de los casos de uso por parte del equipo de trabajo, para evitar trabajo innecesario o implementaciones muy complejas. Un ejemplo de esta situacin en una institucin educativa podra ser, Mejorar la Calidad de la Educacin como objetivo de negocio, Seleccionar Curso como accin incidental en el sistema y Matricular Estudiante como proceso elemental de negocio, por tanto solo el ltimo caso corresponde a un caso de uso de requisitos.

57

Caso de Uso Imperativo Nombre: CasoDeUsoImperativo (ImperativeUseCase) Nombre alterno: CasosDeUsoEnDiseo (UseCaseInDesign) Causas: Desconocimiento y modelado desde la perspectiva del desarrollo. Descripcin: Se presenta cuando los casos de uso se centran ms en el Cmo que en el Qu. Los casos de uso hacen parte fundamental del anlisis de requisitos, por tanto son por naturaleza declarativos (se enfoca mayoritariamente en el Qu o el espacio del problema), mientras que el diseo es imperativo (se enfoca mayoritariamente en el Cmo o el espacio de la solucin), por tanto los modelos de casos de uso no deben invadir el diseo. Factores que motivan su uso: La necesidad de que los casos de uso documenten y representen bien cmo se implementarn, en lugar de representar lo que requiere el usuario. Ejemplo y/o posible solucin: Incluyen los llamados casos de uso CRUD, denominados as por representar las operaciones de Create, Read, Update y Delete; en ocasiones llamadas operaciones CRUDEL [13], adicionando Exist para verificar la existencia de una instancia de una entidad y List para recuperar todos los datos de una entidad. Es notorio que estas operaciones entran ms en el diseo que en el anlisis, por tanto ms que hacer un caso de uso por cada operacin, se debera hacer un caso de uso que agrupe este conjunto de operaciones, generalmente denominado Gestionar [Nombre de la Entidad Implicada]. Dicha regla podra tener una excepcin, cuando la labor de creacin de una instancia de la entidad implicada es muy compleja, justificando la definicin de casos de uso para algunas de sus operaciones CRUDEL; sin embargo, en este caso es posible que un verdadero proceso elemental de negocio haya sido omitido y se est enmascarando dichas operaciones. Ejemplo de operaciones CRUDEL que ocultan un proceso elemental de negocio, podra ser Gestionar Estudiante en una institucin educativa, el cual podra enmascarar el proceso de Matricular Estudiante. 5.3 Categora 3: En los escenarios y pasos Esta categora se centra en los anti-patrones que se presentan en la especificacin de los casos de uso, cuando se describen sus escenarios y sus pasos. Tipo de Flujos Indeterminados Nombre: TiposDeFlujoIndeterminados (IndeterminateFlowTypes) Nombre alterno: FlujoAlternativoOExcepcional (AlternativeOrExceptionalFlow) Causas: Desconocimiento y deficiencias en gestin del proyecto o del equipo de trabajo. Descripcin: Cuando se especifican los casos de uso, se hace especial nfasis en la documentacin del flujo de eventos principales, los cuales definen la coleccin de escenarios que suceden regularmente (o como es llamado en ocasiones: Happy Path); mientras que en algunos casos los dems flujos no son trabajados con el

rigor debido. En otros casos los flujos alternativos y excepcionales no se separan, por el desconocimiento de la principal diferencia entre estos dos tipos de flujos: (a) flujo alternativo, que alcanza el objetivo planteado para el caso de uso por un camino diferente al Happy Path y (b) flujo excepcional, que NO alcanzan el objetivo planteado para el caso de uso. En ocasiones los flujos excepcionales necesitan definir eventos de compensacin, o sea devolver el sistema al estado en el que estaba antes de la ejecucin del caso de uso, mientras que los flujos alternativos no sugieren esta labor. Al no hacer un anlisis separado de estas situaciones, se dificulta la realizacin de pruebas apropiadas para cada situacin, se pueden disminuir los llamados casos de prueba y aumenta la posibilidad de errores. Factores que motivan su uso: La premura en la entrega de los proyectos hace que el tiempo para la capacitacin del personal, la definicin de acuerdos y las pruebas sean labores que pueden retrasar la agenda de los proyectos. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se deben definir acuerdos tendientes a diferenciar estos tipos de flujos en la especificacin de los casos de uso, y de esta forma poder darle el tratamiento apropiado a cada tipo de flujos. Estilo de Escritura Indefinido Nombre: EstiloDeEscrituraIndefinido (UndefinedWritingStyle) Nombre alterno: DesacuerdoEnTipoDeEscritura (DisagreementOnWritingType) Causas: Descuido y deficiencias en gestin del equipo de trabajo. Descripcin: Existen varias caractersticas que pueden afectar la redaccin de los flujos de trabajo, entre ellos se destacan: (a) escenarios muy largos o con redaccin confusa, lo que dificulta considerablemente la comprensibilidad del caso de uso, (b) diferencias en la granularidad de los escenarios, las cuales plantan actividades con granularidad muy gruesa y muy fina en el mismo escenario, (c) mezcla de estilos de escritura, en el estilo esencial se evita tratar la interface de usuario y en el estilo concreto se refieren elementos de la interface de usuario y (d) parcialidad tecnolgica, en la descripcin del caso de uso se incluyen elementos propios de la plataforma en la que ser implementado el sistema. Factores que motivan su uso: La necesidad de que los casos de uso queden bien documentados, en algunos casos hacen que el especificador incurra en detalles innecesarios que entran ms en el espacio de la solucin que del problema. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, en los escenarios muy largos se puede considerar dividirlo en varios casos de uso, pues es posible que se est enmascarando un proceso elemental de negocio. Para resolver los otros casos es necesario definir acuerdos en el equipo de trabajo para usar trminos del domino y definir una granularidad apropiada y un estilo determinado.

58

Desempoderamiento Funcional Nombre: DesempoderamientoFuncional (FunctionalDisempowerment) Nombre alterno: EmpoderamientoPerdido (LostEntitlements) Causas: Desorganizacin y falta de acuerdos para el modelado. Descripcin: Se presenta cuando un caso de uso que involucra dos o ms actores, inicia su flujo preguntando quien es el actor para definir que flujos o escenarios puede utilizar. En estas situaciones ninguno de los actores est verdaderamente empoderado del caso. Factores que motivan su uso: La necesidad de que los casos de uso documenten todos los actores implicados, a la par que se factoriza el comportamiento en comn que estos realizan, aunque ello conlleve a artificiosas especificaciones de los casos de uso. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se debe dividir el caso de uso en dos para garantizar el empoderamiento de cada actor. Un ejemplo de esta situacin en una institucin educativa podra ser el caso de uso de Gestionar Oferta de Cursos relacionado con los actores Directivo y Docente, su flujo inicia preguntando si se trata de un Directivo para permitirle modificar o hacer cualquier otra accin sobre la oferta de curso, o si se trata de un Docente para permitirle solo revisar la oferta de cursos para hacer reservas de cupos o acciones por el estilo. En esta situacin se debe dividir en dos casos de uso, inclusive buscando un nombre ms apropiado para los procesos elementales de negocio implicados, un caso de uso llamado Revisar Oferta de Cursos relacionado con ambos actores, y otro caso de uso llamado Programar Oferta de Cursos que permite cualquier accin sobre la oferta de cursos al Directivo. La Figura 5 ilustra un diagrama en el que se presenta este anti-patrn y la forma en que se resuelve.

Factores que motivan su uso: La necesidad de que el modelo documente completamente las tareas que realizan todos los actores, sin considerar lo complicado que puede ser la comprensin del diagrama. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se debe buscar un super-tipo en los actores para construir una jerarqua que simplifique las relaciones, inclusive se pueden soportar ligeras diferencias en las relaciones entre actores y casos de uso como se ilustra en la Figura 6 con el actor C que es el nico que est relacionado con el caso de uso Z.

Fig. 6: RelacionesEnmaraadas y su solucin

Relaciones Redundantes Nombre: RelacionesRedundantes (RedundantRelationships) Nombre alterno: RelacionesSobrantes (WastedRelationships) Causas: Desconocimiento y falta de acuerdos para el modelado. Descripcin: Se presenta cuando un caso de uso tiene relaciones de dependencia con otro, y al actor involucrado se le pone asociacin con ambos casos de uso. En estas situaciones solo es necesario que los actores estn relacionados con el caso de uso base. Factores que motivan su uso: Dejar en claro dentro de los diagramas todos los casos de uso que se relacionan con los actores, sin revisar las implicaciones de las relaciones de dependencia que existen entre estos. Ejemplo y/o posible solucin: Para resolver este tipo de situaciones, se deben eliminar la relacin redundante. La Figura 7 ilustra un diagrama en el que se presenta este anti-patrn y la forma en que se resuelve.

Fig. 5: DesempoderamientoFuncional y su solucin

5.4 Categora 4: En las relaciones Esta categora se centra en los anti-patrones que se presentan en la especificacin de relaciones entre los casos de uso, o entre estos y los actores. Relaciones Enmaraadas Nombre: RelacionesEnmaraadas (TangledRelationships) Nombre alterno: RelacionesDeTelaraa (SpiderwebRelationships) Causas: Descuido, desconocimiento y falta de acuerdos para el modelado. Descripcin: Muchos actores que se relacionan al tiempo con muchos casos de uso en el mismo diagrama, generan una complicada red de relaciones que dificulta la comprensin del modelo.
Fig. 7: RelacionesRedundantes y su solucin

Relaciones Incorrectas Nombre: RelacionesIncorrectas (WrongRelationships) Nombre alterno: RelacionesErradas (MisusedRelationships) Causas: Descuido, desconocimiento y falta de acuerdos para el modelado. Descripcin: Se presenta cuando la direccin o la semntica de las relaciones de inclusin o extensin son mal utilizadas, al igual que la generalizacin entre casos.

59

Factores que motivan su uso: La necesidad de dejar clara la relacin entre todos los casos de uso implicados, sin considerar la semntica de las relaciones. Ejemplo y/o posible solucin: Para resolver esta situacin, se debe revisar la semntica y la direccin de las relaciones de dependencia y generalizacin, esto evita modelar la navegacin de la interface de usuario o la secuencialidad de los casos de uso, como lo recomienda [10]. Para ejemplificar el buen uso de las relaciones entre casos de uso, la Figura 8 ilustra una situacin en una institucin educativa que presenta las diferentes situaciones.

el xito de un proyecto de software, pues un modelo de requisitos con errores, acarrea desarrollos con errores. La facilidad para construir y comprender un diagrama de casos de uso, ha dado pie para que en algunos casos no se ponga especial atencin en la especificacin de requisitos usando casos de uso. En otros casos, los conocimientos del equipo de trabajo en reas como el desarrollo, los lenguajes de programacin y la tecnologa; en lugar de favorecer un buen modelo de casos de uso, juega en contra de ste al terminar incluyendo detalles propios del diseo o la implementacin. Las malas prcticas que se explicitan en estos antipatrones, han sido encontradas frecuentemente en diversos proyectos de desarrollo de software en los que participaron los autores, tanto en labores de consultora como de desarrollo. En dichos proyectos se inici la construccin del material que sirvi de base para la definicin de este catlogo de antipatrones al especificar requisitos funcionales usando casos de uso. Varias de las empresas para las que se realizaron estos proyectos, han realizado retroalimentacin con respecto a lo til que les resulta el material en el hallazgo de malas prcticas en requisitos, este es uno de los factores que nos hace pensar que el artculo le puede ser til a los lectores que trabajen en proyectos de desarrollo que especifiquen requisitos usando casos de uso. A pesar de contar con un compendio de material acerca de malas prcticas en especificacin de requisitos con casos de uso, formalizar estas experiencias para escribir este catlogo de antipatrones, resulta de gran utilidad para mejorar la compresibilidad del material. Las reflexiones para categorizar, buscar las causas y describir los antipatrones, mejoran las posibilidades de plantear ejemplos y esquemas de solucin que sean entendibles y fciles de aplicar. Los trabajos futuros alrededor de este catlogo de antipatrones al especificar requisitos funcionales usando casos de uso, se pueden plantear en varios frentes:

Fig. 6: Buen uso de relaciones entre casos de uso

En cuanto a la direccin de relaciones de dependencia de <<include>> y <<extend>>, es importante considerar que para la lectura del modelo, ambos verbos se asumen como si estuvieran conjugados en presente (incluye y extiende), por tanto la lectura y direccin queda de la siguiente forma:
En el caso de la inclusin (include):

El caso de uso base incluye el caso de uso incluido. La direccin va desde base hacia el incluido. En el caso de la extensin (extend): El caso de uso extensor extiende el caso de uso base. La direccin va desde el extensor hacia base.

En cuanto a la semntica de las relaciones entre casos de uso, la diferenciacin de las relaciones entre casos de uso est determinada por la comparacin de sus objetivos, a continuacin se describen las principales condiciones que estas deben cumplir: En el caso de la inclusin (include): Objetivo incluido es obligatorio Objetivo base = Objetivo incluido + Objetivo base Objetivo incluido es grande En el caso de la extensin (extend): Objetivo extensor es opcional Objetivo extensor = Objetivo base + Objetivo base Objetivo extensor es pequeo En el caso de la herencia o generalizacin: Objetivo heredado solo cambia la modalidad Objetivo base = Objetivo heredado Cabe aclarar que en las relaciones de herencia, el caso de uso hijo puede adicionar nuevas operaciones, como tambin redefinir o enriquecer con nuevos escenarios, operaciones ya existentes en el caso de uso padre [17]. 6. CONCLUSIONES Y TRABAJO FUTURO Un buen anlisis de requisitos y particularmente un buen modelo de casos de uso, resulta fundamental para

Complementar los antipatrones del catlogo para presentar otras malas prcticas experimentadas o propias de un dominio especfico. Encontrar y formalizar relaciones de causalidad entre los antipatrones en el anlisis de requisitos con otras malas prcticas o antipatrones en diferentes disciplinas del proceso como el modelado de negocio, el anlisis y diseo, o las pruebas. Integrar el catlogo de antipatrones en herramientas y nuevos enfoques de construccin de sistemas de informacin como el desarrollo de software dirigido por modelos [14], buscando por ejemplo que los antipatrones sean detectados automticamente en un modelo de casos de uso, y se le den recomendaciones al modelador para que corrija la situacin y mejore su modelos para disminuir la posibilidades de incurrir en errores.

60

7. REFERENCIAS
[1] The Standish Group International. 2011. CHAOS Manifesto 2011. CHAOS Knowledge Center. [2] Steve, A. et al. 2003. Patterns for Effective Use Cases. The Agile Software Development Series. Addison-Wesley. [3] Booch, G.; Rumbaugh, J. & Jacobson I. 2000. El Proceso Unificado de Desarrollo de Software.Addison Wesley. [4] Larman, C. 2003. UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. Prentice Hall. [5] Buschmann, F. et al. 1996. Pattern-Oriented Software Architecture: A System of Patterns. Wiley & Sons. [6] Gamma, E. et al. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. [7] Brown, W. et al. 1998. Antipatterns: Refactoring Software, Architectures and Project in Crisis. Wiley & Sons. [8] Welicki, L. 2006. Patrones y Antipatrones: una Introduccin. MSDN. Online [Abr. 2012]. [9] Cockburn, A. 2000. Writing effective use cases. AddisonWesley Professional.

[10] Booch, G.; Rumbaugh, J. & Jacobson, I. 1999. El Lenguaje Unificado de Modelado. Addison Wesley. [11] Lilly, S. 1999. Use Case Pitfalls: Top 10 Problems from Real Projects Using Use Cases. In proceedings of TOOLS USA '99, IEEE Computer Society. [12] Ambler, S. 2010. Use Case Package Diagrams. Ambysof. Online [Abr. 2012]. [13] Kruger, S. et al. 2007. Engineering WS-I compliant web services for IBM Lotus Domino V8. IBM. Online [Abr. 2012]. [14] Vlter, M. & Stahl, T. 2006. Model-Driven Software Development. Technology, Engineering, Management. Wiley Software Patterns Series. [15] Pow-Sang, J. A. 2003. La Especificacin de Requisitos con Casos de Uso: Buenas y Malas Prcticas. Online [Abr. 2012]. [16] Kurt Bittner. 2001. Why Use Cases Are Not "Functions". Online [Abr. 2012]. [17] Giandin, R. & Pons, C. 2000. Relaciones entre Casos de Uso en el Unified Modeling Language. Online [Abr. 2012].

61

Risk-based Testing Pruebas basadas en riesgos

Universidad de las Ciencias Informticas. La Habana, Cuba. hmenendez@uci.cu Universidad de las Ciencias Informticas. La Habana, Cuba. ymillet@uci.cu 3 Universidad de las Ciencias Informticas. La Habana, Cuba. arbatista@uci.cu
1 2

Heydi Menndez A.1, Yanetsi Millet L.2, Aniubis Rodrguez B.3

INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo Recibido: 30/04/2012 Correcciones: 29/05/2012 Aceptado: 31/05/2012 Palabras clave Calidad, Prueba, Riesgos. Categories and Subject Descriptors D.2.5 [Testing and Debugging]: Error handling and recovery. General Terms Verification. Keywords Quality, Testing, Risk.

ABSTRACT Risk management is a complex process that leads to the planning and implementation of policies, strategies, tools and measures to prevent, reduce, predict and control the adverse effects of dangerous events on the project; so take integrated measures to reduce risk through prevention, mitigation, preparedness and emergency response. This process has become important in recent years, given the impact it has in meeting project objectives and quality. In this work we make a study on testing techniques based on risk, with analysis of these to provide a guide to homogenize its application in productive projects of the university and to establish mechanisms for timely detection of risks threaten the quality of the final product. RESUMEN La Gestin de Riesgos es un proceso complejo que conduce al planeamiento y aplicacin de polticas, estrategias, instrumentos y medidas orientadas a impedir, reducir, prever y controlar los efectos adversos de fenmenos peligrosos sobre el proyecto; por lo que se llevan acciones integradas de reduccin de riesgos a travs de actividades de prevencin, mitigacin, preparacin y atencin de emergencias. Este proceso ha adquirido gran importancia en los ltimos aos, dado el impacto que tiene en el cumplimiento de los objetivos del proyecto y la calidad del mismo. En el presente trabajo se realiza un estudio profundo acerca de las tcnicas de pruebas basadas en riesgos, haciendo un anlisis de estas para proporcionar una gua que homogenice su aplicacin en los proyectos productivos de la universidad y que permitan establecer mecanismos de deteccin oportuna de riesgos que amenacen la calidad del producto final.

1. INTRODUCCIN Con frecuencia los proyectos productivos de la Universidad de las Ciencias Informticas (UCI) sufren afectaciones en su cronograma, en la calidad del producto, en el presupuesto y en la formacin de los estudiantes. Una variable significativa en la Gestin de Proyectos es la Gestin de Riesgos y se considera que el nivel de calidad de todo proyecto depende de la minimizacin del nmero de riesgos al que se enfrenta el mismo. Actualmente, en el diseo de las pruebas nicamente se tiene en cuenta los requisitos funcionales y los casos de uso derivados de estos. La gestin de riesgos no pasa de ser una simple tarea que se resuelve sin que sus resultados repercutan positiva o negativamente en el desempeo del software construido. Esto trae como efecto la deteccin de errores en etapas tardas como son las pruebas de liberacin y aceptacin, donde elementos de peso aparentemente insignificante se muestran tomando gran importancia, pudindose haber evitado con un buena captura de los riesgos a la calidad del sistema, y posteriormente con un buen anlisis y tratamiento de los mismos. Dichos riesgos que afectan a la calidad se presentan a diario en todas las pruebas de liberacin en forma de errores del sistema que a su vez demoran el proceso de pruebas y desprestigian en alguna medida la imagen que se quiere lograr del sistema que se est liberando.

El presente trabajo tiene como objetivo hacer un levantamiento de las tcnicas de anlisis de riesgos para efectuar pruebas al software, as como enunciar mediante un ejemplo la tcnica propuesta para los proyectos de la UCI que servir de base para la construccin de un sistema que permita automatizar de algn modo el proceso de anlisis anterior a las pruebas basadas en riesgos y determinar su alcance. 2. DESARROLLO 2.1 Pruebas basadas en riesgos Las pruebas basadas en riesgos consisten en [1]: Identificar riesgos especficos a la calidad del sistema. Evaluar y asignar el nivel de riesgo a cada riesgo, basndose en la probabilidad de ocurrencia (a consideracin tcnica) y el impacto (consideraciones del negocio). Asignar el esfuerzo de prueba y priorizar la ejecucin de las pruebas basadas en riesgo [7]. Revisar el anlisis de riesgo a intervalos regulares en el proyecto incluyendo el despus de las pruebas de la primera construccin. 2.2 Los riesgos y las pruebas de software Un riesgo es un resultado potencial indeseable. Por lo que un riesgo a la calidad del sistema es cualquier problema potencial que podra hacer que el sistema fallara en encontrar las expectativas razonables de

62

calidad. Los riesgos se agrupan u organizan por categoras como son: funcionalidad, performance, seguridad, etc. Los riesgos estn presentes siempre en todo tipo de actividad que ha hecho el hombre. En el mundo del software podemos decir que cualquier proyecto significativo incluye riesgos [2]. Estos aumentan con la complejidad, el nmero de participantes, esfuerzo, presupuesto y duracin. Las probabilidades de fracaso de un proyecto de software estn en los lmites del 2% al 85%. Las malas pruebas son consideradas como una de las cuatro causas fundamentales del fracaso junto con la estimacin pobre, la mala planificacin y el mal seguimiento del proyecto (tracking). La gestin de riesgos clsica dice de mitigar estos utilizando ambos mtodos, proactivo (entrenamiento cruzado del personal) y reactivo (codificacin de componentes redundantes) (reutilizacin) [12]. Los riesgos a la calidad del sistema pueden ser mitigados empleando como mtodo proactivo las revisiones y como reactivo las pruebas. El anlisis de riesgos de la calidad es un proceso para la identificacin, el anlisis, la categorizacin prioritaria de los problemas potenciales de la calidad de un sistema determinado. Una vez que los riesgos son identificados, cada uno es asignado a un nivel (en la medida de su grado de importancia). 2.3 Tcnicas para analizar el riesgo Informal quality risk analysis Proporcionar un modo fcil para comenzar el anlisis de riesgos de la calidad. Uno probablemente omite algunas reas importantes de riesgo, sobre todo durante tempranos anlisis de riesgos, pero esta tcnica aunque es informal hace posible alcanzar un mejor grado de enfoque en la prueba y una mayor cobertura que la que se alcanza normalmente sin dicho anlisis [3]. ISO 9126 quality risk analysis Para la presente tcnica de anlisis de riesgo se deben usar las caractersticas y sub-caractersticas descritas en la ISO 9126 como sistema estndar de categoras para el anlisis de riesgos. Las principales son [10]: Funcionalidad Fiabilidad Usabilidad Eficacia Mantenibilidad Portabilidad

asociadas a varios riesgos? y cunto se debe gastar en reducir esos riesgos? Una prdida esperada es el producto de la probabilidad de la prdida multiplicada por el costo de la misma [4]:
Prdida esperada = Probabilidad de la prdida * Costo de la prdida

Dicha tcnica permite al equipo de gestin del proyecto tomar una decisin econmica sobre las pruebas. Para que la misma funcione bien, el equipo de anlisis debe ser capaz de estimar con exactitud las probabilidades y los gastos de varias prdidas. Failure mode and effect analysis El mtodo de anlisis de modo de fallos y efecto va ms all de la discusin sobre riesgos [5]. Empleando esta tcnica el equipo de anlisis de riesgo trata de identificar los aspectos en los que el sistema podra fallar, y todos los posibles efectos que estas fallas puedan traer, en los clientes, en el negocio y en la sociedad. Es una tcnica bien detallada, puede producir una prueba finamente cargada, pero tambin una tonelada de papeleo y trabajo administrativo y mucho tiempo invertido en las mismas. Hazard analysis Esta tcnica comparte ciertos criterios con la tcnica de modo de falla y anlisis de efecto, pero se realiza a la inversa. Comienza por el anlisis de los efectos para de esta forma identificar las causas de los mismos. Durante el trabajo se van haciendo ms claras las probabilidades de esas causas. En algunos casos, aunque existen muchas causas de diferentes tipos de malos comportamientos, esta tcnica tiende a funcionar mejor en sistemas pequeos (ver Tabla 1).
Tabla 1. Comparacin de las tcnicas de anlisis de riesgo
Tcnica En resumen Informal Basada en historial, experiencias y listas de chequeo. Fcil, de peso ligero, flexible. Dependiente del personal participante, abierta, imprecisa. De riesgo giles. bajo o ISO 9126 Siguiendo las caractersticas de calidad segn el estndar industrial. Predefinida, exhaustiva, comn. Potencialmente sobre estimada, sobre regimentada. Comprometido con los estndares. Muy inusuales o de estructura intolerante. Costo de exposicin Estimacin del costo de prueba contra el costo de no probar.

Fortalezas

Balanceada, singular, tradicional. Intensivo informacin, exclusivamente monetaria. Financiero. de

Debilidades

En cada categora existe una o ms sub-caractersticas de la ISO 9126, esto provee un acercamiento ms estructurado y reduce la probabilidad de omitir algunos elementos de riesgo que son importantes [11]. Cost of exposure quality risk analysis La tcnica de costo de exposicin se enfoca en la siguiente pregunta: Cules son las prdidas esperadas,

Adecuada para proyectos Evitar en proyectos

Crticos o regulados en cuanto a seguridad.

De seguridad crtica.

Tcnica En resumen

Modo de fallas/anlisis de efectos Identifica los errores

Anlisis de amenazas Analiza causas de

63

potenciales y su efecto en los involucrados. Fortalezas Debilidades Precisa, general. meticulosa,

amenazas (fuentes riesgo). Exacta, sistemtica. Fcilmente abrumarse complejidad.

de

prudente, puede por su

Prolongada, pesada documentacin, difcil de aprender. De alto riesgo conservativos. o

Analizar y perfeccionar el listado de riesgos de calidad. Alineacin de las pruebas con los riesgos de calidad. Ejecucin de las pruebas basadas en riesgos. Evaluacin del grado de beneficios y lecciones obtenidas. 2.6 Ejemplo prctico de prueba basada en riesgos El proceso ser desplegado en una Empresa x de desarrollo de software y el mismo estar guiado por las seis actividades fundamentales enunciadas anteriormente. Entrenamiento de los stakeholders Para llevar a cabo esta actividad se tienen en cuenta cinco temas a desarrollar en la capacitacin: Principios bsicos de las pruebas y el por qu basarlas en riesgos. Comprensin de las categoras de riesgos de calidad (funcionalidad, rendimiento, fiabilidad, usabilidad, etc.). Cmo realizar un anlisis de riesgos de calidad y alinear las pruebas con niveles de riesgo? Cmo documentar los riesgos a la calidad? Cmo monitorear los riesgos de calidad durante la ejecucin de la prueba e informar resultados de las pruebas basadas en riesgos? Sesin de anlisis de riesgos a la calidad La sesin de anlisis de riesgos a la calidad consta de dos sub-sesiones. En la primera se identificaron la mayor cantidad de riesgos posibles usando la tcnica de tormenta de ideas. En la segunda se definieron varios equipos para determinar la probabilidad de ocurrencia de los riesgos y el impacto que podran traer sobre el sistema. En las Tablas 2 a 4 se muestran los valores empleados para asignar las probabilidades a los riesgos, as como su impacto.
Tabla 2. Valores de la probabilidad de ocurrencia Probabilidad Muy probable Probable Algo probable Improbable Muy improbable Valor 1 2 3 4 5

Adecuada para proyectos Evitar proyectos en

Mdico o embebido.

Caticos, rpidamente Impredecibles o cambiantes o ligados a complejos. prototipos. Tomado de Quality Risk Analysis

2.4 Proceso de anlisis de riesgos a la calidad Sin importar la tcnica escogida, el camino a seguir para el proceso de anlisis debe ser el siguiente: Identificar el equipo de analistas de riesgos a la calidad [11]. Seleccionar una tcnica. Identificar los riesgos, priorizarlos, seleccionar acciones de mitigacin idneas (Brainstorm) [11]. Si el equipo detecta problemas en los requerimientos o en otro artefacto, deben reportarse inmediatamente para su resolucin. Revisar, repasar y finalizar el documento de anlisis de riesgos a la calidad. Comprobar el documento de anlisis de riesgo a la calidad en el expediente de proyecto y bajo control de versiones [8]. En intervalos regulares de tiempo y unido al incremento de informacin del proyecto, se debe repasar y actualizar el anlisis de riesgos adicionando nuevos elementos identificados y reevaluando los niveles de riesgo para los detectados anteriormente [6].

Fig. 1: Proceso de pruebas basadas en riesgo

2.5 Proceso de pruebas basadas en riesgos El proceso de pruebas basadas en riesgos est compuesto por seis actividades fundamentales (ver Figura 1), las cuales constituyen la base para una ejecucin rpida y eficiente de las pruebas [9]. La formacin de los principales involucrados en las pruebas basadas en riesgos. Realizacin de una sesin de anlisis de riesgos de calidad.

Muy probable: muy cercano a pasar. Probable: Ms probable a pasar que a no pasar. Algo probable: Existen pocas probabilidades de ocurrencia. Improbable: Menos probable a pasar que a no pasar. Muy improbable: No debe pasar.
Tabla 3. Impacto del riesgo sobre la calidad del sistema Impacto Correccin inmediata Correccin programada Debe corregirse Sera bueno corregirlo No corregir Valor 1 2 3 4 5

64

Correccin inmediata: Prioridad uno. Correccin programada: Programacin en cronograma para su correccin lo antes posible. Debe corregirse: No debe recibir atencin mientras las otras dos categoras superiores no se hayan cubierto totalmente. Sera bueno corregirlo: Algo que el cliente tomara positivamente si se arreglara pero no atenta contra el funcionamiento. No corregir: Ningn esfuerzo para solucionar este problema.
Tabla 4. Listado de riesgos resultado de la sesin
Riesgo Existen comandos de la librera de datos que no funcionan 3 2 6 Incompatibilid ad con la versin anterior del sistema 5 2 10 Los datos no se salvan correctamente 3 2 6

Asignar el esfuerzo de las pruebas basadas en el nivel de riesgo. Asociar los nmeros de riesgos a sus especificaciones. Asociar nmeros de riesgos a casos de prueba. Priorizar casos de prueba de acuerdo al nivel de prioridad del riesgo asociado. Una vez asociados los riesgos con su nmero de prioridad podemos aadir a la lista de riesgos el aspecto del alcance de la prueba, como se observa en la Tabla 6.
Tabla 6. Prioridades y alcance de las pruebas Prioridad del riesgo 1-12 13-16 17-20 21-25 Alcance de la prueba Extenso General Superficial Oportuno

Probabilidad Impacto Prioridad

Anlisis y refinamiento del listado de riesgos A partir de la probabilidad y el impacto asignados a cada riesgo se determina un nmero de prioridad para cada uno multiplicando los dos factores. Lo cual determina un rango de 1 a 25 para medir la prioridad asociada al riesgo. Refinando los viejos y nuevos elementos podemos elaborar para su anlisis un grfico con las prioridades de los mismos basndose en la cantidad de riesgos que presentan igual nmero de prioridad. Y de la misma forma agruparlos en grupos donde tengan la misma probabilidad e impacto por separado. En esta actividad se puede reajustar desde una visin ms objetiva cada impacto y probabilidad asignado a los riesgos de manera que esto permita asignarles un nmero de prioridad ms ajustado (Figura 2 y Tabla 5).

Extenso: Ejecutar un nmero grande de pruebas de forma general y profunda, ejercitando combinaciones y variaciones de condiciones diferentes para las pruebas. General: Ejecutar un nmero mediano de pruebas que ejerciten muchas condiciones diferentes de la prueba. Superficial: Ejecutar pocas pruebas que ejemplifiquen las condiciones ms probables del sistema. Oportuno: Favorecer otras actividades o realizar una prueba o dos de una condicin interesante, pero slo si se trata de una inversin muy pequea de tiempo y esfuerzo, y slo si se presenta la oportunidad. Luego de determinar el alcance de las pruebas para cada nivel de prioridad del riesgo se procede a asociar cada riesgo a la especificacin de requerimientos asociado al mismo. Preparacin de las pruebas Pasando a la actividad central del tema, ser mucho ms fcil comenzar a probar aquellos requerimientos del software que ms atencin requieren luego de los anlisis realizados con anterioridad. Evaluacin del grado de beneficio y lecciones obtenidas Luego de una reunin con los stakeholders se lleg a la conclusin de que la experiencia con la empresa arroj los siguientes beneficios:

Fig. 2: Prioridad de los riesgos Tabla 5. Riesgos agrupados en probabilidad e impacto

Probabilidad 1 2 3 4 5 Cantidad Riesgos 5 9 6 4 5 Impacto 1 2 3 4 5 Cantidad Riesgos 4 11 10 3 6

La capacidad de asignar el esfuerzo de la prueba inteligentemente dentro de las limitaciones de la empresa. La capacidad de "encontrar los defectos que en etapas tempranas". La capacidad de responder con flexibilidad a las reducciones de tiempo de prueba y recursos disponibles. La capacidad de optimizar la calidad. Adems de haber aprendido otras lecciones importantes sobre probar guiado por los riesgos y sobre el anlisis de riesgos, de las cuales la ms importante fue involucrar los usuarios del negocio lo cual le da una

Alineacin de los riesgos a la calidad a las pruebas Una vez completado el anlisis se procede a alinear las pruebas a los niveles de riesgo. Para esta accin se deben tener en cuenta los siguientes puntos:

65

visin ms cercana a los problemas que puede dar un sistema desde el punto de vista prctico y no tcnico como podra verlo en este caso el programador. 2.7 Valoracin econmica y aporte social En la universidad no se ha presentado este procedimiento con anterioridad donde adems de abordar las tcnicas de anlisis de riesgos ya diseadas por empresas internacionales, se pretende proponer un modelo para las pruebas de los proyectos de la universidad evitando as la deteccin de errores en etapas tardas y elevando as la eficiencia, productividad y sobre todo la calidad de los productos desarrollados en la universidad. La construccin del procedimiento para pruebas basadas en riesgo para la UCI incluye un anlisis ms pro-fundo de las tendencias actuales en la produccin de software en los diferentes centros y una construccin a partir de dichos elementos de un sistema que permita en un principio registrar los riesgos ms probables a ocurrir en las aplicaciones con las caractersticas de las que se producen y de esta forma asociar cada riesgo posible a los requerimientos reales de cada producto para luego pasar al anlisis detallado de los riesgos y la priorizacin de los mismos para las pruebas futuras. El sistema propuesto permitira a partir de la entrada de los niveles de probabilidad y de impacto por el usuario quien se encargara de cotejar cada riesgo con su especificacin correspondiente, determinar el alcance de la prueba empleando para la toma de decisiones una base de casos ya resueltos con anterioridad. Dicho alcance estara asociado al esfuerzo asignado a la misma (Probadores, Tiempo, Recursos). 3. CONCLUSIONES En el trabajo se enunciaron las tcnicas definidas en el mundo actual para el anlisis de riesgos a la calidad de los sistemas. Adems se propone mediante un ejemplo la tcnica ms adecuada a los proyectos de la universidad teniendo en cuenta el tipo de empresa que es, los tipos de clientes que tiene y los procesos de trabajo que se llevan a cabo a diario en la produccin.

Adems, se propone la continuidad de la investigacin con el desarrollo de un sistema que permita automatizar el anlisis anterior a las pruebas de software basadas en riesgos. 4. RECOMENDACIONES Completar progresivamente el anlisis de los beneficios que reporta la incorporacin de las tcnicas de anlisis de riesgos para la organizacin en general y sus servicios. Implementar una herramienta que gestione la informacin de los artefactos propuestos y que permita brindar los reportes de manera automatizada. Investigar y profundizar sobre los temas de anlisis de riesgos del proyecto y su influencia en el anlisis de riesgos del producto. 5. REFERENCIAS
[1] Black, R. 2003. Critical Testing Processes: Plan, Prepare, Perform, Perfect. Addison-Wesley Professional. [2] Black, R. 2007. Pragmatic Software Testing: Becoming an Effective and Efficient Test. Wiley. [3] Black, R. 2008. Quality Risk Analysis. RBCS, Inc. [4] Black, R.; Nash, P & Young, K. A Case Study in Successful Risk-Based Testing at CA. Online: http://www.rbcsus.com/images/documents/A-Case-Study-in-Risk-BasedTesting.pdf. [2011]. [5] Black, R. 2008. Advance software testing: Guide to the ISTQB Advanced Certification as an Advanced Test Analyst. Rocky Nook. [6] Black, R. 2009. Advanced Software Test Design Techniques: Use Cases. Testing Experience Magazine, December, 52-54. [7] Choucair, M. C. 2007. Pruebas de software la salvacin, un proceso sin utilidad, trivial, simplemente una moda? XXVII Saln de la Informtica en Colombia. [8] http://www.definicionabc.com/general/prueba.php [9] https://na.theiia.org/Pages/IIAHome.aspx. [10] ISO. 1994. ISO 8402: Quality management and quality assurance Vocabulary. [11] ISO. 2002. ISO 27000: Information technology - Security techniques -- Information security management systems Overview and vocabulary. [12] Shaefer, H. 2005. Risk based testing: How to choose what to test more and less. STC.

66

Proposed strategy for the execution of functional tests Propuesta de estrategia para la ejecucin de pruebas funcionales
Yadira Machado P.1, Odelky Betancourt G.2, Surima G P.3, Mairelis Quintero R.4, Yailin Fundora C.5
Departamento de Pruebas de Software, Centro Calisoft, La Habana, Cuba. 1 ymachadop@uci.cu, 2 odelky@uci.cu, 3 sgperez@uci.cu, 4 mquintero@uci.cu, 5 yfcarrasco@uci.cu INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Calidad, funcin, pruebas, estrategia Categories and Subject Descriptors D.2.4 [Software Engineering]: Correctness proofs, Validation. General Terms Software Engineering, Testing. Software ABSTRACT The software companies must assess the quality of their applications and between the main types of tests to be developed are function tests that aim to verify that the software meets the requirements and is a task that is gaining more and more importance. The Department of Software Testing (DPSW) belonging to CALISOFT (National Centre for Software Quality) under the Ministry of Informatics and Communications of Cuba defines a strategy to develop the function tests to ensure that the application that is tested meets the performance characteristics described ISO 9126. The strategy identifies the approach and general goals for the activities, levels and types of tests as well as the techniques and tools to be used. RESUMEN Las empresas productoras de software deben evaluar la calidad de sus aplicaciones y entre los principales tipos de pruebas a desarrollar se encuentran las pruebas de funcin, que tienen como objetivo comprobar que el software cumpla con los requisitos establecidos; tarea que va cobrando cada da mayor importancia. El Departamento de Pruebas de Software (DPSW), perteneciente a CALISOFT (Centro Nacional de Calidad de Software) adscrito al Ministerio de la Informtica y las Comunicaciones de Cuba, define una estrategia para desarrollar las pruebas de funcin garantizando as que la aplicacin informtica que se pruebe cumpla con la caracterstica de Funcionalidad descrita en la norma ISO 9126. La estrategia propuesta identifica el enfoque y los objetivos generales de las actividades, niveles y tipos de prueba as como las tcnicas y herramientas a ser usadas.

Keywords Quality, functionality, testing, strategy.

1. INTRODUCCIN La calidad del software se define como la concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente [1]. Para asegurar un determinado nivel de calidad se deben efectuar pruebas que permitan comprobar el grado de cumplimiento de los requisitos del sistema, que deben integrarse en las diferentes fases del ciclo de vida de la Ingeniera de Software. Una estrategia de prueba proporciona una gua para el responsable del desarrollo del software y para la organizacin de control de calidad debido a que debe describir los pasos a desarrollar. Por tanto, cualquier estrategia de prueba debe incorporar la planificacin y el diseo y ejecucin de casos de prueba. La prueba de funcin est centrada en validar los requisitos establecidos basndose directamente en los casos de uso, requisitos o historias de usuarios. En esta investigacin se presenta las pruebas de funcin empleando caja negra, es decir, verificar la aplicacin y sus procesos internos mediante la interaccin con la interfaz del sistema y analizar la salida resultados. Para la ejecucin de pruebas de funcin se ejecuta cada caso de uso, flujo de caso de uso o funcin, usando datos vlidos e invlidos, para verificar: (1) que los resultados

esperados ocurran cuando se usen datos vlidos y (2) que sean desplegados los mensajes apropiados de error y precaucin cuando se usan datos invlidos. Las pruebas de funcin que se realizan en el DPSW se ejecutan con el objetivo de comprobar si el producto que se prueba cumple con la caracterstica de funcionalidad descrita en la norma NC-ISO-IEC 9126-1. Esta norma es un estndar internacional para la evaluacin del software y est dividida en cuatro partes: modelo de calidad, mtricas externas, mtricas internas y calidad en las mtricas de uso. El modelo de calidad establecido en la primera parte del estndar clasifica la calidad del software en un conjunto estructurado de caractersticas: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. La funcionalidad se define como la capacidad del software para proporcionar funciones que satisfacen las necesidades declaradas e implcitas cuando el software se usa bajo las condiciones especificadas [2]. 2. ESTRATEGIA DE PRUEBAS El DPSW ha definido dentro de la caracterstica de funcionalidad tres tipos de prueba a realizar: de funcin, de seguridad y de volumen de la base de datos. La estrategia propuesta es lo suficientemente flexible para adecuarse a todos tipo de proyectos que se desarrollan con clientes nacionales o internacionales, ya sea una multimedia, productos de gestin, portales, etc. A continuacin se describen los objetivos de la estrategia:

67

 Definir los niveles de prueba que se ejecutarn en cada proceso de prueba del DPSW y las herramientas a ser utilizadas. Planificar las pruebas necesarias incluyendo las pruebas de unidad, de integracin y de sistema. Disear e implementar las pruebas creando los casos de prueba que especifican qu probar y cmo realizar las pruebas. 2.1 Etapas definidas para la estrategia de pruebas Los procesos de pruebas que se ejecutan en el DPSW cuentan con tres etapas: planificacin, diseo y ejecucin de pruebas. Planificacin de las pruebas. En esta etapa se determinan las personas involucradas en el proceso y todos los recursos que intervienen, teniendo en cuenta el propsito principal de la prueba; adems, se define la estrategia que se va a seguir, el orden de las actividades necesarias para realizar las pruebas y el tiempo dedicado para su ejecucin y el cronograma. Se realizan las siguientes actividades: Identificar al personal involucrado y los recursos, como los computadores a utilizar. Definir la estrategia y el plan de pruebas como documento rector del proceso. Identificar el propsito de la prueba de funcin. Identificar los requerimientos que se van aprobar. Planificar el orden para realizar las pruebas. Diseo de las pruebas. En esta etapa se disean las pruebas que guiarn el proceso planificado, a partir de la revisin a la documentacin y al diseo de los casos de pruebas documentando, la secuencia de pasos para ejecutar cada caso de prueba y los resultados esperados. Disear los casos de pruebas. Configurar el ambiente de prueba. Seleccionar la herramienta a utilizar. Ejecucin de las pruebas. Etapa en la que se ejecutan las pruebas diseadas con el fin de probar los requerimientos y determinar si se cumplen. En esta etapa se realizan las siguientes actividades: Ejecutar las pruebas diseadas. Analizar y registrar las No Conformidades encontradas. Evaluar el proceso de pruebas y sus resultados. 2.2 Niveles de pruebas de funcin definidos Los niveles de prueba definen los escenarios o niveles de trabajo, en los que es posible realizar el tipo de prueba de funcin en cuanto al nivel de trabajo en el que se realiza; se ejecuta la prueba independiente, es decir, aquella que es diseada e implementada por alguien independiente al grupo de desarrolladores. El objetivo de estas pruebas es proporcionar una perspectiva diferente al probar funcionalmente el sistema. El DPSW ejecuta el servicio de pruebas de liberacin como pruebas independientes. Adems, se realizan las

pruebas de aceptacin enfocadas al usuario final y que es la prueba antes del despliegue del sistema; su objetivo es verificar que el software est listo, que puede ser usado por usuarios finales y que ejecuta las funciones y tareas para las cuales fue construido. En cuanto a qu es lo que se prueba se definen las pruebas de unidad, encaminadas a probar los mdulos independientes del sistema; luego se realizan las pruebas de integracin para asegurar que esos mdulos se integren correctamente cuando se combinen para ejecutar un caso de uso. A continuacin se realiza una propuesta de cmo realizar las pruebas en el nivel de integracin. Pruebas de Integracin Las pruebas de integracin tienen como objetivo detectar las fallas de interaccin entre las diferentes clases que componen el sistema y verificar el correcto funcionamiento de dos o ms mdulos. La necesidad de realizarlas se debe al hecho de que los mdulos del software suelen fallar cuando trabajan de forma conjunta, aunque previamente se haya demostrado que funcionan correctamente de manera individual; un primer paso es identificar los mdulos crticos. De acuerdo con Pressman [3], los principales problemas cuando se realizan las pruebas de integracin son: los datos se pueden perder en una interfaz; un mdulo puede tener un efecto adverso e inadvertido sobre otro; cuando se combinan las sub-funciones pueden no producir la funcin principal deseada; la imprecisin aceptada individualmente puede crecer hasta niveles inaceptables y las estructuras de datos globales pueden presentar problemas. Para la realizacin de estas pruebas se cuenta con dos estrategias de integracin incremental diferentes: la ascendente y la descendente. La seleccin de una de ellas depende de las caractersticas del software y de la planificacin del proyecto. Una buena alternativa es usar una mezcla de las dos estrategias: la descendente para los niveles superiores de la estructura y la ascendente para los niveles subordinados. En la descendente se integran los mdulos movindose hacia abajo por la jerarqua de control y comenzando por el mdulo principal; los mdulos subordinados se van incorporando a la estructura que ya se encuentra probada y libre de errores. Al aplicar esta estrategia pueden surgir algunos problemas, el ms comn se da cuando se requiere un proceso de los niveles ms bajos de la jerarqua para probar adecuadamente los niveles superiores. Al principio de esta prueba, los mdulos de bajo nivel se reemplazan por resguardos, por lo que no pueden fluir datos significativos hacia arriba por la estructura del sistema. Este mtodo tiene como ventaja que permite ver la estructura del sistema desde un principio y como desventaja que requiere de mucho trabajo de desarrollo adicional, porque se debe escribir gran nmero de mdulos ficticios subordinados, resulta difcil introducir los casos de pruebas si no se han incorporados los mdulos de entrada y salida o los

68

juegos de datos de prueba pueden resultar difciles o imposibles de generar e induce a diferir la terminacin de la prueba en ciertos casos. La integracin ascendente empieza por construir y probar los mdulos de los niveles ms bajos de la estructura del sistema. Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados, a un nivel dado, siempre est disponible y se elimina la necesidad de resguardo. Entre sus ventajas se encuentra que las entradas para las pruebas son ms fciles de crear, porque los mdulos inferiores suelen tener funciones ms especficas, es ms fcil la observacin de los resultados de las pruebas, debido a que se elaboran en los mdulos inferiores, adems, se pueden resolver primero los errores de los mdulos inferiores que son los que tienen el procesamiento ms complejo, para luego nutrir de datos al resto del sistema. Entre sus principales desventajas se tiene que se requieren mdulos impulsores, que se deben desarrollar especialmente y que el sistema como entidad no existe hasta que se agregue el ltimo mdulo. Despus de conocer las estrategias de integracin y las ventajas y desventajas brindadas por ambas, se determin poner en prctica la integracin ascendente. En la Tabla 1 se muestra el diseo de casos de prueba para la integracin ascendente de cada uno de los mdulos del sistema bajo prueba.
Tabla 1. Diseo de casos de prueba de integracin
Nombre del Mdulo
Funcionalidad Condiciones de Ejecucin Escenario de interaccin Resultado Previsto Resultado Real

Basado en la tcnica de particiones equivalentes con modificaciones dadas por la experiencia en las pruebas. Definen plantillas basadas en casos de uso, requisitos o historias de usuario. Recoge todas las combinaciones de escenarios posibles a ejecutar. Contiene la descripcin de todas las variables o datos de entrada al sistema. Proporciona los juegos de datos para todas las combinaciones de variables. La base para realizar estos diseos son los requisitos del software, los casos de uso o las historias de usuario y dependen de la metodologa que se use para el desarrollo del software. Un buen diseo de un caso de prueba de caja negra depende de la informacin que brinde el caso de uso o requisito. En el caso de los equipos que por la metodologa de desarrollo o por otras razones diseen los casos de prueba basados en requisitos, se debe garantizar que sus especificaciones estn lo ms completas posibles, porque para los casos de pruebas es necesario identificar todos los escenarios posibles que se presentan en una descripcin de casos de uso pero, generalmente, estos aspectos no se llegan a identificar en los requisitos. La parte ms importante del caso de uso o requisito para generar los casos de prueba es el flujo de eventos. Las dos partes principales del flujo de eventos son el flujo bsico y los flujos alternativos. Un escenario de un caso de uso es un camino completo a travs del mismo. Los usuarios finales pueden seguir muchos caminos cuando ejecutan la funcionalidad especificada en el caso de uso. A continuacin se describe un proceso para generar los casos de prueba a partir de un caso de uso o requisito totalmente detallado: Generar un sistema completo de escenarios para cada caso del uso. Identificar por lo menos un caso de prueba y las condiciones que permiten su ejecucin para cada escenario. Identificar los valores de los datos con los cuales se har la prueba para cada caso de prueba. Adems de plasmar en el caso de prueba los escenarios presentes en la descripcin de requisitos o casos de uso, se deben tener presente otras consideraciones de escenarios que quizs falten en la descripcin, que el diseador de casos de prueba debe incluir en sus diseos: Datos de entrada en un determinado rango: se elabora un escenario que verifique el comportamiento del sistema cuando el dato toma un valor dentro del rango y dos escenarios ms, uno que valide el comportamiento del sistema ante un valor menor al intervalo y otro que valide el comportamiento ante un valor mayor a dicho intervalo.

Funcionalidades: identificar las del mdulo que dependen de los servicios que ofrece otro. Condiciones de ejecucin: deben estar creadas en el sistema antes de ejecutar la funcionalidad. Escenarios de interaccin: se identifican los posibles escenarios de interaccin de cada funcionalidad. Resultado previsto: se escribe el resultado que se espera al realizar la prueba. Resultado real: se escribe el resultado que se obtiene al realizar la prueba. 2.3 Herramientas definidas en el DPSW Para la realizacin de pruebas de funcin se propone la utilizacin de dos herramientas, los diseos de casos de prueba como herramienta manual y apoyo a la ejecucin de las pruebas y como herramienta automatizada el Selenium IDE para agilizar la ejecucin segn las caractersticas del sistema bajo prueba. Diseo de Casos de prueba de funcin Una herramienta necesaria para la ejecucin de las pruebas de funcin son los casos de prueba, los cuales especifican las entradas con datos de prueba, las condiciones de ejecucin y los resultados esperados. El DPSW define un diseo de casos de prueba con las siguientes caractersticas:

69

 Datos de entrada que cumplen una determinada regla del negocio: por ejemplo, cuando la edad de una persona para obtener el carnet de identidad no puede ser menor a 18 aos. En la Tabla 2 se muestra un diseo de caso de prueba para una determinada seccin de un caso de uso, donde las variables son los datos de entrada al sistema que toman valores vlidos (V), Invlidos (I) o No Aplica (NA), dependiendo del escenario, con sus respectivos valores reales.
Tabla 2. Diseo de Casos de Prueba de funcin
Escenario EC 1.n [Nombre del escenario] Descrip. [Descrip. del escenario de prueba] V1 V dato V dato V2 V dato V dato V3 V dato V dato Respuesta del sistema [Resultado que se espera al realizar la prueba] Flujo central [Pasos para probar la funcional idad]

Abrir la aplicacin a la cual se le van a realizar las pruebas y abrir el IDE. Habilitar el botn grabar y luego escribir la URL que se va a usar de base. Ejecutar la funcionalidad que se desea probar para que Selenium vaya registrando cada accin. Desactivar el botn grabar del IDE. La utilizacin del Selenium no debe sustituir el diseo de casos de prueba para realizar las pruebas de funcin manualmente y su puesta en prctica depende de la experiencia de los probadores y las condiciones en la que se ejecuta la prueba, adems de las caractersticas del sistema que se desea probar. 3. RAZONAMIENTO BASADO EN CASOS (RBC) El RBC es un proceso para solucionar nuevos problemas con base en las soluciones de problemas anteriores; pertenece al campo de la inteligencia artificial y bsicamente permite resolver un problema mediante el empleo de problemas resueltos similares al planteado. El RBC es una manera de razonar haciendo analogas, no slo es un mtodo poderoso para el razonamiento de computadores, sino que es usado por las personas para solucionar problemas cotidianos. Se puede concluir que todo razonamiento es basado en casos porque est basado en la experiencia previa. Por ejemplo, en la produccin de software, cuando un programador al que el sistema le muestra un error y por su experiencia va directo a donde est el problema y lo resuelve porque ya solucion uno similar anteriormente, est aplicando RBC. Esto tambin es aplicable en la calidad de software, para lograr la calidad requerida por los usuarios finales, se pueden realizar varias pruebas, una de las ms usadas son las pruebas funcionales o pruebas de funcin, como se explic anteriormente. Usar RBC no es ms que hacer propuestas para la planificacin y reutilizacin de pruebas funcionales. En la Figura 1 se muestra de forma general los pasos a seguir para usar el razonamiento basado en casos, donde almacenar informacin y solicitar su recuperacin son los principales pasos.

Entre los principales errores que se detectan aplicando pruebas de caja negra y el diseo de casos de prueba definido estn los siguientes [1]: Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a las bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin. Utilizando una herramienta para la automatizacin de este proceso se logra disminuir los costos en recursos y en tiempo destinados a su realizacin. Selenium IDE para automatizar las pruebas La generacin automtica de casos de prueba permite ahorrar recursos en todo el proceso y asegurando una mejor calidad. Selenium IDE puede ser utilizado en el desarrollo de pruebas de funcin, sobre todo si se trata de probar el funcionamiento de varios formularios varias veces seguidas. Las pruebas que realiza son como las que hara cualquier usuario desde un navegador, con la ventaja de que las hace mucho ms rpido y evita el trabajo repetitivo; con esta herramienta se pueden grabar acciones ejecutando un determinado escenario de un caso de prueba y reproducirlas cada vez que se necesiten, adems, la extensin tiene un modo de reproduccin paso a paso que puede ayudar a determinar la causa de un problema. A continuacin se describen algunas de sus caractersticas: Multiplataforma y software libre. Ejecucin en varios navegadores. Facilidad de registro y ejecucin de las pruebas. Las acciones se pueden ejecutar paso a paso. Las pruebas se pueden almacenar como HTML o scripts, entre otros formatos.

El trabajo con esta herramienta es sencillo, basta con instalarla y seguir los siguientes pasos:

Fig. 1: Pasos del RBC

70

La utilizacin del RBC para pruebas funcionales se puede realizar con base en las caractersticas particulares de cada proyecto. En el DPSW se aplica en las pruebas funcionales. El departamento recibe solicitudes de pruebas de varios centros de produccin de software, los cuales tienen en sus proyectos funciones semejantes entre s y, con base a esa semejanza, se almacena informacin para luego reutilizar. Se pueden abarcar los siguientes pasos: 1. Definir la caracterstica o sub-caracterstica por la cual se va a guiar el RBC. 2. En caso de ser por los requisitos, reducirlos informalmente de manera que se puedan comparar con otros. 3. En caso de ser por proyecto en general, el centro recupera la informacin necesaria. 4. Verificar si la informacin recuperada es aplicable y realizar el plan de pruebas funcionales. 5. Trabajar en las pruebas funcionales con base en dicha informacin. Es importante aclarar que en las pruebas funcionales no es necesario trabajar con toda la informacin recuperada sino con las ms priorizada, es decir, la que ms reiteracin tenga en la base de casos. Todo esto es necesario para poder aplicar un buen. Un ejemplo concreto para detectar No Conformidades de Validacin es la siguiente: Segn la Figura 1, existen dos momentos importantes: (a) almacenar informacin y (b) solicitar recuperacin de la informacin. El primer momento se divide en registro del proyecto y registro de resultados. Registro del Proyecto. Los parmetros a introducir dependen de las caractersticas de los proyectos: Nombre Centro: en caso de que ya se haya introducido anteriormente se selecciona. Nombre Proyecto e ID: nombre del proyecto y un identificador. Caractersticas: que distingan al proyecto y que puedan servir para compararlo con otro. Escoger Tipo: caso de uso, requisitos, historias de usuario u otro. Registrar cantidad y nombre. Escoger Acciones: de acuerdo con el tipo y la cantidad seleccionada se registra si es Adicionar, Modificar, Eliminar, Buscar, Reporte o Calcular. Escoger Opciones: son los tipos de No Conformidades que se encuentran en las pruebas funcionales: Validacin, Opciones que no funcionan, Excepciones o Funcionalidad. En esta investigacin slo se aborda la opcin Validacin. Existen dos formas de registrar esta informacin: 1. Seleccionar de cada Accin de campos que tiene y de cada campo los tipos de campos que existen. 2. Seleccionar de cada Accin los tipos de campos que tiene y por cada campo escoger la cantidad.

Los tipos de campos son: Campos obligados. Campos alfanumricos. Campos alfabtico. Campos numricos. Campos con caracteres especiales. Campos con nmeros enteros. Campos con una cantidad exacta de caracteres. Registro del resultado de la prueba. Luego de registrar el proyecto en la Base de Casos, se siguen los siguientes pasos: Buscar proyecto: utilizando el ID que lo identifica. Listar los casos de uso o requisitos o historias de usuario u otros. Listar las Acciones de cada tipo. Escoger la Opcin Validacin: En este caso especfico se ver slo Validacin. Listar cada campo introducido: este caso slo es vlido si escogi la opcin 1 anterior. De cada campo introducido listar el/los tipos de campos. De cada tipo de campo registrar el resultado de la prueba. La forma en que se registra la prueba consiste en seleccionar satisfactoria o insatisfactoria; para la primera no se tuvo No Conformidades y para la segunda lo contrario. De esta forma es ms fcil realizar las comparaciones pertinentes para seleccionar los posibles errores en proyectos con caractersticas semejantes. Solicitar Recuperacin de la informacin. Luego de registrar el proyecto, la base de casos debe ser capaz de realizar los pasos siguientes para devolver los posibles errores que puede tener ese proyecto: Comparar con el Tipo escogido anteriormente y escoger las Acciones y Opciones que ms semejanzas presentan, teniendo en cuenta una cantidad mnima de coincidencia. Devuelve los posibles errores, es decir, registrar el resultado de la prueba. 4. RESULTADOS OBTENIDOS Con la utilizacin de los casos de prueba se detectaron ms No Conformidades que con la utilizacin de cualquier otra herramienta. La mayora son de Funcionalidad, Validacin y Excepciones con un promedio de ms de 3.000 detectadas en los procesos de prueba, en un periodo de tiempo de dos aos. Esta estrategia permiti una mayor organizacin para la ejecucin de este tipo de pruebas. Se tiene ya una experiencia de ms de cinco aos con el uso de los diseos de casos de prueba propuestos, aunque se han ido refinando. La mayora de los proyectos en la universidad utilizan los diseos de casos de prueba para sus pruebas funcionales internas.

71

5. CONCLUSIONES La caracterstica de funcionalidad de la Norma ISO 9126 se puede garantizar mediante la realizacin de pruebas de funcin, las cuales tienen como objetivo verificar la correspondencia de los requisitos funcionales con lo implementado. Es necesario planificar, disear e implementar las pruebas de funcin definiendo la estrategia a seguir. La estrategia propuesta le ha permitido al DPSW una mayor organizacin para la ejecucin de este tipo de pruebas. La definicin de los casos de pruebas de funcin, junto con la utilizacin de una herramienta automatizada, permite abarcar todos los escenarios de prueba posibles

La utilizacin de RBC permite realizar las pruebas funcionales con base en las realizadas a proyectos similares. 6. REFERENCIAS
[1] Pressman, R. S. 2005. Ingeniera de Software: Un enfoque prctico. Flix Varela. [2] ISO/IEC. 2003. NC-ISO/IEC 9126-1. IEEE Press. [3] Pressman, R. S. 1998. Software Engineering. Mc Graw Hill.

72

Methodology to teach to assure the software quality through verification and validation techniques Metodologa para ensear a asegurar la calidad del software a travs de tcnicas de verificacin y validacin
Gabriela Salazar B.
Escuela de Ciencias de Computacin e Informtica. Universidad de Costa Rica, San Jos, Costa Rica. gabriela.salazar@ecci.ucr.ac.cr ABSTRACT INFORMACIN DEL ARTCULO The main objective of this article is to describe the experience of teaching the Tipo de artculo: Reflexin students of Software Engineering of the Bachelor Program in Informatics of the University of Costa Rica, to apply validation and verification software tests. The Historia del artculo purpose is to extend the software quality assurance culture, facilitating and Recibido: 30/04/2012 stimulating the use of worldwide methodologies in their future development as Correcciones: 06/06/2012 professionals; in order to support the national companies to improve their Aceptado: 10/06/2012 competitivity in international markets. Specifically, it describes the procedure in the execution of these tests, forms used, the software tools and the team members of the Palabras clave process. The points described in this article can be of interest for teachers and Verificacin, validacin, aseguramiento instructors who wish to develop software engineers in the area of software quality. de la calidad del software, revisin tcnica formal, pruebas. RESUMEN El objetivo principal de este artculo es describir la experiencia de ensear a los Categories and Subject Descriptors estudiantes del curso de Ingeniera de Software del Programa de Bachillerato en F.3.1 [Specifying and Verifying and Computacin e Informtica en la Universidad de Costa Rica, a aplicar pruebas de Reasoning about Programs] verificacin y validacin del software. El propsito es extender la cultura de aseguramiento de calidad del software, facilitando y estimulando el uso de General Terms metodologas de alcance mundial en los futuros profesionales, con el fin de apoyar a Verification, standardization. las empresas nacionales a mejorar la competitividad en mercados internacionales. Especficamente se describe el procedimiento en la ejecucin de estas pruebas, los Keywords formularios utilizados, las herramientas de software y los participantes del proceso. Verification, validation, software Los puntos descritos en este artculo pueden interesar a profesores e instructores quality assurance, formal technical que deseen formar a futuros ingenieros de software en el rea de calidad. review, testing.

1. INTRODUCCIN El aseguramiento de la calidad es en la actualidad uno de los tpicos de investigacin ms importantes dentro del rea de ingeniera de software. La baja calidad de los sistemas que se desarrollan es uno de los mayores contribuyentes a la llamada crisis del software actual. [21]. A nivel mundial existen mltiples metodologas, tcnicas y herramientas modernas de ingeniera de software que permiten mejorar la calidad de los productos de software desarrollados. Algunas de ellas son: el Programa de Certificacin de Pruebas de Software CSTE por sus siglas en ingls [19], los estndares de ingeniera de software del IEEE [10], el Modelo de Capacidad/Madurez CMM por sus siglas en ingls [16-20] y el estndar ISO 9001 [11]. Las instituciones y las empresas nacionales que desarrollan o adquieren software requieren un apoyo importante en el proceso de introducir metodologas de aseguramiento de la calidad del software. Estimular a los estudiantes en el uso de metodologas de alcance mundial les facilita su entrada al mercado laboral y se convierte en un apoyo importante para la industria desarrolladora de software del pas. En la prxima seccin se describe el marco terico de las metodologas que fueron aplicadas. En la seccin tres se describe brevemente el curso de Ingeniera de Software utilizado en esta experiencia. En la seccin

cuatro se explica cmo se aplicaron dichas metodologas y finalmente, en la seccin cinco, se describen las conclusiones. 2. MARCO TERICO 2.1 Aseguramiento de la Calidad del Software La ingeniera de software es la disciplina que desarrolla y utiliza metodologas, mtodos y herramientas para desarrollar software de buena calidad. Uno de los componentes claves de todo proceso de desarrollo de software, son las actividades que se llevan a cabo para asegurar la calidad del software que se produce. Este conjunto planeado y sistemtico de actividades que aseguran que el proceso y los productos cumplen con los requerimientos tcnicos establecidos, se conoce como Aseguramiento de la Calidad del Software ACS. Software de calidad es aquel en el concuerdan los requisitos funcionales y de rendimiento, explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se esperan de todo producto desarrollado profesionalmente [14-19]. De acuerdo con IEEE [7] un componente importante del ACS son las actividades de verificacin y validacin V&V del software, las cuales se realizan durante las diferentes fases que componen el ciclo de desarrollo de los sistemas. El proceso de V&V provee una evaluacin

73

objetiva de los productos y del proceso desarrollados durante el ciclo de vida del software. Esta evaluacin demuestra que los requerimientos del software y del sistema son correctos, completos, precisos, consistentes y fciles de probar. Otros objetivos de V&V son: Facilitar la deteccin y correccin temprana de errores. Mejorar la administracin del proceso y los riesgos del producto. Apoyar el proceso del ciclo de vida para asegurar el cumplimiento de los requerimientos de rendimiento, cronograma y presupuesto del programa. Este proceso proporciona evidencias de que el software y los productos asociados: Cumplen con los requerimientos en todas las actividades durante el proceso de desarrollo. Satisfacen los estndares, prcticas y convenciones durante el proceso de desarrollo. Establecen una base para evaluar cada actividad del ciclo de vida para iniciar la siguiente actividad. Una tcnica importante de V&V son las revisiones tcnicas formales, las cuales ayudan a Verificar y Validar los productos software que se desarrollan durante las diferentes fases del ciclo de vida del proyecto. Verificar la calidad en cada una de las fases de desarrollo, y no esperar hasta la fase de pruebas, reduce el esfuerzo y la duracin del ciclo de vida, porque lo que se persigue es disminuir los costos de prueba y de integracin y un menor nmero de cambios en las primeras versiones del producto. Adems, el proceso de revisiones, como parte de las actividades de aseguramiento de calidad, hace que se detecte y se elimine gran porcentaje de defectos en algunas organizaciones entre el 60% y el 90% [17-19]. 2.2 Pruebas del software De acuerdo con [4] las pruebas de software son un conjunto de actividades diseadas para evaluar la calidad de los productos desarrollados. Por otro lado Myers [14] define las pruebas del software como las actividades de planificar, disear, desarrollar, administrar y ejecutar pruebas, incluyendo adems a las actividades de Verificacin y Validacin. A continuacin se describen las actividades en un proceso de pruebas. Planificacin. Con base en la especificacin funcional y la informacin del proyecto se elabora un plan de pruebas que incluye: objetivos, estrategias, recursos, administracin de riesgos y cronograma. Algunos aspectos que se consideran dentro de la estrategia son: fase y tipo de prueba, tcnica, herramientas y criterios de completitud. Diseo. Se refina la estrategia de pruebas definida, se definen procedimientos de pruebas y se especifican los casos de prueba y los criterios de aceptacin. Los procedimientos se especifican con sus correspondientes

referencias a scripts si fuera necesario y a los casos de pruebas ya definidos. Desarrollo. Se crean o adquieren pruebas automatizadas y se prepara el ambiente de acuerdo con las condiciones planificadas en cuanto a hardware, software, espacio de laboratorio y recursos humanos. Lo ideal es automatizar las pruebas para poderlas reutilizar y mantener un rastreo de ellas y de la validacin de requerimientos. Ejecucin. Se ejecutan las pruebas y se registran los hallazgos; posteriormente se prepara una bitcora de pruebas y un reporte de defectos. Evaluacin de resultados. Se revisan los reportes y se genera un resumen de mtricas, de cobertura de pruebas y de anlisis de defectos. 2.3 Niveles de pruebas [19] El ciclo de vida del proceso de prueba involucra pruebas continuas al sistema, las cuales se realizan en paralelo con el proceso de desarrollo. Por ejemplo, mientras el equipo de desarrollo especifica los requerimientos el de pruebas planifica las pruebas con base en los mismos. Durante el proceso de desarrollo, en puntos predeterminados, se inspeccionan los resultados para determinar su correctitud. Refirase a la Figura 1.
Necesidades operativas
Verificar necesid.operativas

Validar

Pruebas de aceptacin

Validar necesid. operativas

Definicin de requerimientos

Verificar requerimientos

Validar

Pruebas del sistema

Validar requerimientos

Ejecucin Pruebas (Esttica)

Diseo del sistema Verificar diseo

Validar

Pruebas de integracin

Validar diseo

Validar
Construccin del sistema Verificar construccin Pruebas Unitarias

Ejecucin Pruebas (Dinmica)

Validar construccin

Fig. 1: El concepto de pruebas de software en V

En la Figura 1 se puede observar tambin que, desde el inicio del desarrollo, se aplican pruebas estticas sobre los entregables y, una vez el cdigo se encuentra en un estado ejecutable, se realizan pruebas dinmicas para verificar que los requerimientos especificados se estn alcanzando. La secuencia en que ocurren las pruebas est representada por los siguientes tipos: (a) de verificacin, (b) unitarias, (c) de integracin, (d) del sistema y (e) de aceptacin. Pruebas de verificacin. Son pruebas estticas sobre entregables intermedios, que se producen durante el ciclo de vida del proyecto. Aseguran que el sistema cumpla con los estndares y procesos de la organizacin. Utilizan tcnicas como revisiones, caminatas o inspecciones, que no requieren ejecutar el cdigo.

74

Pruebas unitarias. Consisten en probar piezas de software pequeas y a nivel de secciones, procedimientos, funciones y mdulos. Se utilizan para asegurar el correcto funcionamiento de secciones de cdigo, mucho ms reducidas que el conjunto y que tienen funciones concretas con cierto grado de independencia. Utilizan tcnicas que ejercitan rutas especficas, en una estructura de control de componentes, para asegurar una cobertura completa y la mxima deteccin de errores. Pruebas de integracin. Se realizan una vez que las pruebas unitarias concluyen exitosamente. Su objetivo es asegurar que el sistema completo, incluyendo a los sub-sistemas que componen las piezas individuales grandes del software, funcione correctamente al operar e inter-operar en conjunto. Se utilizan las tcnicas de diseo de casos de pruebas que se enfocan en entradas y salidas, aunque tambin se pueden aplicar tcnicas que ejerciten rutas de programas especficos para asegurar la cobertura de las principales rutas de control. Pruebas de regresin. Se enfoca en una nueva ejecucin de algn subconjunto de pruebas que ya se ha realizado, con el fin de asegurar que los cambios no propagaron efectos colaterales no deseados en otras partes del programa. Pruebas del sistema. Permite validar que el producto final cumple con los requerimientos establecidos por el cliente en lo funcional, comportamiento y rendimiento. Una especificacin documentada de los requerimientos del software proporciona la base para el proceso de validacin. Pruebas de aceptacin. Estas pruebas las realiza el cliente y bsicamente son pruebas funcionales sobre el sistema completo con las que se busca una cobertura a la especificacin de requerimientos y al manual del usuario. Estas pruebas no se realizan durante el desarrollo, sino una vez pasadas las pruebas de integracin por parte del desarrollador. 3. DESCRIPCIN DEL CURSO En el Programa de Bachillerato de Computacin e Informtica en la Universidad de Costa Rica la Ingeniera de Software se imparte a travs de dos cursos y sus respectivos laboratorios. Refirase a la Figura 2.
CI-1330 4 CI-1331 1 Sexto semestre

Los cursos son semestrales, uno es requisito del otro y cada uno tiene una duracin aproximada de 16 semanas lectivas. Especficamente, son cursos tericos donde se trabajan metodologas, tcnicas y herramientas de Ingeniera de Software. Se imparten en cuatro horas lectivas semanales y con un peso de cuatro crditos cada uno. Por otro lado, en los cursos de laboratorio los estudiantes aplican los conocimientos tericos; se ofrecen en dos horas lectivas semanales y con un peso de un crdito cada uno. Durante los dos semestres que dura el curso los estudiantes desarrollan una aplicacin, comenzando de una pequea especificacin. Al inicio del ao reciben una definicin bsica de los requerimientos, la cual deben completar y mejorar a travs de entrevistas y otras tcnicas, como construccin de programas usando prototipos. Esto hace que cada proyecto, aunque parta de una misma definicin, vare tanto en el diseo de las interfaces de entrada y salida como a nivel de estructuras de datos. El objetivo es fomentar su creatividad pero con ciertas restricciones, lo cual produce variaciones en el tamao de las aplicaciones de acuerdo con el equipo que la desarrolla. Las caractersticas de los proyectos son muy similares: el mismo problema a resolver, en plataforma operativa Microsoft .NET, lenguaje de programacin ASP.NET y C#, sistema administrador de base de datos SQL Server, herramienta de anlisis y diseo para el modelado UML Rational Rose o StarUML, herramienta para administrar el proyecto Microsoft Project y para administrar las versiones de software Subversion. Como metodologa de desarrollo aplican el Proceso Unificado Racional RUP por sus siglas en ingls, combinado con prcticas de metodologas giles como Extreme Programming y Scrum. El enfoque de administracin iterativa de este ltimo permite organizar el desarrollo del proyecto a travs de pequeas iteraciones y con una duracin de entre cuatro y seis semanas, distribuidas en los dos semestres que dura el curso. El uso de RUP durante el desarrollo asegura que en cada iteracin se siguen prcticas de calidad en cada fase. La aplicacin de XP mejora la construccin de los componentes, garantizando el cumplimiento de los requerimientos y la satisfaccin del usuario. Cada una de cinco fases genricas del RUP es guiada por un estndar adaptado a las caractersticas del curso, pero siguiendo las prcticas internacionales recomendadas por el IEEE [10] y por PMBOK Guide [18]. En la Tabla 1 se presentan las guas que utilizan los estudiantes para el desarrollo, el estndar internacional que se us para disearlas y la fase en que se aplica. Cada una de las guas cuenta con su propia plantilla en formato electrnico para facilitar el proceso de documentacin.

Ingeniera de Laboratorio Software I Ingeniera de Software I

CI-1430

CI-1431

1 Stimo semestre

Ingeniera de Software II

Laboratorio Ingeniera de Software II

Fig. 2: La IS en el Programa de estudios

75

Tabla 1. Plantillas de desarrollo

Nombre de la plantilla Gua para elaborar la Descripcin Conceptual del Proyecto. Elaborada con base en [18]. Gua para elaborar planes de administracin de proyectos de software. Elaborado con base en [1-10]. Gua para especificar los requerimientos del software. Elaborado con base en [6]. Gua para especificar el diseo del software. Elaborado con base en [4]. Las guas de la fase de pruebas son las indicadas en la seccin 4.2.2 y fueron elaboradas con base en [5-9]. Fase en la que se aplica Comunicacin Planificacin Anlisis Diseo Pruebas

4. PROCESO DE APLICACIN DE LAS TCNICAS 4.1 Pruebas de verificacin Participantes. Los roles de los estudiantes en las revisiones tcnicas formales son los siguientes: Equipo de revisin. Encargado de aplicar las revisiones a otros equipos con el objetivo de validar el cumplimiento del proceso de calidad definido. Representa al grupo de calidad de una organizacin. Uno de los miembros debe asumir el rol de lder. Representante del equipo revisado. Representa al equipo encargado de evacuar las consultas de los revisores y no debe justificar o defender los defectos. Documentos utilizados. El equipo de revisin debe contar como mnimo con la siguiente informacin: Enunciado de objetivos de la revisin.

Especificacin del elemento del software que se evaluar. Elemento del software a revisar. Planes, estndares o guas que servirn para revisar el elemento software. Listas de verificacin o cotejo para asegurar que el elemento software cumple con los requerimientos mnimos. Procedimiento. Las reuniones para realizar este tipo de revisin se llevan a cabo cuando as lo establezca el calendario del curso o cuando se determine adecuada la revisin del elemento software por su disponibilidad. El procedimiento a seguir se presenta en la Tabla 2. Al finalizar la revisin, el profesor evala los resultados para asegurar su correctitud y para evaluar al equipo revisor. Una vez que los autores revisan y corrigen el producto, atendiendo las recomendaciones, el profesor realiza una evaluacin al producto ya corregido.

Tabla 2. Procedimiento para llevar a cabo una revisin tcnica formal

Pasos 1. Planificacin 2. Vistazo (opcional) 3. Preparacin Descripcin Lder verifica los criterios de entrada, establece el calendario, identifica y convoca al equipo de revisores y reparte los materiales. Si el lder lo considera necesario, convoca a los participantes a una reunin breve en una fecha y hora especfica. Cada revisor estudia el material en forma individual. Durante la revisin el equipo realiza lo siguiente: 1. Revisar el elemento de software contra estndares y guas. 2. Discutir las alternativas o recomendaciones en pro del mejoramiento del elemento de software. 3. Asignar responsabilidades para la solucin de problemas encontrados en el elemento de software. Esta responsabilidad puede asignarse al autor o a otros integrantes del proyecto. (Debe hacerse por medio del lder). 4. Documentar los aspectos tcnicos, las recomendaciones y al responsable de resolverlos. 5. Cuando los defectos son numerosos o crticos, el lder debe recomendar un proceso de revisin adicional (retrabajo). Autor revisa y corrige el producto atendiendo la lista de recomendaciones. Lder comprueba la solucin de los problemas realizados por el autor y otros responsables, adems de determinar si se necesita realizar otra revisin.

4. Reunin

5. Re-trabajo 6. Seguimiento

4.2 Pruebas de validacin Participantes del proceso de pruebas. Los roles de los estudiantes en el proceso de pruebas son los siguientes: Lder de pruebas. Es el responsable del proceso y de su planificacin, pero tambin participa del diseo y ejecucin de las pruebas, aunque en menor medida. Encargados de pruebas. El resto de miembros. Documentos utilizados. Las plantillas para soportar el proceso de pruebas, suministradas en el curso, fueron diseadas con base en [5-9]: Plan de pruebas. Permite registrar la planificacin del plan de pruebas y contiene el resumen de los elementos y caractersticas que se probarn y las que no se probarn, la estrategia de pruebas, el ambiente

de pruebas, los roles y responsabilidades de los grupos encargados de las pruebas y el cronograma del proyecto de pruebas. Diseo de pruebas. Tiene dos partes: (a) especificar la estrategia de pruebas y (b) registrar los resultados de las pruebas despus de ejecutadas. En la primera parte del formulario se registra informacin como: el propsito de la prueba, el tipo, las herramientas, los procedimientos, los datos de entrada y los criterios de aceptacin. En la segunda parte se registran las No Conformidades NC con su correspondiente descripcin, el estado de la prueba, el responsable, la fecha de ejecucin y las incidencias encontradas. Casos de prueba. Algunos campos de este formulario son: los datos de entrada, el resultado esperado y el flujo, que corresponde a la secuencia

76

de pasos para probar la funcionalidad y una descripcin de las variables que se referencian en el caso de prueba. Reporte de No Conformidades. Permite registrarlas por su tipo y descripcin, por su ubicacin, clasificacin de importancia, historial, respuesta del equipo de desarrollo y el responsable. Reporte de mtricas. Permite registrar las mtricas obtenidas en el proceso de pruebas y calcular los indicadores de mtricas. Las mtricas que se obtienen son: densidad de fallas, cobertura de pruebas e ndice de fallas por tipo. Herramientas de pruebas Selenium. Es una suite de herramientas de cdigo abierto que se distribuye bajo la licencia Apache License 2.0. Est compuesta por tres herramientas de funcionamiento independiente: Selenium IDE, Selenium RC y Selenium Grid. Para esta investigacin se utilizaron las dos primeras. Selenium IDE. Funciona como un complemento del navegador Mozilla Firefox y, gracias a esta simbiosis, permite grabar toda interaccin del usuario con un sitio Web, en scripts de casos de prueba que luego pueden ser reproducidos. Selenium RC. Adems de proveer la capacidad de ejecutar casos de prueba producidos por Selenium IDE, no slo en Mozilla sino en otros navegadores libres, permite enriquecer las pruebas al traducir los casos de prueba a varios lenguajes de alto nivel. NUnit. Es una herramienta para la ejecucin de pruebas de unidad, especficamente en aplicaciones desarrolladas en alguno de los lenguajes de programacin del framework de Microsoft .NET, como Visual Basic, C++, C# y F#. Procedimiento. En cada ciclo de pruebas funcionales se realiza el siguiente procedimiento: 1. Planificacin. Antes de realizar las actividades de validacin de requerimientos funcionales, el lder de pruebas verifica la disponibilidad de los elementos de prueba y de la documentacin correspondiente y planifica las pruebas junto con el resto de los miembros del equipo. En esta fase se utiliza el formulario Plan de Pruebas. 2. Diseo de las pruebas. El encargado de pruebas, de cada funcionalidad o mdulo, disea el proceso de pruebas y utiliza los formularios de diseo de pruebas y casos de prueba. Una vez completados ambos documentos el lder de pruebas los enva, junto con el plan de pruebas, al profesor del curso para su revisin. En caso de que los documentos necesiten correcciones, el profesor se lo regresa al lder de pruebas para que se realicen las correcciones correspondientes.

3. Desarrollo del ambiente de pruebas. El encargado de pruebas debe crear las pruebas automatizadas para la funcionalidad que le fue asignada. En el curso ejecutan pruebas unitarias con NUnit y las integran con Selenium IDE para realizar pruebas funcionales. Posteriormente prepara el ambiente: espacio fsico, hardware, software. Si las condiciones no fueran ptimas el lder de pruebas informa al asistente del curso para que se corrija el problema. Esta informacin se actualiza en el plan de pruebas. 4. Ejecucin de las pruebas. El encargado de pruebas procede a ejecutarlas de acuerdo con el diseo de y durante la ejecucin registra los resultados en el formulario diseo de pruebas, incluyendo la imagen que comprueba las NC. 5. Elaboracin de reportes de las pruebas. Cuando concluye el proceso de pruebas se completan los formularios del reporte de no-conformidades y el de mtricas. Este trabajo lo realiza todo el equipo. 6. Evaluacin de las pruebas. Posteriormente, el lder de pruebas, junto con todos los integrantes del equipo, revisa los resultados del ciclo actual de pruebas y emite observaciones para que se corrijan los defectos y se repita el proceso en un nuevo ciclo, o se d por concluido. Si requieren un nuevo ciclo de pruebas se debe revisar y actualizar la documentacin correspondiente para la nueva ejecucin. Si se da por concluido se crea el informe final para entregar los resultados al profesor. Al finalizar los tres ciclos el profesor, con el apoyo del asistente del curso, evala los resultados para asegurar que efectivamente se cumplen los requerimientos establecidos y para analizar los defectos y las mtricas reportados.
Documentos de entrada al proceso de pruebas 1. Planificacin 2. Diseo de pruebas 3. Desarrollo del ambiente de pruebas

De 2 a 3 ciclos de pruebas

4. Ejecucin de pruebas 5. Elaboracin de reportes 6. Evaluacin de resultados

Elemento de software con errores

Elemento de software probado

Fig. 3: Procedimiento de pruebas

5. ANALISIS DE RESULTADOS Durante el ao 2010 a los estudiantes se les asign como proyecto del curso el desarrollo de un sistema web en una arquitectura 4 capas que permitiera administrar los requerimientos de un proyecto de software. Dentro de las funcionalidades solicitadas estn las siguientes:

77

 Administrar la informacin bsica del recurso humano que tiene acceso al sistema: administrador, cliente, desarrollador. Administrar la seguridad de la aplicacin, restringiendo el acceso a la informacin de acuerdo con rol del usuario. Administrar la informacin bsica de un proyecto, permitiendo adems crear para cada proyecto el equipo de trabajo. Administrar los requerimientos funcionales y nofuncionales para un determinado proyecto. Administrar, para cada requerimiento, las dependencias y los conflictos asociados. Administrar los cambios realizados al requerimiento quin, cundo, qu y por qu y, a partir de una lnea base, controlar las versiones para facilitar el manejo de su historial sin borrar las anteriores. Administrar el material de apoyo casos de uso, casos de prueba, entre otros asociado a los requerimientos de un determinado proyecto, de manera que permita el acceso a los archivos electrnicos correspondientes. Administrar el proceso de verificacin y validacin de la calidad de los entregables del proyecto. Realizar consultas, por ejemplo, un rbol jerrquico que muestre todos los proyectos con sus correspondientes requerimientos ordenados por prioridad y por estado.

En este caso de estudio participaron cuatro equipos de trabajo desarrollando la misma aplicacin. Al finalizar el se ejecutaron tres ciclos de pruebas funcionales para validar el cumplimiento de los requerimientos solicitados. El primero y el tercer ciclo de pruebas lo ejecutaron los mismos autores o desarrolladores de la aplicacin a evaluar; el segundo corresponde a una RTF en la que un equipo externo evala en forma objetiva una aplicacin que no es la suya y es representado por otro equipo de trabajo, elegido por el profesor de entre los mismos estudiantes del curso. Durante la ejecucin de los tres ciclos los estudiantes recolectan medidas para estimar la densidad de fallas, la cobertura de pruebas por clases y por requisitos e ndice de fallas por tipo. A continuacin se analizan los resultados de las tres mtricas recogidas. 5.1 Mtrica de densidad de fallas En la Tabla 3 se muestran los resultados obtenidos por los equipos de trabajo del caso de estudio. En la primera columna se identifica el equipo de trabajo, en la segunda la cantidad de lneas de cdigo implementadas de la aplicacin (LDC), en la tercera, la cuarta y la quinta el nmero de fallas detectado en los tres ciclos de pruebas correspondientemente y en la sexta, sptima y octava la densidad calculada en los tres ciclos de pruebas.

Tabla 3. Densidad de pruebas

Equipos de Fallas ciclo trabajo KLDC pruebas 1 Equipo 1 Equipo 2 Equipo 3 Equipo 4 12215 7567 11230 10654 10 38 89 5 Fallas ciclo pruebas 2 35 65 134 29 Fallas ciclo Densidad ciclo Densidad ciclo pruebas 3 pruebas 1 pruebas 2 25 40 97 1 0.000818666 0.008751727 0.0079252 0.000469307 0.00286533 0.01497006 0.011932324 0.002721982 Densidad ciclo pruebas 3 0.002046664 0.009212345 0.008637578 9.38615E-05

En la Tabla 3 se observa que el ciclo 2 es donde se obtiene una mayor densidad de fallas, lo que permite afirmar que cuando las pruebas las realiza un equipo de trabajo, diferente al que desarroll la aplicacin, se logra detectar un mayor nmero de fallas. Esto se evidenci en los cuatro equipos de desarrollo. En la Figura 4 se muestra el resultado de las densidades obtenidas para los cuatro equipos. Los equipos 1 y 4 lograron una mejor densidad de fallas.
Grfico de Densidades
0.016 0.014 0.012

slo un equipo dej de probar una de las clases programadas, logrando un 96% de cobertura, el resto tuvo un 100%. En cuanto a la cobertura de requisitos de los 25 establecidos al inicio del curso, slo un equipo cumpli con lo solicitado, el resto obtuvo entre un 89,5% y un 96,5% de cobertura.
Tabla 4. Cobertura de pruebas
Equipos de Clases trabajo probadas Equipo 1 Equipo 2 Equipo 3 Equipo 4 25 20 29 26 Total clases 26 20 29 26 Cobertura clases 96% 100% 100% 100% Requisitos probados 17 17 23 25 Total Cobertura requisitos requisitos 25 25 25 25 96.2% 89.5% 92.0% 100.0%

Densidad de Fallas

0.01 0.008 0.006 0.004 0.002 0 Fallas ciclo pruebas 1 Fallas ciclo pruebas 2 Fallas ciclo pruebas 3

Equipo 1 Equipo 2 Equipo 3 Equipo 4

5.3 Distribucin de ndice de NC por tipo En la Tabla 5 se presentan los resultados de distribucin de las NC por tipo, acumuladas por los 4 equipos de trabajo y recogidas durante los tres ciclos de pruebas. Las NC fueron clasificadas de acuerdo con las categoras: 1. Funcionalidad. Al realizar una accin determinada el resultado que se muestra no es el esperado. 2. Validacin. Existen errores relativos a la falta de validacin.

Fig. 4: Grfico de densidades

5.2 Cobertura de la prueba En la Tabla 4 se presentan los resultados de la cobertura. Se recogieron medidas para dos tipos de mtricas: la de clases y la de requisitos. En la de clases

78

3. Opciones que no funcionan. Al realizar una accin determinada no se muestra resultado alguno. 4. Usabilidad. Se encuentran inconformidades de efecto visual provocadas por las interfaces de las aplicaciones: de formato, de visibilidad, de navegabilidad, de correspondencia de etiquetas o ttulos mostrados con reales. 5. Excepciones. El sistema muestra un mensaje sealando que ha ocurrido un error inesperado o que no ha sido tratado. 6. No correspondencia de lo implementado con lo documentad. Incumplimiento de la correspondencia que debe existir entre una aplicacin informtica y lo que est documentado al respecto.
Tabla 5. Distribucin de NC por tipo
Opciones Implementado no que no corresponde con lo Tipos de Fallas Funcionales Validacin funcionan Usabilidad Excepciones especificado Equipo 1 28 38 4 20 0 0 Equipo 2 40 36 6 30 16 0 Equipo 3 67 22 133 33 16 15 Equipo 4 19 6 0 30 0 4 Total 154 102 143 113 32 19 Distribucin porcentual 37% 24% 27% 8% 5%

Un aspecto que hay que considerar en el proceso de adopcin de estndares para el curso es la necesidad de revisar las exigencias de los estndares IEEE, porque son muy especficos y detallados en algunos puntos, lo que los vuelve poco prcticos y difciles de implementar. Por esto es necesario analizar con cuidado el estndar en forma general y posteriormente hacer una seleccin de las partes ms relevantes para el curso. La experiencia de utilizar estndares internacionales en forma sistemtica brinda diversos beneficios: Mejora la calidad de los productos que desarrollan los estudiantes. Capacita y disciplina a los estudiantes en buenas prcticas. Proveen una excelente regla para medir la calidad de los entregables implementados en las diferentes fases del ciclo de vida. Las revisiones tcnicas realizadas entre equipos de trabajo resultan muy productivas: El equipo revisor acta con tal rigurosidad y objetividad que detecta errores que generalmente el equipo revisado no encuentra. La retroalimentacin que recibe el equipo revisado le permite obtener un producto final ms depurado y de mayor calidad. Comparten experiencias, aprenden y/o aclaran aspectos tcnicos que no haban considerado en sus proyectos o que no tenan claros. Impartir el curso de esta manera no es una tarea fcil, porque abarca una amplia variedad de temas de Ingeniera de Software, sin embargo, en general los estudiantes manifiestan mucho inters y satisfaccin al aprender y trabajar de forma prctica. Las mtricas recogidas durante el proceso de prueba permiten conocer el estado del mismo y mejorar las deficiencias encontradas. 7. RECONOCIMIENTO Los autores agradecen a los estudiantes del curso de Ingeniera de Software del ao 2011 su colaboracin en esta labor de investigacin, porque su trabajo permiti probar estas metodologas. 8. REFERENCIAS
[1] IEEE Computer Society. 1987. ANSI/IEEE Std. 1058.11987, IEEE Standard for Software Project Management Plans. [2] IEEE Computer Society. 1988. IEEE Std 982.1-1988 Standard Dictionary of Measures to Produce Reliable Software. [3] IEEE Computer Society. 1990. IEEE Std 610.12.1990 Standard Glossary of Software Engineering Terminology. [4] IEEE Computer Society. 1993. Std. 1016.1-1993 IEEE Guide to Software Design Descriptions Description. [5] IEEE Computer Society. 1998. IEEE Std 982.1-1988 Standard Dictionary of Measures to Produce Reliable Software.

En la Figura 5 se muestra que el 37% de las NC ocurre por funcionalidades incorrectas, el 27% por falta de usabilidad del software y el 24% por una dbil validacin de las interfaces. No se graficaron las NC del tipo opciones que no funcionan porque de los 143 NC de este tipo, 133 correspondan solamente un equipo de trabajo que entreg la aplicacin incompleta.
Distribucin de NC de acuerdo al tipo
Funcionales 4% 8% Validacin

37%

Opciones que no funcionan Usabilidad

27%

Excepciones

24%

Implementado no corresponde con lo especificado

Fig. 5: Grfico de NC por tipo

6. CONCLUSIONES Con la metodologa propuesta se pueden concluir: La enseanza de tcnicas de aseguramiento de calidad de software es un rea que no debera omitirse en los cursos de Ingeniera de Software, debido a que las empresas desarrolladoras requieren calidad en sus productos para competir en mercados internacionales. Una forma de apoyarlas es introducir al mercado laboral profesionales preparados en esta materia. La metodologa utilizada fue positiva porque los estudiantes aprendieron conceptos tericos de aseguramiento de la calidad del software mediante un enfoque muy prctico.

79

[6] IEEE Computer Society. 1998. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications Description. [7] IEEE Computer Society. 1998. IEEE Std 1012.1998. Standard for Software Verification and Validation. [8] IEEE Computer Society. 1998. IEEE Std 1061-1998 Standard for a Software Quality Metrics Methodology, (Revision of IEEE Std 1061-1992). [9] IEEE Computer Society. 1998. IEEE Std 829.1998 Standard for Software Test Documentation. [10] IEEE. 2003. IEEE Standards Collection: Software Engineering. IEEE Inc. 2003. ISBN: 978-0738137575. [11] ISO. 1991. ISO 9000-3 Guidelines for the Application of ISO 9001 to the Development, Supply, and Maintenance of Software. ASQC Press. [12] Kaner, C.; Falk, J. & Nguyen, H.1999. Testing Computer Software. Wiley, second edition, USA. [13] Kaner, C., Bach, J. & Bred, P. 2002. Lessons Learned in Software Testing. Wiley, USA.

[14] Lewis, W. 2009. Software Testing and Continous Quality Improvement. 3rd ed, CRC Press. [15] Myers, G. 1979. The Art of Software Testing. WileyInterscience. [16] Paulk, M.; et al. 1995. The Capability Maturity Model: Guidelines for Improving the Software Process. AddisonWesley. [17] Pressman, R. 2010. Ingeniera de Software: Un enfoque prctico. Sptima edicin, McGraw-Hill. [18] Project Management Institute. 2005. Guide to the Project Management Body of Knowledge (PMBOK Guide). [19] Quality Assurance Institute. 2006. CSTE Common Body of Knowledge. V6.2. [20] SEI. Software Engineering Institute. 2006. CMMI for Development (CMMI-DEV), Versin 1.2 Technical report CMU/ SEI-2006-TR-008. Pittsburg, PA: Software Engineering Institute, Carnegie Melon University. [21] Yourdon, E. 1993. Decline and Fall of the American Programmer. Yourdon Press.

80

Redmine and Subversion integration in the for software projects

construction

of

a test platform

Integracin de Redmine y Subversion en la construccin de una plataforma para la prueba de proyectos software
1 CITIC, Universidad 2

Guillermo E. Murillo G.1, Gabriela Salazar B.2

de Costa Rica, Alajuela, Costa Rica. guillermo.murillogoussen@ucr.ac.cr CITIC, Universidad de Costa Rica, San Jos, Costa Rica. gabriela.salazar@ucr.ac.cr ABSTRACT During the last decade, universities, state institutions and representatives of industry have interacted to contribute to improving the quality of software produced in Costa Rica. This year was established at the University of Costa Rica, the Research Center on Information Technology and Communication (CITIC). Within its structure is proposed to constitute research units, and one of them is the Software Quality Assurance Laboratory (LACSOFT) that is in process of creation and for which there are tools under development to support the management of administrative processes. This article describes the results of an investigation of free software tools Redmine and Subversion that, integrated, could be incorporated into LACSOFT, to facilitate the management of their projects software verification and validation. RESUMEN Durante la ltima dcada, las universidades, las instituciones del estado y los representantes de la industria han interactuado para contribuir al mejoramiento de la calidad del software producido en Costa Rica [1]. Este ao se cre en la Universidad de Costa Rica (UCR) el Centro de Investigaciones en Tecnologas de la Informacin y Comunicacin (CITIC). Dentro de su estructura se propuso constituir Unidades de Investigacin, y una de ellas es el Laboratorio de Aseguramiento de la Calidad del Software (LACSOFT) que est en proceso de creacin y para la cual se trabaja en la definicin de herramientas que permita dar soporte a la gestin de sus procesos administrativos [2]. Este artculo describe los resultados de una investigacin de dos herramientas de software libre (Redmine y Subversion) que integradas, pudieran ser incorporadas en LACSFOT para facilitar la administracin de sus proyectos de verificacin y validacin de software.

INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo Recibido: 30/03/2012 Correcciones: 19/06/2012 Aceptado: 30/06/2012 Palabras clave Redmine, Subversion, administracin de proyectos, pruebas de software. Categories and Subject Descriptors D.2.4 [Software/Program Verification]: Validation. General Terms Management, design, experimentation, standardization, verification. Keywords Redmine, subversion, management, software testing. project

1. INTRODUCCIN Hoy da poseer una administracin efectiva de la informacin es un elemento crtico para el xito de cualquier proyecto. La creciente dependencia de la informacin y los sistemas que la proporcionan han convertido a los sistemas de informacin en activos muy valiosos dentro de las empresas. Sin embargo, se ha vuelto comn en el desarrollo de software, proyectos que no concluyen a tiempo, que exceden su presupuesto, que se abandonan, o que concluyen y no se utilizan por no satisfacer las expectativas del usuario. Destinar esfuerzos en pro del mejoramiento de la calidad del software producido, ha sido en la ltima dcada, comn denominador entre la industria y la academia. Se espera que uno de estos puntos de confluencia sea LACSOFT, laboratorio creado con el propsito de: desarrollar y extender la cultura del aseguramiento de la calidad del software, as como promover, facilitar y estimular el uso de metodologas de alcance mundial o regional para mejorar la competitividad de las empresas. Para lograrlo, LACSOFT trata temas de investigacin bsica y aplicada relacionados con la mejora y la certificacin de la calidad de procesos, productos y proyectos que realiza

una organizacin, considerando las pruebas funcionales del software como el primer servicio que brindar. Por otro lado, LACSOFT como institucin universitaria tiene la responsabilidad de asegurar un mbito adecuado, i.e. un laboratorio bien equipado, para la prctica profesional necesaria en carreras tanto de grado como de posgrado, de manera que los egresados contribuyan de forma inmediata al crecimiento productivo, econmico y social basados en nuevas tecnologas desarrolladas con calidad. Uno de los componentes claves de todo proceso de desarrollo de software es el Aseguramiento de la Calidad y las actividades de verificacin y validacin (V&V) se realizan durante las diferentes fases que del ciclo de vida de los sistemas. Los objetivos principales del proceso de V&V son: verificar la calidad de los productos obtenidos en cada fase del ciclo de vida y validar que el producto final cumpla con los requerimientos del software establecidos. Buscando garantizar la calidad del software es que han surgido distintas herramientas y aplicaciones, utilizables a lo largo del ciclo de vida del proyecto. Redmine es una de ellas y fue seleccionada para esta investigacin debido a sus buenas referencias y sobre

81

todo a la experiencia positiva que ha tenido la Universidad de Costa Rica al utilizarla. En la siguiente seccin se describen brevemente las caractersticas que hicieron de Redmine, herramienta candidata para la investigacin. Posteriormente se mencionan algunas de las ventajas de utilizar Subversion como manejador de versiones de un proyecto. Posteriormente se explica cmo se configur Redmine para funcionar como plataforma de pruebas de software. Se especifican tambin los complementos instalados para incrementar la funcionalidad de Redmine y cmo se logr su integracin con Subversion. Adicionalmente se describe la experiencia al poner a prueba la plataforma, con estudiantes del curso de Ingeniera de Software, en un proceso de validacin de requerimientos funcionales, simulando un ambiente real de trabajo. Finalmente, se exponen los problemas encontrados y las conclusiones obtenidas. 2. MARCO TERICO 2.1 Redmine Es una herramienta web dedicada a la administracin de proyectos y al seguimiento de errores, desarrollada con el framework Ruby on Rails. Para su instalacin se requiere poseer en el servidor web: Ruby, un gestor de bases de datos (MySQL, PostgreSQL), Rack y Ruby on Rails. Es una herramienta multiplataforma, a nivel de cliente slo requiere una conexin a la red y un navegador web para comenzar a utilizarla. Redmine es gratuito, puede descargarse desde el sitio oficial www.redmine.org (el ltimo release estable, versin 1.2.1, fue lanzado el 11 de julio del 2011) y se distribuye bajo la licencia General Public License GNU [3]. La principal caracterstica que convirti a Redmine en una herramienta atractiva para la presente investigacin es su enorme flexibilidad. Si bien es cierto, la aplicacin fue pensada para el mbito empresarial, su facilidad de configuracin permite utilizarla en la administracin de cualquier proyecto, independientemente del rea en la que se desarrolle. Adems, la coordinacin de tareas, comunicacin entre los participantes y la integracin con sistemas de versiones, terminan por inclinar la balanza al comparrsele con otras herramientas para la gestin de proyectos [4]. Especficamente para la administracin de proyectos, result beneficioso para esta investigacin, el hecho de que Redmine permite que cada proyecto posea una configuracin propia. Es posible activar o desactivar los mdulos para noticias, peticiones, control del tiempo, documentos, y adems agregarles campos personalizados (de variedad de formatos: texto, lista, numrico, fecha) que le confieren una identidad propia a cada proyecto. Adems un mismo usuario puede ocupar un rol distinto en cada proyecto. La funcionalidad con la que ms se identifica a Redmine es la forma en que se le da seguimiento a las tareas y

actividades. Dentro de un proyecto, la asignacin y visualizacin de las responsabilidades se logra a travs de peticiones. Estas peticiones son asignadas a un miembro del proyecto y en su definicin contienen: fechas de inicio y fin de la tarea, tipo de peticin, porcentaje de realizacin, prioridad y descripcin. Los miembros del proyecto reciben notificaciones acerca de las actividades a las que han sido vinculados, tanto en su pgina personal de Redmine como por correo electrnico. Adems, si as se desea, estas peticiones pueden observarse a travs del calendario del proyecto o mediante un diagrama de Gantt. A continuacin se resumen algunas de las funcionalidades que posee Redmine y que lo convierten en una herramienta til para la administracin de proyectos [4]: Integracin con repositorios: permite establecer un canal de comunicacin directo con un repositorio para el control de versiones de cada proyecto. Entre los tipos de repositorios compatibles estn: Subversion, Git, CVS. Disposicin de una pgina personal: construye una pgina especfica para cada usuario donde se le muestra la informacin sobre los proyectos en los que participa. Se muestran las tareas que ha asignado, cules le han sido asignadas y la actividad reciente del proyecto. Utilizacin de filtros: permite realizar consultas sobre las peticiones existentes, tanto por campos predeterminados como por aquellos creados por el usuario. Administracin de archivos y documentos: se cuenta con una seccin donde se pueden adjuntar los documentos relacionados al proyecto. Extensin de sus caractersticas: contiene en su sitio web una larga lista de plug-ins para ampliar las funcionalidades de la herramienta. Las extensiones van desde la generacin de grficos, hasta crear salas de chat. De todas ellas se ofrece una descripcin breve, las versiones de Redmine para las que es compatible y algunos detalles sobre su instalacin. 2.2 Subversion Es una herramienta de software libre utilizada para implementar un sistema de control de versiones. A travs de ella es posible realizar de forma automtica tareas como: guardar, descargar, y mezclar las distintas versiones que a travs del desarrollo de un proyecto, se generan de un mismo archivo. Subversion se distribuye bajo la licencia APACHE/BSD (Berkeley Software Distribution), lo cual permite la inclusin de su cdigo tanto en software libre como comercial. La primera versin de la herramienta fue lanzada en octubre del ao 2000 y desde octubre del presente ao se encuentra disponible para la descarga gratuita la versin 1.7.1, ltimo release estable. Fue programada enteramente en C y es multiplataforma, compatible con

82

una gran cantidad de sistemas operativos: Windows / MacOSX / AIX / Centos Linux / Debian Linux / Fedora Linux / FreeBSD / HP-UX / NetBSD / OpenBSD / Red Hat Linux / Solaris / SUSE Linux / Ubuntu Linux) [5]. Para la administracin de los archivos versionados, Subversion maneja los conceptos de repositorio y copia de trabajo. Por repositorio se entiende aquel espacio, comn y compartido por el equipo desarrollador, en el que se conservan todas y cada una de las versiones de los archivos producidos durante el ciclo de vida del proyecto, mientras que la copia de trabajo es aquel espacio perteneciente al entorno local de cada desarrollador, sobre el cual posee dominio total y que necesita peridicamente sincronizarse con el repositorio. Esta sincronizacin se traduce en las tres operaciones bsicas de la herramienta: 1. Importar (Checkout): a travs de este comando se descarga del repositorio una copia exacta de sus contenidos, tanto de los archivos como de su estructura. Es posible descargar la ltima versin o versiones ms antiguas. 2. Actualizar (Update): esta operacin permite descargar nicamente aquellas modificaciones realizadas al repositorio, ocurridas desde la ltima sincronizacin con la copia de trabajo. 3. Confirmar (Commit): esta operacin ocurre en va inversa a las dos anteriores, ya que permite actualizar el contenido del repositorio con los cambios realizados en la copia de trabajo. Esta operacin se ejecutar correctamente si no hay conflicto con alguno de los archivos del repositorio, es decir, no habr sincronizacin si alguien ms, ha modificado el mismo elemento en forma paralela. Para una mejor organizacin de las versiones, Subversion permite la creacin de Tags y Branches dentro del repositorio. La creacin de un Tag, tcnicamente congela una versin, alejndola del tronco (Trunk) de desarrollo principal del proyecto. Por otro lado, la creacin de Branches permite la evolucin paralela de varias versiones, por ejemplo si se est trabajando al mismo tiempo en varias maneras de solucionar un mismo problema. Subversion le permite a los desarrolladores crear Branches y as tener entornos disjuntos para el desarrollo paralelo. Cuando estas versiones necesiten fusionarse, igualmente Subversion provee asistencia para su integracin [5]. A continuacin se listan una serie de caractersticas que hacen de Subversion elegible y ventajoso en comparacin con otros sistemas y estrategias no automatizadas para el manejo de versiones [6]: Los directorios tambin se encuentran versionados, no slo los archivos. El estado general del repositorio posee asignado un nico nmero de versin, y no cada archivo.

Permite adjuntar metadatos a los archivos o directorios versionados. Las operaciones sobre el repositorio son atmicas, lo que significa que ninguna tiene efecto parcialmente. Ej: un commit concluye hasta que todo l haya ocurrido exitosamente. Posee una bitcora en la que se registra un mensaje por cada commit y no por todos los archivos afectados por el commit, evitando as la redundancia. Posee merge tracking el cual es una asistencia automtica que maneja el flujo en los cambios de lneas de cdigo, lo cual es muy til para la resolucin de conflictos al mezclar archivos. Permite el bloqueo selectivo de archivos. Permite conocer los cambios realizados en el repositorio, cundo, y por quin. Le permite al usuario crear, copiar y borrar las carpetas y archivos en la copia de trabajo (o del repositorio) con la misma flexibilidad con la que se ejecutan estas acciones en el ambiente del sistema operativo. En la seccin a continuacin, se detalla sobre el procedimiento de pruebas definido para la presente investigacin. 3. METODOLOGA El objetivo principal de esta investigacin es la construccin de una plataforma que apoye y sistematice las actividades de verificacin y validacin de software. Para ello se decidi aprovechar las conocidas funcionalidades de herramientas como Redmine y Subversion e integrarlas en una nica plataforma. El hbrido de estas dos herramientas debiera poder participar en un ambiente de pruebas, donde un equipo de evaluadores realiza pruebas sobre los entregables de otro equipo de trabajo. As mismo, la herramienta debera garantizar la total separacin entre la informacin a la que tiene acceso el equipo revisado y la que ve el equipo revisor. Para satisfacer estos objetivos, se inici la configuracin de Redmine con la definicin de una estructura de proyectos y sub-proyectos, y la especificacin de los permisos y privilegios para cada rol de usuario. Conscientes de lo subjetivo que puede ser el registro de las no conformidades durante la ejecucin de las pruebas de software, se necesita de alguna manera estandarizar la forma en la que la plataforma recopila la informacin concerniente a los resultados de las pruebas. Para esto, se tom como modelo el estndar de la IEEE para Revisiones y Auditoras del Software (IEEEStd. 1012-1987) y se agregaron nuevos campos y nuevos tipos de peticiones en Redmine. Otro objetivo de la presente investigacin es proveerles a los equipos de trabajo acceso a un repositorio de control de versiones para los entregables de las pruebas. Para ello se integrar Redmine con Subversion, de tal forma que cada equipo pueda no solo versionar

83

sus documentos sino tambin acceder a los entregables a evaluar, sin abandonar el contexto de ejecucin. Dicha integracin debe conferirle total independencia a la plataforma, de manera que no sea necesaria la utilizacin de otras herramientas, para la creacin o para la alteracin del estado de los repositorios. Para ello se investig y prob varios plug-ins de Redmine. Finalmente, se puso a prueba la plataforma desarrollada, en un ambiente controlado, para depurar la herramienta y para identificar aciertos y desaciertos en la creacin del procedimiento de pruebas de pruebas ideal, luego de enfrentarlo con actores reales, situaciones y problemas reales. Esto se logr a travs de la interaccin con la docencia, incorporando el proceso de validacin de requerimientos funcionales dentro del curso de pregrado Ingeniera de Software I y su correspondiente laboratorio de la Escuela de Ciencias de la Computacin e Informtica de la UCR. En el siguiente apartado se describe detalladamente el proceso a travs del cual se configur Redmine para convertirla en una herramienta apta para las actividades de validacin y verificacin de software. 4. CONFIGURACIN DE REDMINE Al comenzar la presente investigacin, se contaba con la versin 1.1.0 de Redmine ya instalada. Se dispuso entonces a configurar la plataforma y ajustarla al proceso de pruebas. Primero fue necesario personalizar la herramienta, creando no slo la estructura de proyectos, sino tambin nuevos roles, campos y peticiones. El paso siguiente fue, hacer efectiva la integracin entre Redmine y Subversion, creando repositorios y accediendo a ellos desde la plataforma. Finalmente deba comprobarse la efectividad de los enlaces Redmine para direccionar revisiones y archivos especficos en un repositorio asociado a algn proyecto. 4.1 Estructura de proyectos El proceso de personalizacin de Redmine, comenz con la creacin de la estructura de proyectos necesaria para que la plataforma resultara apta tanto para el desarrollo, como para la administracin de las pruebas al software desarrollado. La estructura se plane en forma jerrquica: un proyecto padre y dentro de l tres sub-proyectos hijos. Estos sub-proyectos serviran de apoyo para el desarrollo de software de cada equipo. A su vez, por cada proyecto hijo se cre un sub-proyecto dedicado a pruebas. En la Figura 1 se puede observar el diagrama con la estructura de proyectos definitiva.

Seguidamente se procedi a configurar cada proyecto de acuerdo a su finalidad. Para cada tipo de proyecto, se definieron campos especficos, tipos peticiones y roles de usuario. 4.2 Personalizacin de proyectos A los proyectos de desarrollo se les agregaron los siguientes campos personalizados: Objetivo: de tipo texto largo, en l se especifica el objetivo del proyecto. Alcance: de tipo texto largo, en l se define el alcance del proyecto. Iteracin: de tipo numrico, en l se especifica la iteracin del ciclo de vida en la que se encuentra el proyecto. Versin: de tipo versin, en l se indica la versin del archivo o documento. Tipo de entregable: de tipo lista, de l se elige el tipo de entregable sobre el que se est trabajando. Los entregables pueden ser: conceptualizacin del proyecto, plan del proyecto, cronograma, especificacin de requisitos, casos de uso, casos de prueba, prototipo, modelos de diseo, cdigo, manual de usuario y manual de instalacin.

Fig. 2: Mdulo para la creacin de nuevos campos

En la Figura 2 se observa el mdulo de Redmine para la generacin de nuevos campos personalizados, entre ellos peticiones, proyectos y usuarios. Para los proyectos de prueba se agregaron los siguientes campos: Objetivo: de tipo texto largo, en l se especifica el objetivo del proyecto. Alcance: de tipo texto largo, en l se define el alcance del proyecto. Error de documentacin: de tipo lista, en l se elige el tipo de error de documentacin identificado. Estos errores pueden ser: de correspondencia con otra documentacin, de formato, de idioma, de ortografa, de redaccin, tcnico y otros. Error de aplicacin: de tipo lista, en l se elige el tipo de error de aplicacin encontrado. Este error puede ser de: correspondencia con lo documentado, de interfaz, de excepciones, de funcionalidad, de idioma, de opciones que no funcionan, de ortografa, de redaccin y de validacin), Tipo de entregable: de tipo lista, en l se elige el tipo de entregable sobre el que se est trabajando. Los entregables pueden ser: conceptualizacin del proyecto, plan del proyecto, cronograma, especificacin de requisitos, casos de uso, casos de

Fig. 1: Estructura de proyectos definida

84

prueba, prototipo, modelos de diseo, cdigo, manual de usuario y manual de instalacin. Tambin fue necesario definir en los sub-proyectos de prueba una serie de peticiones nuevas. Especficamente: Liberar entregable: peticin utilizada para informarle al Coordinador sobre la disponibilidad de un entregable para su revisin. Asignar entregable: peticin utilizada para asignarle el entregable a un Revisor. No conformidad documentacin: peticin utilizada a manera de registro, sobre el hallazgo de un error de documentacin. No conformidad aplicacin: peticin utilizada a manera de registro, sobre el hallazgo de un error de aplicacin. Liberar resultado: peticin mediante la cual se informa sobre la conclusin y resultados del proceso de pruebas.

pueden ver peticiones, aadir peticiones, modificar peticiones, hojear repositorio, ver cambios en repositorio, acceso de escritura al repositorio y actualizar el repositorio. En las siguientes secciones se explica cmo fueron cubiertas las necesidades del proceso de pruebas, mediante la instalacin de extensiones y el aprovechamiento de las caractersticas propias de Redmine. 4.4 Integracin con Subversion Una de las propiedades de Redmine, fundamental para lograr la consecucin del objetivo principal de esta investigacin, es su capacidad de integracin con repositorios de versiones, especficamente Subversion. La herramienta cuenta con un mdulo llamado Repositorio el cual debe ser habilitado primero y posteriormente configurado. La configuracin es: 1. En la pantalla de Configuracin de Proyecto habilitar el mdulo Repositorio, seleccionando la caja de chequeo correspondiente. 2. En el mdulo Repositorio elegir el tipo de repositorio de versiones con el que se asociar (Git, Mercury, Subversion, entre otros). 3. Especificar el URL del repositorio. 4. En caso de haber definido usuario y contrasea para el repositorio, se deben ingresar los mismos en los campos correspondientes. Para este caso en particular debi realizarse una configuracin adicional: la habilitacin del acceso WebDAV (extensin del protocolo HTTP), para poder mover, copiar y modificar el contenido de los repositorios, ya que fueron creados en un servidor Apache de acceso nicamente por la red local de la institucin. Una vez realizada la configuracin del mdulo Repositorio, se comprob que a travs de Redmine era posible visualizar el historial de revisiones y descargar los archivos del repositorio Subversion (Figura 3), sin embargo, no se permita modificacin alguna sobre el mismo. En otras palabras, las operaciones disponibles eran solamente de lectura y parte de los objetivos de la investigacin era lograr el manejo total de los procesos de desarrollo y de pruebas desde Redmine, sin necesitar de una segunda herramienta para realizar los commits hacia el repositorio. Por esta razn se procedi a buscar, instalar y configurar una extensin (plug-in) que satisficiera este requerimiento.

4.3 Perfiles Segn la definicin de los actores del proceso de pruebas, sus capacidades y limitaciones, as fueron definidos los perfiles para los usuarios de Redmine: Coordinador: aquel que dirige ambos procesos (desarrollo y pruebas), est al tanto de todas las notificaciones del sistema. Posee todos los permisos. Jefe de proyecto: persona de mayor responsabilidad dentro del grupo desarrollador. Dentro de sus labores ms importantes estn: asignar tareas a los desarrolladores y vigilar por el cumplimiento de la ruta crtica del proyecto. Posee todos los permisos a excepcin de aquellos de carcter administrativo: administrar el repositorio, administrar categoras de peticiones, borrar peticiones, mover peticiones y crear y modificar proyecto, seleccionar mdulos, crear sub-proyectos y administrar versiones. Desarrollador: integrantes del grupo desarrollador. Sus responsabilidades son ms que variadas pues se encargan de disear, documentar, implementar y probar, a lo largo del ciclo de vida del proyecto de software. Posee habilitados todos los permisos menos aquellos relacionados a proyectos (crear proyecto, modificar proyecto, seleccionar mdulos, crear sub-proyectos y administrar versiones), administrar categoras de peticiones, administrar relacin con otras peticiones, modificar notas, mover peticiones, borrar peticiones, administrar consultas pblicas, grabar consultas, borrar seguidores, administrar noticias y administrar repositorio. Revisor: miembros de otro equipo desarrollador, elegidos por el Coordinador del proceso, para que funjan como revisores del material del equipo revisado. El rol revisor puede ver peticiones, aadir peticiones, modificar peticiones, administrar relacin con otras peticiones, gestionar sub-tareas, borrar peticiones, hojear repositorio y ver los cambios del repositorio. Revisado: son los miembros dueos de su subproyecto de pruebas. Los usuarios con este perfil,

Fig. 3: Mdulo Repositorio de Redmine

85

Se instal el plug-in SCM extensions, con el cual se habilitan las operaciones de escritura al repositorio desde Redmine. El plug-in hace disponibles tres nuevas operaciones en el mdulo Repositorio, a saber: subir archivo, crear carpeta y borrar carpeta. Adems, se agrega al mdulo de configuracin de roles (Figura 4), un nuevo permiso sobre actualizacin del repositorio, es decir, permite definir qu usuarios pueden modificar el repositorio y cules nicamente consultarlo.

4.6 Links entre proyectos Para concluir la configuracin de la plataforma, es necesario comprobar la factibilidad de utilizar los enlaces de Redmine para direccionar objetos en el repositorio de otro proyecto, es decir, de un proyecto distinto a aquel desde el cual se realizaba la peticin. Estos links le permitiran al integrante del grupo revisor acceder directamente al archivo en el repositorio Subversion del grupo revisado, sin tener que acceder primero a un proyecto ajeno, ni desperdiciar tiempo buscando el archivo a evaluar entre las carpetas del repositorio. Sin embargo se descubri que ninguno de los enlaces Redmine, de la versin instalada (1.1.0), satisfaca la funcionalidad anteriormente descrita. Estos links entre proyectos fueron agregados a la herramienta a partir de la versin 1.2.0, bajo el nombre de cross-project links. Por lo tanto, se procedi a actualizar la plataforma a la versin 1.2.1 de Redmine. Luego de la actualizacin del Redmine se comprob la efectividad de los links entre proyectos, los cuales deben seguir el siguiente formato: idProyecto: source: rutaAlArchivo, donde idProyecto corresponde al identificador del proyecto en que se encuentra el repositorio y rutaAlArchivo se refiere a la ubicacin especfica del archivo que se desea referenciar. Estos enlaces pueden utilizarse para direccionar tanto a archivos especficos, como a toda una revisin del repositorio. 5. EJECUCIN DEL PROCEDIMIENTO Una vez finalizada la configuracin de la herramienta para soportar el procedimiento, se puso a prueba utilizando el curso de Ingeniera de Software y su laboratorio. La experiencia se realiz durante el desarrollo del proyecto prctico del curso. Se intent simular un ambiente real de trabajo, donde los estudiantes pudieran aplicar revisiones tcnicas entre grupos revisores y grupos revisados, permitindole a cada uno de los grupos (cuatro en total) evaluar la calidad del software producido por otro grupo de compaeros. Se dedicaron una serie de laboratorios para capacitar en la utilizacin de la plataforma e instruir a los estudiantes sobre sus beneficios. Se les facilit una lista clasificada de errores para que en el momento de ingresar a la plataforma, una peticin del tipo No Conformidad, pudieran clasificar y registrar el tipo de error encontrado. Tambin se les insisti en describir en forma clara el error y de ser necesario adjuntar una imagen del mismo. Se les solicit que no crearan ninguna clase de jerarqua en el momento de crear peticiones del tipo No Conformidad, sino que todas deban ser hijas (sub-tareas) de la peticin original de tipo Asignar Entregable.

Fig. 4: Pantalla para definir privilegios

Como detalle importante debe aclararse que si durante la configuracin del repositorio se especific un usuario y una contrasea, los cambios realizados al estado del repositorio quedarn a nombre de dicho usuario, por lo tanto, para que la autora de estas modificaciones vaya acorde con el usuario identificado en la plataforma, los campos de usuario y contrasea deben dejarse en blanco. 4.5 Creacin automtica de repositorios desde Redmine Una vez lograda la actualizacin de los repositorios desde la plataforma, se consider la posibilidad de que stos fuesen creados tambin desde Redmine, logrando as una independencia total al no requerir de otra herramienta o de otra persona para crear los repositorios en el servidor. Se descubri que el plug-in SCM Creator permita dicha funcionalidad. Luego de su instalacin, debe configurarse la ruta del directorio donde sern creados y otorgarle permisos de lectura, ejecucin y escritura al usuario dueo de dicho directorio (cdigo 0755). Cuando el plug-in es instalado correctamente, se puede ver en el mdulo Repositorio, junto al campo para digitar el URL, un botn (Figura 5) a travs del cual se crea el repositorio automticamente. [8].

Fig. 5: Botn para crear automticamente el repositorio

86

6. PROBLEMAS ENCONTRADOS El primer problema experimentado fue el hecho de que la versin instalada de Redmine no dispona de la funcionalidad conocida como cross-project links. Estos enlaces representaban una mejora a los enlaces que ya provea Redmine y permiten referenciar archivos en un repositorio, revisiones enteras o incluso documentos adjuntos pertenecientes a un proyecto distinto. Sin embargo, la actualizacin mencionada en la seccin anterior, requiri instalar tambin la versin 2.3.11 de Ruby on Rails lo cual gener una gran inestabilidad en el Mongrel (servidor web que viene con Redmine) y cierta incompatibilidad con los plug-ins instalados. Dicha inestabilidad provocaba que el trnsito entre una pantalla y otra de la interfaz web se viera interrumpido y muy frecuentemente concluyera con una pantalla en blanco. Incluso si se refrescaba la pgina, la accin ejecutada antes del bloqueo, se repeta, produciendo la duplicacin de peticiones o de archivos subidos al repositorio. Para solucionar esto, debi utilizarse el Webrick (servidor Web que viene con Ruby) como servidor alterno, el cual brind mayor estabilidad a la plataforma. La mayor dificultad en trminos de configuracin a la que hubo que hacer frente, fue la poltica que posee Redmine, de compartirlo todo o no compartir nada. Esto qued en evidencia al probar el funcionamiento de los links entre proyectos (cross-project links), pues los enlaces resultaron funcionales s y slo s, el usuario que los defina era miembro de ambos proyectos. Esta limitacin afect la definicin original de los roles en el proceso de pruebas, pues se deseaba una total separacin entre los equipos. La solucin ptima fue que los revisores no tuvieran acceso ms que a la descarga directa del entregable en el repositorio del equipo revisado, sin embargo, para utilizar los links debieron hacerse tambin miembros del proyecto de pruebas. La solucin fue crear un perfil bastante limitado para estos revisores, de manera que slo tuvieran acceso de lectura al repositorio y acceso denegado a todos los dems mdulos del proyecto revisado. Si bien los estudiantes recibieron toda la induccin necesaria para la utilizacin de la plataforma, el ambiente del curso no era el ptimo para que se alcanzaran los mejores resultados. La inexperiencia de los participantes en cuanto al desarrollo de pruebas de software y la inclinacin por proveer sus propias soluciones cuando se encontraban frente a un problema, atent contra la uniformidad de los resultados. Para solucionar esto se elabor un manual de usuario y se realiz una nueva sesin de capacitacin sobre el uso de la herramienta, donde se atendieron las dudas de los estudiantes y se explic paso a paso el procedimiento de pruebas. Adems por la irregular asistencia de los estudiantes a los laboratorios, qued evidenciada en la definicin de roles, una fuerte dependencia sobre el lder de proyecto, ya que slo l poda modificar o borrar las peticiones

realizadas, lo cual restaba fluidez al trabajo de los desarrolladores. La solucin fue flexibilizar la definicin de los roles de usuario, otorgando a los desarrolladores mayores permisos sobre las peticiones. 7. CONCLUSIONES Y TRABAJO FUTURO Como herramienta para la administracin de proyectos, Redmine satisface todas las necesidades en cuanto a seguimiento de tareas y comunicacin entre los participantes. Esto sumado a su integracin con Subversion para administrar repositorios de versiones, terminan por convertirla en una plataforma ms que funcional para el desarrollo de proyectos de software. La gran flexibilidad y facilidad para la personalizacin que posee Redmine, representaron caractersticas claves durante la investigacin, ya que extienden el campo de accin de la herramienta, permitindole ajustarse a proyectos de la ms diversa naturaleza. La posibilidad de definir tipos concretos de peticiones y agregar nuevos campos a los formularios, le conceden al usuario la capacidad de utilizar Redmine en proyectos de formato no tradicional. Incluso cuando parece que la herramienta no puede satisfacer necesidades especficas, el sitio oficial de Redmine posee una gran cantidad de extensiones (plugins) que le ayudan en gran manera al usuario a solventar sus problemas. Esta investigacin no hubiera podido llegar a buen trmino sin la posibilidad de instalar los plug-ins (SCM extensions y SCM creator) que enriquecieron de gran forma las operaciones sobre los repositorios de Subversion. Crear repositorios y realizar operaciones de escritura sobre ellos sin tener que abrir otra aplicacin, le confirieron a la plataforma cierta autonoma que en un inicio no se crea posible. Los laboratorios con los estudiantes representaron una gran fuente de retroalimentacin sobre el procedimiento de pruebas definido. Tambin, la utilizacin de la plataforma por usuarios ajenos al desarrollo de la misma, result en una variedad de comentarios y opiniones sobre su facilidad de uso, las ventajas y desventajas de su introduccin en las revisiones tcnicas formales y por supuesto el sealamiento de carencias o errores en el diseo de los formularios desde el punto de vista de usuario final. Entre las dificultades encontradas que atentaron contra el rendimiento de la plataforma y su deseada configuracin estuvieron: el comportamiento inconstante de los enlaces entre proyectos, la inestabilidad de la plataforma posterior a su actualizacin y la escasa capacitacin que recibieron los estudiantes sobre la utilizacin de la plataforma, especialmente el modo de registrar las no conformidades. Aun as, por encima de todas estas dificultades se concluye que s es posible configurar Redmine para su utilizacin como plataforma de un proceso de pruebas

87

de software bajo una modalidad de equipos. Su completa integracin con Subversion, permite el intercambio de entregables para su respectiva evaluacin y su naturaleza web, permite el registro, envo y acceso de los resultados de las pruebas, rpida y fcilmente. Se espera que el xito de la presente investigacin no culmine con los resultados ya obtenidos, sino que impulse otros trabajos en los que se experimente la integracin de Redmine con otros repositorios como Git, o Mercurial. Actualmente se est trabajando en la inclusin de nuevos campos para la obtencin de mtricas de pruebas y la generacin de reportes de incidencias. Posterior a esta experiencia, se concluye que en proyectos sucesivos sobre integracin de herramientas, es vital que desde un inicio se elijan aquellas que demuestren una complementariedad natural, ya sea por la existencia de mdulos dedicados a compartir su informacin a travs de servicios web o la exportacin de datos. Esto permitira que la integracin suceda de manera rpida y transparente. Otra caracterstica importante es la afinidad temtica de las herramientas.

Finalmente como proyecto a futuro siempre en el mbito de las pruebas de software, se considera la integracin de NUnit y Selenium para una agilizacin de las actividades de validacin y verificacin en aplicaciones web. 8. REFERENCIAS
[1] [2] [3] [4] [5] [6] [7] [8] Cmara Costarricense de Tecnologa de Informacin y Comunicacin. 2010. Sobre nosotros. Online [Mar. 2011] Consejo Nacional para la Calidad de Calidad Costa Rica. 2006. Online [Mar. 2011]. Organizacin Redmine. 2011. Online [Marc. 2011]. Centro de excelencia de software libre de Castilla La Mancha. Anlisis de aplicacin: Redmine. 2010. Online [Marc. 2011]. Organizacin Apache. 2011. Apache Subversion. Onlilne [Apr. 2011]. Gmez, E. S. 2010. Buenas prcticas de gestin de versiones con Subversion. Online [Apr. 2011]. Collins-Sussman, B.; Fitzpatrick, B. W. & Pilato, C. M. 2004. Version Control with Subversion For Subversion 1.0. Published (TBA). Lesyuk, A. 2011. Redmine SCM Creator. Online [Apr. 2011].

88

Case Based Reasoning to Infer the Behavior of a Release Testing of Software Products Razonamiento Basado en Casos para Inferir el Comportamiento de una Prueba de Liberacin de Productos Software
Heney Daz P.1, Daira Prez S.2
1 2

Profesor Asistente del Departamento de Pruebas de Software de CALISOFT, La Habana, Cuba. hdperez@uci.cu Profesora Asistente y Asesora de Planificacin y Control del centro ISEC de la UCI, La Habana, Cuba. dairap@uci.cu ABSTRACT This paper presents a proposal of solution to infer the duration of an iteration of release testing. It begins with the description of the testing process of Industrial Laboratory of Testing Software of the Universidad de las Ciencias Informticas. Then, it makes a conceptualization of Iteration studying the testing methodology of some organizations. Based on participant observation and once the Artificial Intelligence technique Case-Based Reasoning is defined, a case base is structured for supporting the proposal taking into account all features that influence the duration of tests. This base case will consider the historical behavior of release test. Valid elements are proposed to estimate the time a liberation test takes. Thus, a plan adjusted to reality can be planned to assure all release request of software products. RESUMEN En este artculo se presenta una propuesta de solucin para inferir el tiempo de duracin de una iteracin de pruebas de liberacin. Se parte de la descripcin del procedimiento de pruebas del Laboratorio Industrial de Pruebas de Software de la Universidad de las Ciencias Informticas, para luego realizar una conceptualizacin del trmino Iteracin estudiando la metodologa de pruebas de algunas organizaciones. A partir de la observacin participante y definida la tcnica de Inteligencia Artificial de Razonamiento Basado en Casos, se logra estructurar una base de casos para fundamentar la propuesta, con todos los rasgos que influyen en la duracin de las pruebas. La base de casos tendr en cuenta el comportamiento histrico del proceso de pruebas de liberacin. Con esta propuesta se dispone de elementos vlidos para estimar el tiempo que dura una prueba de liberacin. De esta manera se podr trazar un plan ajustado a la realidad, para dar respuesta a todas las solicitudes de liberacin de productos de software.

INFORMACIN DEL ARTCULO Tipo de artculo: Reflexin. Historia del artculo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 12/06/2012 Palabras clave Base de casos, iteracin, prueba de liberacin. Categories and Subject Descriptors D.2.4 [Software Engineering]: Software/Program Verification. General Terms Verification. Keywords Base case, iteration, release testing.

1. INTRODUCCIN Segn Myers [1], una organizacin desarrolladora debiera evitar probar sus propios sistemas. Bajo este principio se perfila toda una industria de prueba de software constituida en los pases desarrollados por una buena cantidad de profesionales especializados, proveedores de servicios y herramientas, congresos, publicaciones peridicas e innumerables alternativas de capacitacin y certificacin, el nivel de especializacin en dicha industria, se consume por el primordial desarrollo de la industria de software. Entre las organizaciones consideradas como pilares en las pruebas de software se encuentran el Centro de Ensayos de Software [2], GreenSQA de Parquesoft [3] y BugHuntress [4], entre otras. Cada una define su propia estrategia o procesos de ejecucin de pruebas en funcin de los servicios que provee. Internacionalmente Cuba tiene poca imagen como pas productor de software. Al mismo tiempo, en lo que a pruebas de software respecta, los avances son bastante discretos. No fue sino hasta la IX Convencin y Feria Internacional Informtica en 2003 y el Primer Taller Internacional de Calidad de Software, que se comenz a crear un ambiente favorable en torno a las pruebas, a

travs de la discusin de temas afines. Ese mismo ao se crea la Direccin de Calidad de Software de la Universidad de las Ciencias Informticas UCI, con un laboratorio de pruebas, que hoy forma parte del Departamento de Pruebas de Software y que tiene adscritos un grupo de trabajo de Ingeniera de Pruebas y un Laboratorio Industrial de Pruebas de Software. Desde la puesta en marcha de este laboratorio se ha observado que el tiempo de ejecucin de las mismas sobrepasa, en la mayora de los casos, al tiempo planificado y pactado entre las partes involucradas. Muchos son los factores que dan al traste con esta situacin y que provocan fuertes retrasos de los compromisos de entrega de los productos de software a los clientes. Entre estos factores se pueden sealar, el hecho de que los probadores y hasta los desarrolladores en muchos casos son estudiantes de pregrado en formacin, la demora en los tiempos de respuesta del equipo de desarrollo y la pobre disponibilidad de recursos. A partir todo esto se define el siguiente problema: Cmo lograr que el tiempo de duracin de una iteracin de pruebas se corresponda con el tiempo planificado y pactado inicialmente entre las partes

89

involucradas? Para darle respuesta se plantea el objetivo de disear una base de casos que permita inferir el tiempo de duracin de una iteracin de pruebas a partir del razonamiento basado en casos. 2. LAS PRUEBAS DE LIBERACIN Desde el punto de vista del cliente y los usuarios, la calidad de un producto de software es percibida principalmente por las fallas que encuentran en el producto y por la gravedad que stas tienen para el negocio del cliente. Para ser competitivas, las empresas desarrolladoras de software necesitan asegurarse de la calidad de sus productos previo a su instalacin en el ambiente del cliente. Un paso previo a la instalacin del sistema en el ambiente del cliente o la entrega de cualquier artefacto que se obtenga como parte del desarrollo de software, lo constituye la prueba de liberacin, teniendo en cuenta que para el Departamento de Pruebas de Software DPSW constituyen una etapa dentro del ciclo de vida del software, se ejecutan una vez que se haya concluido el desarrollo y realizadas las pruebas internas en el proyecto, a todos los artefactos que constituyen entregables al cliente, o que deben ser utilizados como parte del desarrollo de otro proyecto. Dentro de las pruebas de liberacin se realizan evaluaciones estticas y dinmicas, dependiendo del artefacto que deba ser evaluado, las cuales se enmarcan en el concepto de pruebas de software al que se lleg a partir de las definiciones estudiadas. Un estudio basado en varias organizaciones que brindan servicios de pruebas de software permiti precisar algunos elementos importantes y que se tienen en cuenta de una u otra forma como generalidad. Entre estos se encuentra el establecimiento de una estrategia de pruebas y la definicin de sus procesos, infraestructura, herramientas fundamentalmente automatizadas y tcnicas. Se conoce que realizan estas definiciones para desarrollar su actividad pero no se pudo constatar cmo se implementaban dichos procesos, en qu consistan las estrategias de pruebas. A continuacin, se define el proceso de pruebas de liberacin desarrollado por el DPSW y se asocia una de sus actividades con el rea de procesos de administracin de acuerdo con proveedores, establecida por CMMI, en funcin de elevar la eficiencia en la prestacin del servicio de pruebas y satisfacer las necesidades del cliente. 2.1 Procedimiento de Pruebas de Liberacin. Laboratorio Industrial de Pruebas de Software En el Departamento de Pruebas de Software de la UCI existe un grupo de especialistas capacitados en la ejecucin de pruebas de liberacin y aceptacin de productos de software antes de la entrega pactada con el cliente. Es en el Laboratorio Industrial de Pruebas de Software LIPS, a travs de un procedimiento de pruebas, que se revisan todos los artefactos que constituyen entregables.

Una solicitud de prueba constituye el primer paso del procedimiento. A travs de ella, los proyectos solicitan al laboratorio la liberacin de diversos artefactos, reflejando bsicamente la complejidad de los mismos, los requerimientos de software y hardware para poder probarlos y la fecha de compromiso con el cliente. Esta solicitud es revisada para confirmar que estn todos los elementos necesarios y que no existe ninguna dificultad para ejecutar la prueba. Es en este momento que se acepta o se rechaza la solicitud. Una vez aceptada la solicitud, se asigna un especialista [5] que ser el responsable de la gestin de la prueba. Dicho especialista es el encargado adems de elaborar un pre-plan de pruebas donde recoge todos los elementos a tener en cuenta para la satisfactoria ejecucin de la liberacin del artefacto o de los artefactos en cuestin. Entre estos elementos, uno muy importante lo constituye la propuesta de cronograma de ejecucin del procedimiento de pruebas de liberacin. Dicho cronograma se discutir posteriormente en la reunin de inicio, previo a la ejecucin de las pruebas. La reunin de inicio es el momento en el que se discute con el equipo de proyecto, el pre-plan de pruebas elaborado y se ajustan los aspectos necesarios. Se ajusta adems, el cronograma inicialmente propuesto y se aprueba entonces el Plan de Pruebas que gua todo el proceso de liberacin. Luego de efectuada la reunin de inicio ya las partes involucradas estn de acuerdo en el procedimiento a seguir. Faltara puntualizar algunos detalles para comenzar con las pruebas. Es momento entonces de refinar la batera de casos de pruebas y listas de chequeo necesarias para el proceso, y al mismo tiempo, montar el entorno de pruebas. Estas dos actividades se realizan de forma simultnea. Al revisar los casos de pruebas y listas de chequeo se parte de los casos de prueba y pautas definidas en el proyecto, adaptaciones realizadas a las listas de chequeo, especificaciones de casos de uso y/o especificaciones de requisitos. En el caso del montaje del entorno de pruebas, este corresponder siempre con el definido y acordado en el plan de pruebas. Ahora bien, cmo optimizar los recursos a la hora de efectuar las pruebas? Es con las pruebas exploratorias que se disminuye el gasto de tiempo, recursos humanos, tecnologa, esfuerzo, etc., ya que proporcionan rpidamente informacin sobre el artefacto que se va a probar y garantizan un mnimo de calidad para que el artefacto pase a la fase de pruebas. Entonces, posterior a la preparacin de los casos de prueba y listas de chequeo, de conjunto con el montaje del entorno de pruebas y justo antes de comenzar las pruebas, se ejecutan las pruebas exploratorias. Con estas se prueba o revisa una muestra significativa de cada artefacto de forma que se verifique que estn listos para entrar al LIPS.

90

Las pruebas comienzan entonces con la ejecucin de las iteraciones. En cada una de ellas se ejecuta la batera completa de casos de prueba y listas de chequeo, la cual va a generar un conjunto de No Conformidades que son entregadas al equipo de desarrollo. Este por su parte, tiene la responsabilidad de dar respuesta en un tiempo prudencial a cada una de ellas, en correspondencia con lo pactado en el plan de pruebas. Efectuadas las iteraciones de pruebas hasta conseguir que no se detecten NC y que no quede ninguna pendiente, previo anlisis por parte del especialista al frente de la prueba con la direccin del Departamento de Pruebas de Software, se procede a la liberacin de los artefactos y al cierre de las pruebas. Se emite entonces un acta de liberacin, se entregan los artefactos liberados y se efecta una evaluacin de las pruebas. Por ltimo, se almacena la versin liberada de cada artefacto de modo que est disponible para efectuar las pruebas de aceptacin con el cliente. Del procedimiento de pruebas de liberacin descrito hasta este momento, la actividad que ms influye en el tiempo de duracin de la prueba es justamente la de ejecucin de las iteraciones. 2.2 Iteraciones de Pruebas Al Segn se define en la vigsima segunda edicin del Diccionario de la Lengua Espaola de la RAE, el trmino iteracin proviene del latn iteratio y significa: Accin y efecto de iterar. Por su parte, el trmino iterar significa repetir, volver a hacer lo que se haba hecho. Una iteracin se refiere a la accin de repetir una serie de pasos un cierto nmero de veces. Desde el punto de vista matemtico, una iteracin se refiere al proceso de iteracin de una funcin o a las tcnicas que se usan en mtodos iterativos para la resolucin de problemas numricos. En programacin, la iteracin es la repeticin de una serie de instrucciones en un programa. Desde el punto de vista de la gestin de proyectos informticos, las iteraciones se refieren a la tcnica de desarrollar y entregar componentes incrementales de funcionalidades de un negocio. La organizacin GreenSQA de Parquesoft en Colombia, recoge en su metodologa de pruebas de software a las iteraciones de pruebas como parte del proceso de ejecucin de las mismas, como se observa en la Figura 1. Bsicamente define a la iteracin como las actividades requeridas para ejecutar los requerimientos de prueba identificados en la fase de diseo de pruebas, reportar los hallazgos y asegurar su correccin por parte del equipo de desarrollo de software [6]. El Centro de Ensayos de Software de Uruguay, en su estrategia de gestin de las pruebas funcionales, trata a las iteraciones como ciclos. Plantea que el objetivo de cada ciclo es el de generar y ejecutar las pruebas para

una versin determinada del producto. El proyecto de prueba es guiado por los ciclos de prueba y cada ciclo est asociado a una versin del producto a probar [7]. Dentro de cada ciclo se realiza un seguimiento del mismo con el objetivo de planificar en detalle las tareas del mismo y ajustar la planificacin.

Fig. 1: Metodologa de Pruebas de Software de GreenSQA

Como parte del ciclo tambin se tiene en cuenta la configuracin del entorno y el diseo de los casos de prueba a partir de la especificacin del producto; se contempla la ejecucin de las pruebas para contrastar el comportamiento esperado del software con su comportamiento real, se analizan las diferencias y se reportan los resultados (ver Figura 2).

Fig. 2: Metodologa de Pruebas de Software del CES

Partiendo de las diferentes definiciones de iteracin, dadas las particularidades del proceso de desarrollo de software en la UCI y del propio procedimiento de pruebas de software del LIPS, el trmino se conceptualiz como se manifiesta a continuacin. Una iteracin no es ms que la revisin completa de un determinado artefacto, dgase de tipo documentacin o aplicacin, con el empleo de determinadas herramientas segn corresponda. En el desarrollo de la misma participan estudiantes en el rol de probador y especialistas de pruebas, funcionales y del sistema, como se observa en la Figura 3. Del mismo modo, dentro de cada iteracin, se ejecuta la batera de pruebas completamente, se informan las No Conformidades detectadas y se entregan al equipo de desarrollo. Posteriormente se realizan pruebas de regresin y se preparan las condiciones para la siguiente iteracin o para el trmino de las pruebas con la liberacin final del artefacto.

91

Fig. 3: Mapa Conceptual. Iteracin

3. RAZONAMIENTO BASADO EN CASOS El Razonamiento Basado en Casos RBC surge en la dcada del 80 como un nuevo paradigma de la Inteligencia Artificial. Sus races parten del trabajo de Roger Schank [8] y su modelo de memoria dinmica. Schank plante que esta forma de razonamiento resuelve nuevos problemas adaptando soluciones utilizadas en problemas anteriores. Entre las diversas definiciones existentes se encuentra tambin la de Kolodner [9], quien plantea que constituye, por un lado la forma en la cual la gente utiliza casos para resolver problemas y por otro las formas con las que podemos hacer que las mquinas las utilicen. Aamodt & Plaza [10] enuncian por su parte que constituye una reciente aproximacin para la resolucin de problemas y para el aprendizaje. En este sentido, el razonamiento basado en casos es una tcnica de Inteligencia Artificial que se basa en la utilizacin de experiencias previas para resolver nuevos problemas mediante la hiptesis de que problemas similares tienen soluciones similares. Dado un problema a resolver, el RBC busca, en una base de casos, problemas similares que anteriormente se hayan resuelto con xito, llamados casos, y adapta las soluciones para dar una solucin al problema actual. Este mecanismo de razonamiento es utilizado por los humanos en mltiples problemas de la vida cotidiana y permite que sea un sistema de fcil comprensin. El RBC involucra toda una metodologa con un ciclo de actividades que adems de solucionar nuevos problemas nos permite aprender de las buenas soluciones obtenidas por los nuevos problemas. Entre las actividades se relacionan las siguientes: Recuperar: Dado un problema, se recuperan los casos ms similares de la base de casos, partiendo de que un caso es un problema anterior con su solucin. Reutilizar: Extraer la solucin del caso seleccionado para utilizarla. Esto puede implicar adaptar la solucin a la nueva situacin. Revisar: Se debe analizar si la nueva solucin es aceptable y si es necesario revisarla. Retener: Despus de haber aplicado la solucin con xito, se debe almacenar la experiencia como un nuevo caso en la base de casos.

Fig. 4: El ciclo del RBC segn la Unidad de Desarrollo Tecnolgico en Inteligencia Artificial

Por lo anteriormente expuesto, para utilizar el RBC es conveniente disponer de casos de xito para diferentes problemas y conocer los diferentes factores que influyen en la solucin. Estos factores son conocidos como rasgos y son detallados en la estructura de la base de casos [11]. 4. ESTRUCTURA DE LA BASE DE CASOS PROPUESTA Para estructurar la base de casos que se propone como solucin para estimar el tiempo de duracin de una iteracin, se parte de aplicar el mtodo de observacin participativa. Cada uno de los rasgos identificados, son resultado de la experiencia de un grupo de especialistas del LIPS, en estrecha relacin con el procedimiento de pruebas de software y las peculiaridades en el proceso de desarrollo. Todos los artefactos que se someten a pruebas de liberacin en el laboratorio, se pueden clasificar en dos categoras fundamentales. Pueden ser artefactos de tipo documentacin o aplicacin. Los documentos que entran al laboratorio son aquellos generados por los proyectos y que constituyen entregables al cliente. Del mismo modo sucede con las aplicaciones, constituyen entregables y objetos del proceso de liberacin. En este caso, dentro de las aplicaciones entran todos los sistemas informticos, desde sistemas de gestin, multimedia, aplicaciones web, portales, hasta juegos. La revisin de los artefactos de tipo documentacin, siempre van a requerir menos esfuerzo y empleo de recursos que los artefactos de tipo aplicacin. Por esto, constituyen factores determinantes en la duracin de una iteracin, a tener en cuenta en la base de casos. Determinado el tipo de artefacto, otro elemento importante lo constituye el tipo de pruebas a aplicar, que est en correspondencia con el artefacto. Por consiguiente, va a determinar tambin la duracin de la prueba. Los tipos de prueba pueden ser de funcionalidad, seguridad, volumen, contencin, carga, estrs, rendimiento, configuracin, instalacin o simplemente revisin tcnica de la documentacin [1].

92

Cmo enfrentar entonces los diferentes tipos de pruebas? Para esto se emplean un conjunto de herramientas que pueden ser casos de prueba, listas de chequeo o herramientas automatizadas [12]. Las mismas se seleccionan en funcin del tipo de pruebas a realizar y poseen diferentes niveles de complejidad que van a influir tambin en el tiempo de duracin de la iteracin. Las herramientas constituyen otro rasgo de la base de casos propuesta. El esfuerzo para la ejecucin de una iteracin corre a cargo del especialista de pruebas al frente de la prueba y de los estudiantes que se desempean como probadores. Por tal motivo, la cantidad de probadores y de especialistas de que se disponga va a influir de modo significativo en la duracin de una iteracin. Por ltimo, y no menos importante, existen dos factores que son minimizados en muchas ocasiones pero que su importancia puede resultar vital en el correcto desempeo de una prueba de liberacin. Se trata de la presencia de un especialista funcional y de un especialista de sistema. El especialista funcional es la persona capacitada en todos los temas del negocio que se informatiza. Su conocimiento, ayuda a los probadores y especialistas de pruebas, a entender la filosofa del artefacto en cuestin. El especialista de sistema por su parte, constituye un miembro del equipo de desarrollo que conoce el artefacto, de modo que puede ayudar a su comprensin mientras se enfrenta la prueba. El rasgo que se va a inferir con esta propuesta, es el tiempo de duracin de la iteracin.
Tabla 1. Base de Casos Propuesta

liberacin con un nivel de precisin basado en la experiencia acumulada. Esto les permitir realizar planificaciones y estimaciones de recursos y esfuerzo ms reales, con mayor nivel de certeza, para lograr un desarrollo eficiente del proceso. De esta manera, los tiempos de ejecucin de las pruebas se ajustarn a lo previsto inicialmente, tributando al cumplimiento de los compromisos con el cliente. Al mismo tiempo la propuesta contribuir de manera decisiva a la toma de decisiones, ya que aporta elementos determinantes a la hora de realizar determinadas valoraciones. A la hora de validar la propuesta, se utiliz la herramienta SI-Holmes, desarrollada en la UCI. La misma constituye un sistema experto de propsito general, desarrollado para la evaluacin de bases de casos, permitiendo crear expertos de cualquiera de ellas. Para obtener una solucin, se selecciona el o los rasgos a inferir, se llenan los otros que se consideren necesarios, se escoge alguno de los algoritmos implementados y el sistema indica el resultado de la inferencia brindada por el experto, los casos ms cercanos de manera grfica y en detalles. Durante las inferencias realizadas, la estructura de la base de casos propuesta favoreci un comportamiento estable, al no mostrar picos exagerados, quedando los valores estimados muy cerca de la realidad. Hoy la investigacin se encuentra terminada y est siendo utilizada al mismo tiempo, para el anlisis, diseo e implementacin de un sistema inteligente, de propsito especfico, que base su funcionamiento en la definicin de un peso por cada rasgo y de una funcin de inferencia bien estudiada y documentada y no en la implementacin de algoritmos de propsito general. 6. CONCLUSIONES Con la realizacin de esta investigacin se pudo arribar a las siguientes conclusiones: El procedimiento de pruebas del Laboratorio Industrial de Pruebas de Software constituye uno de los principales elementos para una satisfactoria ejecucin de pruebas de liberacin a los artefactos que se producen en los Centros de Desarrollo, de la Universidad de las Ciencias Informticas. Su establecimiento y mejora permitir afrontar nuevos compromisos con el resto de las organizaciones de desarrollo de software y su insercin en el mercado internacional. La definicin del trmino de iteracin, a partir de las metodologas de pruebas de software de organizaciones tales como el Centro de Ensayos de Software de Uruguay y el GreenSQA de Parquesoft en Colombia, permiti fundamentar los cimientos para el planteamiento de la solucin. La identificacin de los principales elementos a tener en cuenta para aplicar la tcnica de Inteligencia Artificial de Razonamiento Basado en Casos,

En la Tabla 1 se realiza una representacin de los datos que contendr la base de casos propuesta. En la misma se recogen los rasgos que la compondrn, los posibles valores que pueden asumir cada uno de los rasgos y se especifica si puede existir multi-seleccin, es decir, si se puede seleccionar ms de un valor para cada rasgo. 5. RESULTADOS ESPERADOS La calidad de los resultados de la aplicacin de la base de conocimiento, depende en gran medida, del proceso de recogida de los datos de los casos reales a ser insertados en la base de casos. Importante tambin, resulta la existencia de una cantidad suficiente de casos, con todas las combinaciones posibles, en pro de lograr resultados precisos. Se espera entonces, que los especialistas del LIPS puedan inferir el comportamiento de las pruebas de

93

favoreci el uso de esta tcnica para la definicin de una base de casos con los rasgos que caracterizan el comportamiento de una prueba de liberacin de productos de software. El diseo de la estructura de una base de casos para inferir el tiempo de ejecucin de una iteracin de pruebas de liberacin, en el Laboratorio Industrial de Pruebas de Software, favorecer la implementacin de una herramienta que permita realizar un conjunto de estimaciones para mejorar el proceso de pruebas y aumentar la satisfaccin del cliente con la prestacin del servicio. 7. REFERENCIAS
[1] [2] [3] [4] Myers, G. J. 2004. The art of software testing. John Wiley & Sons, Inc. http://www.uruguayinnova.org.uy/benef_ces.htm. http://www.greensqa.com/portal/index.php. http://www.bughuntress.com/.

[5]

Palomo, G. M. A. 2007. Modelo para la capacitacin de los especialistas de pruebas de sistemas de software. Actas de Talleres de Ingeniera del Software y Bases de Datos, 1(4), 31-36. [6] Roca, M. J. 2006. Proyectos de Gestin de Calidad: una primera vista desde el enfoque de la gua del PMBOK. Online [Sep. 2011]. [7] Lamancha, P. B. 2007. Estrategia de gestin de las pruebas funcionales en el Centro de Ensayos de Software. REICIS, 3(3), 28-41. [8] Schank, R. 1982. Dynamic memor, a theory of reminding and learning computers and people. Cambridge University Press. [9] Kolodner, J. L. 1993. Case-Based Reasoning. Morgan Kaufmann Publishers. [10] Aamodt, A. & Plaza, E. 1994. Case-based reasoning: Foundational issues, methodological variations, and system approaches. AI Communications, 7(l), 39-59. [11] Barranco, R. J. A. 2009. El Razonamiento Basado en Casos o Case-based Reasoning (CBR). Online [Sep. 2011]. [12] Esmite, I. et al. 2007. Automatizacin y gestin de las pruebas funcionales usando herramientas Open Source. Proceedings XIII Congreso Argentino de Ciencias de la Computacin (CACIC).

94

A quality assurance experience in a Systems Unit Una experiencia de aseguramiento de la calidad en una Unidad de Sistemas
Marcelo Jenkins1, Alexandra Martnez2, Gustavo Lpez3
12 2

Esc. de Ciencias de la Computacin e Informtica, Universidad de Costa Rica, San Jos, Costa Rica. marcelo.jenkins@ecci.ucr.ac.cr. alexandra.martinez@ecci.ucr.ac.cr. 3 Centro de Investigaciones en Tecnologas de Informacin y Comunicacin, Universidad de Costa Rica, San Jos, Costa Rica gustavo.lopez_h@.ucr.ac.cr. INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin. Historia del artculo Recibido: 30/03/2012 Correcciones: 30/05/2012 Aceptado: 10/06/2012 Palabras clave Aseguramiento de la calidad, pruebas de software, CMMI. Categories and Subject Descriptors D.2.5 [Software Engineering]: Management software process models, software quality assurance. General Terms Experimentation, Verification. Keywords Quality assurance, software testing, CMMI. ABSTRACT This article is an experience report of carrying out a project to improve the process in a small software development organization based on the CMMI-DEV 1.3 model. Specifically, our project focused primarily on improving the software testing subprocess and implementing SCAMPI type C assessments of the current process. We describe the scope of the project and the results obtained to date in conducting independent testing of the software systems and the assessments of the state of the current software process based on the CMMI model. This article may interest organizations wishing to improve their software process based on an international standard. RESUMEN Este artculo es un reporte de la experiencia de llevar a cabo un proyecto de mejoramiento del proceso de una unidad de desarrollo de software pequea con base en el modelo CMMI-DEV 1.3. Especficamente, nuestro proyecto estuvo enfocado principalmente en mejorar el subproceso de pruebas de software y en realizar evaluaciones SCAMPI tipo C del proceso actual. Describimos el alcance del proyecto y los resultados obtenidos hasta la fecha de llevar a cabo pruebas independientes de los sistemas desarrollados y de evaluar el proceso actual con base en el modelo CMMI. Este artculo puede interesar a organizaciones de software que desean mejorar su proceso con base en algn estndar internacional.

1. INTRODUCCIN El aseguramiento de la calidad QA, por sus siglas en ingls es un conjunto de actividades planificado y sistemtico que proporciona confianza en que los productos y servicios cumplirn los requerimientos especificados y las necesidades del usuario [11]. En el caso del software, QA establece y evala los procesos que producen los productos de software. Por ejemplo, las actividades de QA en un ambiente de TI determinaran la necesidad de: metodologas de desarrollo de sistemas, procesos de estimacin, procesos de mantenimiento de sistemas, procesos de definicin de requerimientos, y procesos de pruebas y estndares. Una vez implantados, QA medira estos procesos para identificar debilidades y luego corregira esas debilidades para mejorar continuamente el proceso [17]. El software es uno de los artefactos ms variables y complejos que se disean regularmente. El costo de la verificacin del software sobrepasa la mitad del costo total del desarrollo y mantenimiento, y an estamos lejos de poder producir software libre de defectos [15]. Escoger la combinacin apropiada de tcnicas para alcanzar el nivel de calidad requerido dentro de las restricciones de costo es un reto constante para quienes verifican productos de software. El proceso de Verificacin y Validacin V&V inicia en el momento en que se decide desarrollar un producto de software, y est presente en todo el ciclo de vida del

software. La ejecucin de las pruebas al final del ciclo de desarrollo es slo una pequea parte de todo el proceso de V&V. Las actividades de verificacin controlan la calidad de los artefactos intermedios y del producto final, de manera que satisfagan los requerimientos. Las actividades de validacin comprueban que los artefactos intermedios y el producto final correspondan a las expectativas de los usuarios [15]. Kaner [11] define las pruebas de software como una investigacin tcnica que se realiza para suministrar a un actor informacin relacionada con la calidad de un producto de software. Aqu un actor es cualquier persona que tenga un inters en el producto de software, desde el usuario final hasta el que financia el desarrollo del mismo. Kaner et al [10] plantean que el objetivo de las pruebas es encontrar problemas en el software, y que una prueba es exitosa si logra detectar un problema. El beneficio de realizar pruebas es que mejora la calidad del software puesto que los problemas encontrados se corrigen aunque pueden existir problemas que no se corrijan por su alto costo y complejidad. Los modelos CMMI son colecciones de mejores prcticas que ayudan a las organizaciones a mejorar la efectividad, eficiencia, y calidad de sus procesos. Estos modelos de madurez y capacidad son desarrollados por equipos conformados por miembros de la industria, el gobierno y el Carnegie Mellon Software Engineering

95

Institute. La versin 1.3 de CMMI [2, 18], publicada en noviembre de 2010, contiene tres modelos, o constelaciones: CMMI-ACQ para adquisiciones, CMMISVC para servicios y CMMI-DEV para desarrollo. En este trabajo se utiliz el modelo CMMI-DEV V1.3, que cubre las actividades para el desarrollo de productos y servicios, y consta de 22 reas de proceso PAs distribuidas en cuatro categoras (segn la representacin continua): Gestin de Proyectos, Soporte, Ingeniera, y Gestin de Procesos. De acuerdo con la representacin escalonada, las reas de proceso se agrupan en cinco niveles de madurez, donde cada nivel de madurez abarca un conjunto de reas de proceso que proponen prcticas especficas y genricas que la organizacin puede ejecutar, estableciendo as una trayectoria predeterminada de mejora desde el nivel 1 hasta el nivel 5. Este artculo reporta nuestra experiencia implementando prcticas de aseguramiento de la calidad en una Unidad de Sistemas que desarrolla software interno para nuestra universidad. El resto del artculo est organizado de la siguiente manera. La seccin 2 presenta trabajos relacionados a la presente investigacin, la seccin 3 presenta la metodologa utilizada. Las secciones 4 y 5 discuten los resultados obtenidos, la seccin 6 presenta las conclusiones. 2. TRABAJO RELACIONADO Existen mltiples estudios relacionados con el mejoramiento de procesos de software y las pruebas de software en pequeas y medianas empresas [6, 8, 9, 16]. Se pueden utilizar diferentes modelos para evaluar el estado de los procesos que se siguen en una empresa o unidad desarrolladora de software [16], entre los cuales detacan CMMI, ISO 9001 e ISO 12207. Recientemente se han realizado muchos estudios sobre la aplicacin del modelo CMMI en particular para el mejoramiento de los procesos de software en empresas [3-6, 8, 9, 14, 21]. Day et al [3] describen un model de flujo de trabajo completo para que una compaa TIC alcance el nivel 3 de madurez CMMI. Este estudio lo realizaron en una compaa de consultora TIC de Nueva Zelanda. Los autores recomiendan que para implementar un modelo de proceso de negocio de forma exitosa y eficiente se necesita mucha planificacin, herramientas apropiadas, y mtodos y estrategias. Dounos y otros [4] enfatizan que los enfoques exitsosos de mejoramiento de procesos de software consideran y utilizan factores propios de la experiencia de las organizaciones, de tal manera que las actividades predefinidas del CMMI son adaptadas al entorno particular de la organizacin. Ekdahl et al [5] presentan la experiencia que ha tenido el Centro de Investigacin Corporativa ABB de Suecia en el uso de evaluaciones internas CMMI como un medio para mantener el enfoque de mejora. Algunas lecciones aprendidas que mencionan son:

Nunca subestimar el poder de un buen plan. Los representantes locales, de la organizacin, facilitan la logstica. Las entrevistas abiertas y honestas requieren de comunicacin e integridad. Buenas herramientas ayudan en el proceso. No pierda la oportunidad de realizar alguna capacitacin. Durante el desarrollo de nuestro proyecto, se aplicaron la mayora de estas lecciones. Por ejemplo, gracias a la experiencia del equipo evaluador, se desarroll un plan tanto para las valoraciones SCAMPI tipo C como para el proceso parcial de pruebas. As mismo, se incorpor a miembros de la Unidad de Sistemas durante la evaluacin y las pruebas. La inclusin de estos representantes locales nos permiti desarrollar cierta confianza, que a su vez facilit una comunicacin fluida y sencilla. Utilizamos herramientas fcilmente integrables a los ambientes de desarrollo y pruebas de la Unidad de Sistemas. Por ltimo, tenemos planeada una capacitacin al personal de la Unidad de Sistemas en la fase final del proyecto. A partir de los resultados observados en las primeras fases del proyecto (este estudio), desarrollaremos en conjunto con el Centro de Investigaciones en Tecnologas de Informacin y Comunicacin CiTIC, cursos de capacitacin que ayuden a la Unidad de Sistemas a mejorar sus procesos de desarrollo y pruebas de software. Huang y Zhang [6] exponen los problemas ms comunes que se han encontrado al implementar CMMI en empresas pequeas y medianas en China. Tambin ofrecen soluciones y un marco de mejora de proceso, que incluye los siguientes aspectos clave: La implementacin del CMMI debe estar integrada con el plan estratgico de desarrollo de la organizacin. Realizar un anlisis costo-beneficio de la implementacin del CMMI. Hacer una reduccin razonable en la implementacin del CMMI. Uso de herramientas adecuadas de apoyo en la implementacin del CMMI. Monteiro et al [14] proponen conciliar el nivel de madurez 2 del CMMI con las prcticas de verificacin y validacin que estn en el nivel 3 mediante la adopcin del estndar ISO/IEC 29119. Staples y Niazi [21] describen dos casos de estudio de empresas australianas pequeas que adoptaron CMMI para mejorar su proceso de software, ambas con motivaciones y preparacin organizacional distintas. De la comparacin concluyen que tener metas claras dentro de la organizacin puede ayudar a posicionar mejor la organizacin en su preparacin hacia un proceso de mejora de software. En el caso de Costa Rica, existen pocos estudios previos sobre mejoramiento de procesos de software [8, 9]. En

96

particular, Jenkins describe en [8] la experiencia de implementar mejoras del proceso de software basadas en CMMI en nueve organizaciones. El mismo autor describe en [9] una metodologa para realizar proyectos de mejora del proceso de software en organizaciones de TI, la cual se ha probado en 20 organizaciones y 6 pases diferentes a lo largo de 10 aos. Esta metodologa consiste de 17 pasos agrupados en cuatro fases. La siguiente seccin muestra la metodologa de trabajo que seguimos en nuestro estudio, tanto para realizar las pruebas a las aplicaciones como para realizar la evaluacin de los procesos de software de la Unidad de Sistemas. 3. METODOLOGA El presente trabajo se realiz en una de las tres Unidades de Sistemas que existen en la Universidad de Costa Rica. La Universidad de Costa Rica es una organizacin grande y compleja de hecho, es la universidad ms grande del pas, de ah que posea varias unidades gestoras de tecnologas de la informacin, algunas de las cuales desarrollan software para uso interno de la institucin. La Unidad en la cual desarrollamos nuestro trabajo tiene un portafolio amplio de proyectos, la mayora de los cuales son sistemas de informacin web conectados a bases de datos institucionales. Est conformada actualmente por un equipo de 10 personas. La intervencin en aseguramiento de la calidad realizada en esta Unidad tuvo dos componentes: un servicio parcial de pruebas a dos de sus sistemas, y una evaluacin parcial de su proceso de desarrollo de software. A continuacin de describen en ms detalle cada uno de estos componentes. 3.1 Servicio de Pruebas a Dos Aplicaciones El primer componente de la intervencin en aseguramiento de la calidad que se realiz en la Unidad de Sistemas consisti en un servicio de pruebas a dos aplicaciones desarrolladas por la Unidad. Dichas aplicaciones fueron elegidas por el director de la Unidad, con base en la factibilidad y conveniencia de someterlas a un proceso de pruebas. El servicio de pruebas brindado fue un proceso parcial de pruebas a ambas aplicaciones en el cual se probaron slo ciertos mdulos y ciertas caractersticas, por limitaciones de tiempo y personal. Debe aclararse tambin que nuestra intervencin a nivel de pruebas no contempl un acompaamiento desde el inicio del ciclo de vida de las aplicaciones es decir, actividades de verificacin en las etapas tempranas del desarrollo, debido a que las aplicaciones suministradas por la Unidad de Sistemas se encontraban ya en etapas avanzadas de desarrollo cdigo completo, pruebas finales, iniciando pilotos. Las dos aplicaciones que se probaron fueron desarrolladas en .NET con una arquitectura multicapas y una base de datos como back-end en un caso se

us Oracle y en el otro Microsoft SQL Server. Su interfaz era web y estaba protegida con autenticacin de usuarios. Infraestructura de Pruebas. Debido a que este proyecto fue uno de los primeros proyectos auspiciados por el CiTIC de nuestra universidad, no contbamos con una infraestructura tecnolgica establecida para la gestin del proceso de pruebas. As que una de las primeras labores de nuestro proyecto fue disear, instalar y probar la infraestructura de hardware, software, y comunicacin que permitiera gestionar el proceso de pruebas que se iba a implementar. La infraestructura diseada y utilizada se muestra en la Figura 1.

Fig. 1: Infraestructura para la gestin de las pruebas

A nivel de software, se decidi utilizar Microsoft Team Foundation Server 2010 [12] junto con Microsoft Visual Studio 2010 Ultimate [13], que incluye la aplicacin para pruebas Microsoft Test Manager 2010, dado que la Unidad de Sistemas utiliza preferencialmente tecnologa Microsoft para desarrollar sus sistemas. El hecho de utilizar la misma plataforma de software facilit la comunicacin e interaccin con el personal de la Unidad ya que ellos estaban familiarizados con el ambiente de Visual Studio y de Visual SourceSafe (precursor de TFS). As mismo, la utilizacin de VS2010 nos permitir en el futuro cercano realizar pruebas de caja blanca de forma natural y directa sobre el cdigo de las aplicaciones desarrolladas por esta Unidad, las cuales estn escritas en su mayora en .NET. A nivel de hardware, se instal un servidor de TFS2010 sobre Windows Server 2008. Tambin se instal el cliente VS2010 en las cuatro computadoras que utilizaban los miembros del equipo de pruebas. Adicionalmente, hubo que configurar la red de manera especial debido a que nuestra universidad maneja dos tipos de redes por asuntos de seguridad, y para lograr comunicarnos a travs del TFS con el equipo de desarrollo de la Unidad de Sistemas, tenamos que ser capaces de ver ambas redes simultneamente. Por otro lado, la aplicacin a probar (incluyendo servidor web de aplicaciones y servidor de base de datos) se instal en un servidor de pruebas del CiTIC (ver Figura 1) en uno de los casos. En el otro caso, por limitaciones de tiempo y recursos, se solicit a la Unidad de Sistemas que nos diera acceso a un servidor de pruebas de ellos, donde estuviera instalada la aplicacin.

97

Entregables. El proyecto contempl la entrega de los siguientes artefactos a la Unidad de sistemas: Plan de Pruebas Especificacin de Diseo de las Pruebas Reporte de Ejecucin de las Pruebas e Incidentes Para la confeccin del Plan de Pruebas, se utiliz como base el estndar IEEE 829 [7], con algunas adaptaciones para nuestro contexto. Este documento fue entregado fsicamente al director de la Unidad de y se solicit su aprobacin para proceder con las siguientes etapas. La Especificacin de Diseo de las Pruebas se realiz mediante las herramientas VS2010 y TM2010, conectadas a nuestro servidor TFS2010. Los casos de prueba se almacenaron en un proyecto de equipo (team project en el argot de Microsoft) dentro de una coleccin de equipo team collection en el argot de Microsoft del servidor TFS2010. Para disear las pruebas nicamente se utilizaron tcnicas de caja negra, especficamente anlisis de clases de equivalencia, anlisis de valores frontera, cobertura de casos de uso, e intuicin y experiencia. La ejecucin de las pruebas se realiz de forma manual, pero se almacen una bitcora de ejecucin de dichas pruebas de forma automatizada facilitado por las herramientas TM2010 y TFS2010. Los miembros de la Unidad de Sistemas que estaban involucrados en el proyecto tenan acceso de lectura al servidor TFS, de manera que ellos podan observar las pruebas que se estaban diseando, as como monitorear el avance de la ejecucin de las mismas. Esto evit tener que crear otro documento de texto con la especificacin de los casos de prueba, y agiliz bastante el proceso. El Reporte de la Ejecucin de las Pruebas y el Reporte de Incidentes se consolidaron en un solo documento que resuma las pruebas ejecutadas, las configuraciones utilizadas, y los resultados obtenidos al ejecutar las pruebas as como los incidentes defectos encontrados durante la ejecucin de las pruebas. Los incidentes de agruparon por mdulo y por severidad. Una gran parte de la informacin incluida en este reporte fue obtenida y procesada con las herramientas VS2010 y TM2010. 3.2 Evaluacin del Proceso de Desarrollo de Software Adems de llevar a cabo el proceso de pruebas descrito en la seccin anterior, nuestro proyecto contempl realizar evaluaciones SCAMPI tipo C [19] del proceso de desarrollo de software de la Unidad de Sistemas. Para ello utilizamos como base la constelacin CMMI-DEV 1.3 [2], al tratarse de una unidad de desarrollo y mantenimiento de software interno de nuestra institucin. En particular, nos enfocamos en evaluar las categoras de Ingeniera y Administracin de Proyectos del CMMI-DEV V1.3, que contienen un total de doce reas de proceso. Mtodo de evaluacin. Los resultados de la evaluacin SCAMPI tipo C [19] fueron documentados utilizando una

serie de workbooks de CMMI V1.3. La documentacin de los resultados le ayuda a la organizacin a identificar las brechas que se deben cerrar para lograr un mayor nivel de capacidad segn el modelo CMMI as como las fortalezas y oportunidades de mejora de cada una de las reas de proceso. El trabajo se realiz en el lapso de cinco semanas con la participacin de un equipo de trabajo de la Unidad de Sistemas. El esfuerzo rond entre dos y tres horas de trabajo por cada rea de proceso del CMMI. El mtodo SCAMPI [1] define tres tipos de evaluaciones del proceso de software: tipo A, B y C, dependiendo del nivel de detalle y formalidad que se desea obtener como resultado. Los resultados de las evaluaciones SCAMPI tipo A son las que se publican semestralmente [20]. En nuestro proyecto realizamos evaluaciones SCAMPI tipo C debido a que la organizacin apenas est iniciando su proceso de mejora y el objetivo de esta primera evaluacin era obtener un vistazo rpido sobre el estado del proceso actual con respecto al modelo CMMI-DEV V1.3 y determinar oportunidades de mejoras. Las evaluaciones SCAMPI tipo C realizadas en el marco de este proyecto verifican cubrimiento de la documentacin del proceso de software con respecto a las prcticas de las reas de proceso del CMMI. En ese sentido, es una evaluacin tipo anlisis de brechas, pero tambin verifica la implementacin de tales prcticas en los proyectos y procesos de la organizacin. El mtodo de evaluacin empleado es simple pero efectivo, y lo hemos utilizado anteriormente en diversas organizaciones de software con buenos resultados [4, 5]. La evaluacin se hizo mediante tres instrumentos: 1. Revisin de la documentacin existente, tanto impresa como digital. Para esto se tom en cuenta toda la documentacin que se encontraba elaborada, revisada y aprobada. 2. Sesiones de preguntas y respuestas (entrevistas) con el equipo de trabajo para profundizar en los detalles de la documentacin de procesos. 3. Revisin de la evidencia, tanto impresa como digital, de los proyectos y procesos en ejecucin para verificar la implementacin (uso) de los procedimientos, plantillas y otros artefactos descritos en la documentacin. Como resultado se obtuvo lo siguiente: 1. La lista de brechas (gaps) existentes en el proceso con respecto a las prcticas propuestas en el CMMI. Las brechas se clasifican segn su severidad en dos tipos: Amarilla: brecha leve, generalmente causada por falta de implementacin. Roja: brecha seria, generalmente causada por falta de documentacin o implementacin. 2. Grado de cubrimiento de cada una de las prcticas del CMMI.

98

Para la cuantificacin del grado de cubrimiento de cada prctica, definimos una escala de evaluacin de tres niveles para determinar el grado de cubrimiento de las metas y prcticas tanto especficas como genricas del CMMI, como se describe a continuacin: Rojo: prctica no cubierta del todo valor 0 Amarillo: prctica parcialmente cubierta valor 1 Verde: prctica completamente cubierta valor 2 Los porcentajes de cubrimiento de cada rea de proceso (PA) se calculan como promedios ponderados de la siguiente manera. Primero se suman el nmero de prcticas cubiertas verde ponderadas con un factor de 2 y el nmero de prcticas parcialmente cubiertas amarillo ponderadas con un factor de 1. Luego esa suma se divide entre el nmero total de prcticas del PA, ponderadas por un factor de 2 y as se obtiene el porcentaje de cubrimiento del PA:
%Cub. PA= (#Rojas*0)+(#Amarillas*1)+(#Verdes*2) X 100% # total de prcticas del PA * 2

Tabla 2. Cantidad de pruebas diseadas aplicacin 2 Mdulo A B C Total Cantidad de pruebas diseadas 21 21 27 69 Cantidad de pruebas ejecutadas 21 21 9 51

Para calcular el porcentaje total de cubrimiento de un grupo de PAs del CMMI por ejemplo, el grupo de PAs de una categora del CMMI o de un nivel del CMMI en la organizacin, se suman el nmero de prcticas cubiertas verde ponderadas por un factor de 2 y el nmero de prcticas parcialmente cubiertas amarillo ponderadas por un factor de 1, para todas las PAs del grupo. Luego el resultado de esa suma se divide entre el nmero total de prcticas del grupo de PAs ponderadas por un factor de 2, y as se obtiene el porcentaje de cubrimiento del grupo de PAs:
%Cubr. PAs = (#Rojas*0)+(#Amarillas*1)+(#Verdes*2) X 100% # total de prcticas CMMI evaluadas* 2

De las Tablas 1 y 2 se observa que se probaron ms mdulos y se realizaron ms pruebas sobre la primera aplicacin que sobre la segunda. Esto se debi a varios factores: (1) se cont con ms tiempo para el proceso de pruebas de la primera aplicacin que para el de la segunda, (2) la primera aplicacin era conceptualmente ms sencilla y fue mucho ms fcil asociar los casos de uso a la interfaz de usuario, mientras que en la segunda se dur bastante tiempo tratando de entender los casos de uso y cmo stos se reflejaban en la interfaz de usuario y (i3) para la primera aplicacin se utilizaron tres configuraciones distintas de pruebas variando el sistema operativo y el navegador, mientras que para la segunda aplicacin slo se utiliz una configuracin. Las configuraciones bajo las cuales se prob la primera aplicacin fueron: 1. Microsoft Windows XP + Internet Explorer 8.0 2. Microsoft Windows 7 + Internet Explorer 8.0 3. Microsoft Windows 7 + Firefox 3.0 Esto explica por qu en la Tabla 1 se reportan ms pruebas ejecutadas que diseadas, debido a que se trat de ejecutar la mayora de las pruebas en las tres configuraciones. En la Tabla 2 se reportan menos pruebas ejecutadas que diseadas debido a que hubo 18 pruebas que no se pudieron ejecutar del todo, ya que la funcionalidad que intentaban verificar no estaba accesible en el sistema, especficamente en el mdulo C. Las Tablas 3 y 4 muestran tanto el nmero de pruebas que pasaron como el nmero de pruebas que fallaron, por mdulo, para cada una de las aplicaciones en estudio. En resumen, de las 398 pruebas ejecutadas sobre la primera aplicacin 72% pasaron y 28% fallaron; mientras que de las 51 pruebas ejecutadas sobre la segunda aplicacin 61% pasaron y 39% fallaron. En la primera aplicacin, una gran parte de las pruebas, entre 68% y 84%, pas en todos los mdulos. En la segunda aplicacin, ms del 60% de las pruebas fallaron para uno de sus mdulos, lo cual evidentemente gener un mayor nmero de incidentes reportados en dicho mdulo (ver Tabla 6).
Tabla 3. Resultado de las pruebas aplicacin 1 Mdulo A B C D E Total Cantidad y porcentaje de pruebas que pasaron 89 68,5% 69 73,4% 48 68,6% 33 70,2% 48 84,2% 287 72,1% Cantidad y porcentaje de pruebas que fallaron 41 31,5% 25 26,6% 22 31,4% 14 29,8% 9 15,8% 111 27,9%

4. RESULTADOS DE LAS PRUEBAS Los resultados del proceso parcial de pruebas en dos aplicaciones de la Unidad de Sistemas fueron: Las Tablas 1 y 2 muestran tanto el nmero de pruebas diseadas como el nmero de pruebas ejecutadas, para cada una de las aplicaciones en estudio. En estas tablas se muestra la cantidad de pruebas, agrupadas por mdulo, donde cada mdulo corresponde a lo que la Unidad de Sistemas denomina un caso de uso de anlisis es decir, la separacin se realiz con base en la documentacin de la aplicacin suministrada por la Unidad, pero tambin se verific que a nivel de interfaz, la separacin modular fuera conveniente. Los nombres las aplicaciones y sus mdulos se omiten por razones de confidencialidad.
Tabla 1. Cantidad de pruebas diseadas aplicacin 1
Mdulo A B C D E Total Cantidad de pruebas diseadas 44 32 24 20 19 139 Cantidad de pruebas ejecutadas 130 94 70 47 57 398

99

Tabla 4. Resultado de las pruebas aplicacin 2

Mdulo A B C Total Cantidad y porcentaje de pruebas que pasaron 17 81% 8 38% 6 67% 31 72,1% Cantidad y porcentaje de pruebas que fallaron 4 19% 13 62% 3 33% 20 27,9%

Tabla 1. Distribucin de incidentes por mdulo y severidad aplicacin 2

Mdulo A B C Total Sev. 3 (mediana) 3 37 0 40 Sev. 4 (baja) 0 7 0 7 Total 3 44 0 47

Las Tablas 5 y 6 muestran el nmero de incidentes, por mdulo y por severidad, para cada una de las aplicaciones en estudio. Como se puede observar en estas tablas, la mayora de los incidentes encontrados fueron de mediana severidad. En la primea aplicacin se encontraron algunos de alta severidad, no as en la segunda aplicacin no se muestra la columna correspondiente a severidad 2 en la Tabla 6 ya que no hubo incidentes en esta categora. Ambas aplicaciones exhibieron pocos incidentes de baja severidad.
Tabla 5. Distribucin de incidentes por mdulo y severidad aplicacin 1
Mdulo A B C D E Total Sev. 2 (alta) 5 3 1 3 3 15 Sev. 3 (mediana) 9 4 6 2 1 22 Sev. 4 (baja) 0 1 0 1 1 3 Total 14 8 7 6 5 40

5. RESULTADOS DE LA EVALUACIN DEL PROCESO DE DESARROLLO A continuacin presentamos los resultados de las evaluaciones SCAMPI tipo C efectuadas en la Unidad de Sistemas. Las reas de proceso contempladas en la evaluacin fueron las cinco PAs de Ingeniera ms las siete PAs de Administracin de Proyectos del CMMI-DEV V1.3. La Tabla 7 muestra las PAs evaluadas, su categora y nivel de madurez. Al lado de cada PA se indica su acrnimo en ingls. La Tabla 8 resume los resultados de nuestra evaluacin de las cinco PAs de Ingeniera. Para cada PA, se muestran la cantidad total de prcticas evaluadas, la cantidad de prcticas por grado de cubrimiento: verde, cubierta, amarillo, parcialmente cubierta y rojo, no cubierta y el porcentaje de cubrimiento de la PA calculado segn la frmula %Cubrimiento PA. La ltima fila muestra los totales as como el porcentaje total de cubrimiento para todas las PAs de Ingeniera (calculado segn la frmula %Cubr.Gupo PAs.

Tabla 2. reas de proceso evaluadas rea de Proceso 1. Verificacin (VER) 2. Validacin (VAL) 3. Solucin Tcnica (TS) 4. Integracin del Producto (PI) 5. Desarrollo de Requerimientos (RD) 6. Planificacin de Proyectos (PP) 7. Seguimiento y Control de Proyectos (PMC) 8. Administracin del Riesgo (RSKM) 9. Administracin Integrada de Proyectos (IPM) 10. Administracin Cuantitativa de Proyectos (QPM) 11. Administracin de Requerimientos (REQM) 12. Administracin de Contratacin de Proveedores (SAM) Tabla 8. Cubrimiento de las reas proceso de Ingeniera
rea de proceso 1. VER 2. VAL 3. ST 4. PI 5. RD Cubrim. Ing. Prcticas 8 5 9 9 8 39 Cant. prcticas por grado de cubrimiento Verde Amarillo Rojo 2 4 2 1 2 2 2 2 5 0 3 6 5 3 0 10 14 15 % de cubrim. 50% 40% 33% 17% 81% 44%

Categora Ingeniera Ingeniera Ingeniera Ingeniera Ingeniera Adm. Proy. Adm. Proy. Adm. Proy. Adm. Proy. Adm. Proy. Adm. Proy. Adm. Proy.

Nivel de madurez 3 3 3 3 3 2 2 3 3 4 2 2

La informacin recolectada y los aspectos evaluados en cada sesin se introdujeron en formularios a partir de los cuales se generaron grficos que resumen el porcentaje de cumplimiento de las prcticas asociadas a cada rea de proceso evaluada. La Figura 2 muestra el grfico resumen del porcentaje de cubrimiento para las PAs de Ingeniera evaluadas.

Fig. 2: Cubrimiento de las 5 reas de proceso de Ingeniera

Los resultados del anlisis de brechas fueron documentados utilizando los workbooks del CMMI-DEV V1.3, desarrollados para tal efecto con base en las prcticas del modelo. Precisamente uno de los aportes ms significativos a la mejora del proceso de desarrollo

100

es la lista de brechas. A manera de ejemplo, la Tabla 9 muestra el resultado de la evaluacin de las prcticas y metas especficas del rea de proceso de Verificacin. En este ejemplo, se notan 2 metas en rojo no cubiertas en el proceso y una en amarillo parcialmente cubierta en el proceso. Esto refleja que existen en el proceso actual de desarrollo algunas prcticas de verificacin que estn siendo implementadas, pero en algunos casos no estn debidamente documentadas. Algunas prcticas sugeridas por el CMMI no estn del todo contempladas en el proceso actual que ejecuta la organizacin. Finalmente, las brechas encontradas en cada rea de proceso se documentan y clasifican segn su severidad en A amarilla, brecha leve, o R roja, brecha seria. A manera de ejemplo, la Tabla 10 muestra las brechas que se encontraron en el rea de proceso de Verificacin. De un total de 10 brechas, 8 se consideraron leves amarillo y 2 serias rojo.
Tabla 3. Evaluacin de las prcticas de Verificacin
Goals and Practices SG1 - Preparation for verification is conducted SP1.1 Select the work products to be verified and the verification methods that will be used for each SP1.2 Establish and maintain the environment needed to support verification SP1.3 Establish and maintain verification procedures and criteria for the selected work products SG2 - Peer reviews are performed on selected work products SP2.1 Prepare for peer reviews of selected work products SP2.2 Conduct peer reviews on selected work products and identify issues resulting from the peer review. SP2.3 Analyze data about preparation, conduct, and results of the peer reviews SG3 - Selected work products are verified against their specified requirements SP3.1 Perform verification on the selected work products SP3.2 Analyze the results of all verification activities and identify corrective action

cubrimiento para todas las PAs de Administracin de Proyectos.

Tabla 4. Brechas del rea de proceso de Verificacin
Brecha 1. No existe un procedimiento documentado para realizar verificaciones de productos de software. 2. Los mtodos de verificacin disponibles para productos de software especficos no estn documentados. 3. Los costos de R.H. encargados de la verificacin de productos (QA y usuarios) no estn cargados a los proyectos de desarrollo 4. La descripcin de los ambientes de pruebas y el procedimiento de paso de artefactos de un ambiente a otro no estn documentados. 5. Los procedimientos para verificacin de artefactos de software no estn documentados. 6. No se estn realizando actualmente revisiones de colegas de cdigo fuente. 7. Los procedimientos para realizar revisiones de colegas de artefactos de software no estn documentados. 8. No existe una base de datos digital en lnea con los resultados de las verificaciones de los artefactos de software (todo est en papel). 9. No existen mtricas de calidad resultado de las verificaciones de los productos de software. 10. No se realiza un anlisis sobre los resultados obtenidos de las verificaciones de los productos de software. Sever

A A A A A A A A
R R

Tabla 5. Cubrimiento de las reas de proceso de Administra-cin de Proyectos

rea de Proceso 1. PP 2. PMC 3. RSKM 4. IPM 5. QPM 6. REQM 7. SAM Cubrim. Admon. Proyecto Cant. de prcticas 14 9 7 13 8 5 8 64 Cant. prcticas por grado de cubrimiento Verde Amarillo Rojo 5 7 2 0 5 4 3 3 1 0 0 13 0 0 8 1 3 1 2 1 5 11 19 34 % de cubrim. 61% 28% 64% 0% 0% 50% 31% 32%

Las brechas le permiten a la organizacin identificar los aspectos especficos que debe mejorar en su proceso de desarrollo de software. En este ejemplo especfico, las dos brechas ms importantes claramente especifican que la organizacin debe iniciar la aplicacin de mtricas de calidad y productividad a las actividades de verificacin de productos de software que se realizan, incluyendo las pruebas, e implementar un proceso de anlisis de los resultados de las verificaciones para mejorar el proceso de software. Las dems brechas se consideran leves ya que no son causadas por la inexistencia de la prctica sino por la falta de documentacin de la misma. Por otro lado, tambin se evaluaron las reas de proceso de la categora de Administracin de Proyectos del modelo CMMI-DEV V1.3. La Tabla 11 resume los resultados de nuestra evaluacin de las siete PAs de Administracin de Proyectos. Para cada PA, se muestran la cantidad total de prcticas evaluadas, la cantidad de prcticas por grado de cubrimiento verde, cubierta, amarillo, parcialmente cubierta, rojo, no cubierta y el porcentaje de cubrimiento de la PA. La ltima fila muestra los totales as como el porcentaje total de

Fig. 3: Cubrimiento de las 7 reas de proceso de Administracin de Proyectos

La Figura 3 muestra el grfico resumen del porcentaje de cubrimiento para las PAs de Administracin de Proyectos evaluadas. En este caso, claramente se refleja que las reas de proceso de Administracin Integrada de Proyectos IPM y Administracin Cuantitativa de Proyectos QPM son particularmente dbiles debido a que la organizacin no cuenta con un sistema de mtricas de desempeo para los proyectos. Adicionalmente, las reas de proceso de Seguimiento y

101

Control de Proyectos PMC y Administracin de Contratacin de Proveedores SAM tambin se deben mejorar. La Figura 4 muestra el resumen final de la evaluacin realizada, donde cada barra representa el porcentaje de cubrimiento para las categoras de Ingeniera y Administracin de Proyectos, respectivamente, del CMMI-DEV V1.3. De esta figura se observa que el cubrimiento general para las reas de proceso de Ingeniera fue del 44%, mientras que para las reas de proceso de Administracin de Proyectos fue de 32%. Este resultado se debe principalmente a la falta de documentacin y evidencia de la ejecucin de muchas prcticas que, aunque en algunos casos se implementan en los proyectos, no estn debidamente documentadas en la definicin del proceso o no existe evidencia de su realizacin. En ambos casos, tales falencias se identificaron como brechas del proceso actual que deben ser mejoradas. Estos resultados tambin reflejan que existen grandes oportunidades de mejora que se pueden incorporar al proceso de desarrollo de software que efecta la Unidad de Sistemas.

unidades de desarrollo de software dentro de nuestra universidad que estn interesadas en realizar un trabajo similar en sus reas de proyectos de desarrollo de software para mejorar el proceso y formalizar las actividades de pruebas de los sistemas institucionales que desarrollan. El reto principal para una organizacin de software pequea como la descrita en este artculo es cmo invertir recursos en iniciativas de mejora del proceso sin desviar los escasos recursos, y a la vez mostrar resultados tangibles a corto y mediano plazo, de tal manera que esto permita persuadir a los stakeholders que la inversin se justifica. En se sentido, estamos actualmente orientando a la organizacin para que implemente las recomendaciones surgidas como resultado de este proyecto, tarea que estimamos que tomar entre seis y doce meses implementar. Al final de este periodo, realizaremos una segunda evaluacin SCAMPI tipo C para determinar el avance en el proceso de software en el cubrimiento del modelo CMMI. 7. AGRADECIMIENTOS Los autores agradecen al personal de la Unidad de Sistemas, as como a los investigadores colaboradores Marco Gonzlez, Eric Rojas, Mauricio Barrientos y Francisco Cocozza. Este proyecto fue apoyado por el Centro de Investigaciones en Tecnologas de la Informacin y Comunicacin y por la Escuela de Ciencias de la Computacin e Informtica. 8. REFERENCIAS
[1] Ahern, D. et al. 2005. CMMI SCAMPI Distilled. Appraisals for Process Improvement. Addison-Wesley. [2] Chrissis, M. B. et al. 2011. CMMI for Development: Guidelines for Process Integration and Product Improvement. Addison-Wesley. [3] Day, B. et al. 2009. The Ladder: CMMI Level 3. Proceedings of the International Enterprise Distributed Object Computing Conference. [4] Duonos, P. & Bohoris, G. 2010. Factors for the Design of CMMI-based Software Process Improvement Initiatives. Proceedings of the 14th Panhellenic Conference on Informatics. [5] Ekdahl, F. & Larsson, S. 2006. Experience Report: Using Internal CMMI Appraisals to Institutionalize Software Development Performance Improvement. Proceedings of the 32nd EUROMICRO Conference on Software Engineering and Advanced Applications. [6] Huang, D. B. & Zhang, W. 2009. CMMI in Medium & Small Enterprises: Problems and Solutions. Proceedings of the 2nd International Conference on Information Management and Engineering. [7] IEEE Computer Society. 1998. IEEE Std. 829.1998 Standard for Software Test Documentation. [8] Jenkins, M. 2007. Implementing Process Improvement in Nine Software Organizations: A Case Study. 2007 IRMA International Conference. [9] Jenkins, M. 2008. A Lean and Effective Methodology for Software Process Improvement. 6th Annual SEPG AU Australia Conference. [10] Kaner, C.; Falk, J. & Nguyen, H. Q. 1999. Testing Computer Software.

Fig. 4: % de cubrimiento de las categoras de Ingeniera y Administracin de Proyectos del CMMI-DEV V1.3

6. CONCLUSIONES La ejecucin del proceso parcial de pruebas a dos aplicaciones de la Unidad de Sistemas permiti detectar un total de 87 incidentes en ambas aplicaciones, los cuales fueron debidamente reportados a los encargados de la Unidad. Los encargados de la Unidad nos han indicado que estos incidentes sern priorizados y tomados en cuenta en una segunda versin de las aplicaciones, mejorando as la calidad de dichos sistemas. Adicionalmente esperamos que la metodologa seguida para desarrollar el proceso de pruebas as como las herramientas utilizadas para su gestin, sirvan como ejemplo de buenas prcticas de aseguramiento de la calidad para la Unidad, que actualmente est tratando de mejorar su proceso de pruebas para alcanzar una mayor calidad en los sistemas que desarrolla. La evaluacin SCAMPI tipo C de doce reas de proceso de Ingeniera y Administracin de Proyectos del modelo CMMI-DEV V1.3 detect importantes oportunidades de mejora en el proceso de desarrollo de software que esta Unidad realiza. Tales mejoras estn actualmente en proceso de implementacin. Actualmente hay otras dos

102

[11] Kaner, C. 2010. Software testing as a social science. STEP 2000 Workshop on Software Testing. [12] Microsoft. 2010. Microsoft Team Foundation Server 2010. Online. [13] Microsoft. 2010. Microsoft Visual Studio 2010 Ultimate. Online. [14] Monteiro, P.; Machado, R. J. & Kazman, R. 2009. Inception of Software Validation and Verification Practices within CMMI Level 2. Proceedings of the Fourth International Conference on Software Engineering Advances. [15] Pezz, M. & Young, M. 2008. Software Testing and Analysis: Process, Principles, and Techniques. Wiley. [16] Pino, F.; Garcia, F. & Piattini, M. 2009. Key processes to start software process improvement in small companies. Proceedings of the ACM Symposium on Applied Computing.

[17] Quality Assurance Institute. 2010. CSTE Common Body Of Knowledge V6.1. Online. [18] SEI. 2010. CMMI for Development, version 1.3. Technical report CMU/SEI-2010-TR-033. [19] SEI. 2010. Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) A, Version 1.3: Method Definition Document. [20] SEI. 2012. CMMI for SCAMPI Class A Appraisal Results 2011 End-Year Update. March 2012. [21] Staples, M. & Niazi, M. 2010. Two Case Studies on Small Enterprise Motivation and Readiness for CMMI. Proceedings of the 11th International Conference on Product Focused Software.

103

Requirements elicitation based on a product design approach Elicitacin de requisitos desde la perspectiva del diseo de producto
Ricardo Meja G.1, Alejandro Clad A.2, Daniel Zuluaga H.3
Universidad EAFIT. Medelln, Colombia. 1 rmejiag@eafit.edu.co 2 acaladal@eafit.edu.co 3 dzulua19@eafit.edu.co INFORMACIN DEL ARTCULO Tipo de artculo: Reflexin Historia del artculo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 10/06/2012 Palabras clave Ingeniera de Requisitos, diseo de producto, ciclo de vida del producto, desarrollo de software. Categories and Subject Descriptors D.2.1 [Software engineering]: Requirements General Terms Management, performance, human factors, theory. design,

ABSTRACT The aim of this article is to compare two different processes. These processes are product design and software development, specifically requirement identification and requirement engineering respectively. The research presents a review and a comparison of methods to obtain theirs similar aspects and uses this result to justify why could be possible to improve software development on the requirements elicitation phase by implementing an abstraction of concurrent engineering methods. RESUMEN Este artculo busca comparar los procesos relacionados con el diseo de producto y el desarrollo de software; especficamente la identificacin de necesidades en el desarrollo de producto y la ingeniera de requisitos en el desarrollo de software. La investigacin presenta una revisin y comparacin de mtodos, la obtencin de aspectos similares y cmo este resultado puede justificar una posible mejora al desarrollo de software en la fase de elicitacin de requerimientos mediante la implementacin de de mtodos adaptados de la teora de ingeniera concurrente.

Keywords Requirements engineering, product design, product lifecycle, software development.

1. INTRODUCTION In the first part of this article a brief state of the art of product design is presented as an introduction to support the proposal. It aims to contextualize the problem starting by defining product design, summarizing its evolution up until the latest trends such as concurrent and collaborative design. The second part presents a brief history of software engineering and its evolution, focusing in requirements elicitation and emphasizing in the collaborative aspect of the process. The third section tries to contrast collaborative product design with software development to get similar characteristics and to support the proposal. The last part presents the proposal, an implementation of collaborative identification techniques used in product design into the requirements elicitation stage of software development. 2. PRODUCT DESIGN HISTORY It is important to understand the definition of product development to help the readers relate it with software development. Product development is an interdisciplinary process conformed by different stages, which are performed by three different roles: marketing, design and manufacturing. The article focuses on product design to develop the arguments proposed here. According to this, some definitions of design will be given in this section.

Literature defines design in many different ways; e.g., one definition establishes that it is an action to create and elaborate something from an idea or also can be viewed as a specific way to image something [8]. The Oxford Dictionary defines design as a plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is made. Dieter and Schmidt adopted the following definition: Design establishes and defines solutions to and pertinent structures for problems not solved before, or new solutions to problems which have previously been solved in a different way [3]. According to the various definitions it is possible to say that design is a way to solve problems that have not been solved before; it is a problemsolving approach that is based on a cyclic and iterative process based on the problem characteristics that proposes a solution to it. At the begging of the design process there is not a problem as such, there are a set of necessities that are not well structured. To solve the problem, it is necessary first to define the problem itself. To do so, designers acquire the main characteristics of the problem and make an analysis and synthesis based on different aspects, among which are: actual state, user requirements, context, etc. This process if often called need analysis. The article focuses on this stage of the design process because it has the same objective of the

104

requirements elicitation process of software development, and also, due to the design project has the same kind of problems found in software development projects. The hypothesis of this work is that the experience acquired in product design, especially in need analysis, can be applied into software development to improve the resultant product. 2.1 Design process To talk about design process it is necessary to refer to Morris Asimow, which was one of the first to give a detailed description of the complete design process [3]. This author divides the design process into seven phases: Conceptual design. Through this process designers define a set of possible solutions, which then are reduced to a single one. To obtain a single solution there are a number of activities characterized by a high level of creativity and constant analysis of the enterprise environment. Identification of costumers needs, problem definition and gathering information are three some of the activities of these phase. Basically those activities are related with the elicitation of every aspect concerning the problem. Embodiment design. The concept that results from the conceptual design is structured based on decisions about materials, strength, size and others engineering matters. Making changes to the product after this phase results in huge costs to the project. Detail Design. As its name says, detailed engineering is made for every part of the producible product. Planning for Manufacture. Planning for Distribution. Planning for Use. Planning for Retirement of the Product.

related with functionality determine the success or the failure of the product. 2.3 Concurrent Engineering Product development process was initially a linear methodology, known as over the wall method. It takes the costumers necessities through the client to the final product. It started with marketing department that according to what they perceived from the user, wrote a list of requirements that were passed to the designers. Designers develop the product according to the requirements received from the marketing people. The specifications of the product, drawings, bill of materials, among others, were passed to the production team once the design was ready. The information moved only in a one-way, losing many important aspects and feedbacks resulted from the process. During the process there was not communication between the actors limiting the options and subsequently the resultant product. Another major drawback of this way of working was the developing time; it took too much time to develop a new product. Concurrent Engineering (CE) was born as a solution to the problems mentioned above and as a way to integrate the knowledge of the experts of every phase of the PLC with the development of the product. In literature there is not a unique definition of CE but Prasad in his book referenced a good approach of Winner et al. [11]. This definition said that CE integrates product development processes with every element of each phases of the PLC. With this approach designers have to work together with members owning knowledge of every phase of the PLC and this interaction changes how needs analysis are made. CE forces to create multidisciplinary engineering groups that include knowledge of the entire PLC changing the way of working and therefore the way how need analysis is made. 3. REQUIREMENTS ELICITATION BRIEF HISTORY The software development process involves all the activities regarding the creation of a computer program, since the conception of the desired software through the final materialization of it; ideally based in a planed and structured process. During this process, the earliest stage called conception phase, has as object to find out what problem needs to be solved by the implementation of the software, and hence identify system boundaries. That goal is accomplished by the Requirements Engineering (RE) [10]. RE could be defined as a multi-disciplinary humancentered process [10] belonging to the software system development specifically to its front-end phase. RE became recognized as an inchoate discipline, by the mid-1980 and since the early 1990s it has had its own conferences and a growing literature [6]. RE occurs early in the lifetime of a project, motivated by the evidence that requirement errors, such as

For the last four stages a well structured and detailed plan is defined for production, distribution, sale, use and disposal of the product. These stages are considered during the design process because Product Lifecycle (PLC) guides product engineering. 2.2 Product Lifecycle The PLC refers to every possible phase of a product during its life, since its conception to the aspects regarding to the end of its life. Stages of the PLC can be grouped in four areas: Product development, production and delivery, use, and end of life [4]. The importance of PLC in product design is that by considering those areas during the process, it is possible to improve the quality of the resultant products and minimize related cost. Also some important characteristics of the product are only discovered and included in the final concept when knowledge of each PLC area is considered in the early stages of the design process. Including those little details and many other important aspects that are not

105

misunderstood or omitted requirements, are more expensive to fix at later stages of the products lifecycle [1]. RE embraces a large spectrum of activities. It must span the gap between the informal world of stakeholder needs, and the formal world of software behavior. The key question over the use of formal methods is not whether to formalize, but when to formalize. It is because of this dissonance between the formal and informal worlds that requirement engineering is hard to apply and has wicked problems. The preliminary phase of the RE process involves knowledge acquisition in order to define the purpose for which the software must be created, considering the stakeholders (company, users) and the actual system information. Usually this knowledge covers the following [6]: Knowledge about the organization - its structure, business objectives, policies, roles and responsibilities. Knowledge about the domain in which the problem world is rooted - the concepts involved in this domain, the objectives specific to it and the regulations that may be imposed in it. Knowledge about the system -as-is- its objectives, actors, resources involved, tasks, workflows, and problems that arise in this context. For the RE process different tools and techniques are used, which draw upon a variety of disciplines, and the requirements engineer may be expected to master skills from a number of different disciplines. The choice between the different elicitation techniques depends on the time and resources available, as well as the kind of information that needs to be elicited. Different classes of elicitation techniques are showed next [10]. Traditional techniques include a broad class of generic data gathering techniques. (Questionnaires, surveys, interviews and analysis of existing documentation). Group elicitation techniques aim to foster stakeholder agreement and buy-in, while exploiting team dynamics to elicit a richer understanding of needs, including techniques such as brainstorming, focus groups, etc. Prototyping is used for elicitation where there is a great deal of uncertainty about the requirements, or where early feedback from stakeholders is highly needed. Model-driven techniques provide a specific model of the type of information to be gathered, and use this model to drive the elicitation process. These include goal-based methods and scenario-based methods. Cognitive techniques include a series of techniques originally developed for knowledge acquisition for

knowledge-based systems [14]. Such techniques include protocol analysis, laddering, card sorting and repertory grids. Contextual techniques emerged in the 1990s as an alternative to both traditional and cognitive techniques [5]. These include the use of ethnographic techniques such as participant observation. Within the previous classes of elicitation techniques, different explicit activities could be done in order to accomplish the entire RE process. The most common of these techniques are presented next in a deeper way; some of them are Artifact-driven techniques and others are Stakeholder-driven techniques. Background study (content analysis), to understand the system as-is. Data collection can be helpful for eliciting nonfunctional requirements, related to usability, performance and cost. Questionnaires: Specific questions to selected people. Repertory grids and card sorts are useful to acquire further information from available domain concepts. Storyboards and scenarios, to elicit or validate useful information from concrete examples of how things are running in the system as-is, or how they should be running in the system to-be. Interviews (structured or unstructured) support the elicitation of potentially important information that cannot be obtained through background study, i.e. descriptions of how things proceed really in practice, personal complaints or improvement suggestions. Observation and ethnographic studies that could reveal tacit knowledge that would otherwise not emerge trough previous techniques Group sessions, thanks to their informal style of interaction, can reveal aspects of the system as-is or issues about the system to-be that might remain hidden under formal interactions during interviews. After presenting a brief history of RE and specially the different techniques available for it, it is clear that there are too many ways to accomplish and to perform it properly. RE is crucial for the software development process. It is the most important activity in this kind of projects as other phases in the life cycle of software development are directly related with it. To support this fact, a survey conducted by Standish Group Study in 1994 shows that 13.1% of projects fail due to incomplete requirements and 8.8% of projects fail due to rapidly changing requirements [13]. All the previously presented activities and techniques for RE could be included in a specific RE model; although there is no ideal process established for it, it is

106

possible to define a good RE process model. On the work done by SHAMS-UL-ARIF, M. et al. in 2009 five different models were presented (Input/output of Requirements Engineering Process, Linear Requirements Engineering Process Model, Linear Iterative Requirements Engineering Process Model, Iterative Requirements Engineering Process Model and Spiral Model of Requirements Engineering Process) [13]. Each of the previously presented models for the RE process have their own pros and cons; the linear requirements engineering process, for example works as a base for some of the newest models proposed and some important changes, such as risk management, have been recently introduced in models such as the spiral model. Selection of a specific model for RE depend on each projects to be developed. The spiral model is of one of the existing methods to RE. Its showed in Figure 1.

groups implies a greater challenge in coordination, communication, decision-making, etc., so when you are trying to involve not only the development team in the process but also all the other actors these difficulties will surely arise. The evolution of product design has solved these kinds of issues by migrating from the former over the wall mentality to the concurrent engineering philosophy. To generate a deeper involvement of stakeholders in the process it is necessary to convert the requirements process into a more collaborative one that could be done in different locations and time, involving the extended enterprise concept introduced by Duffy & Tod in 2004. 4.1 Proposed approach According to the arguments presented above, it is proposed an adapted process which integrates concurrent engineering principles into RE. The proposal is composed by nine stages. Software Utility. Define what the software is going to be used for. It entails answering the following questions: What is the main goal of the application? Who is the main user? Is the application supporting a specific process of the company? Who are the people who will be affected by the development? Roles. Identify the required roles, in both side of the project, this means roles of the people who will be involve in the development team and in the client side. For the development team identify roles as software architect, requirements engineering, developers, testing engineering, data base expert, project manager, among others. In the client side there are two main roles: user(s) and project responsible. Interaction types. Doing the job in different locations and time-zones is common due to the fact that the increasing globalization process has made more and more companies every day work for external international companies (stakeholders) in foreign countries, making it necessary to clearly identify the type of interaction that is possible to have with the actors that must be included in the RE process. In concurrent engineering this identification is made based on the possibilities of time and location; see Table 1.
Table 1. Location vs Time [9] Time Same Colocated synchronous interaction Remote synchronous interaction Different Colocated asynchronous interaction Remote asynchronous interaction

Fig. 1: Spiral Requirements Engineering Model [15]

4. PRODUCT DESING AS A GUIDE TO SOFTWARE DEVELOPMENT As showed in sections 2 and 3, there are common factors and techniques between the Process of Product Design in the needs analysis stage and the software development process in the requirements elicitation stage. However, as product design has more history and experience than software development, its techniques and processes have undergone longer testing than requirements elicitation techniques and processes. Although some research had been done in this topic [2, 7], the proposed approach only focus in the requirements elicitation stage because it is the most important and sensitive part of the process. Thinking in software as a product that has a defined life cycle and taking into account the fact that solving problems in early stages of the development process is cheaper than do it later; the idea from concurrent engineering of involve as many actors as possible in early development stages is valid for software development as well. This would therefore imply involving as many stakeholders (users, company, developers) as possible into the requirements elicitation phase. Doing this brings many improvements to the project, but it is also common knowledge that working in large

Location

Same

Different

107

 Necessary tools. After identifying the type of interaction based on Table 1, the next step is to define the necessary tools to support it. There are four categories of tools to support collaborative work in the design process [9]: Functional tools: Specific software engineering task. E.g. IDES, UML tools, etc. Coordination tools: For task management e.g. Project management, e-project, workflow, etc. Communication tools: Support the cooperation, for communication and interaction. E.g. email, chats, videoconference, etc. Information management tools: To share and manage information and knowledge, facilitate to interchange results. E.g. Data Bases, data managers, code repositories, etc. A collaborative project, ideally must include at least one of each kind of tools, otherwise problems will arise [9]. Items to be checked. Based on the product theory presented by Pugh in 1991 for the generation of the Product Design Specifications (PDS) file in a product design project [12]. From the original proposal, 17 items were selected; the meanings of some of them were changed to fix in the context of software development. An adaptation of Pugh proposal for the RE process is showed in Figure 2.

To summarize, all the different roles implicated in the concurrent approach works together in a collaborative way, emphasizing in some items previously selected in the roles distribution phase. Each role uses collaborative tools to support the requirement definition. This approach can be seen in Figure 3.

Fig. 3: Roles and Items distribution

5. FUTURE WORK This process is an ongoing project which must be validated in a case study. The integrations of tools, roles and items defined must be tested in a concurrent application where the requirements quality must also be analyzed. It entails the conformation of work group working around a real software development project. 6. CONCLUSIONS A brief review of Product Design and Requirements Elicitation was done. Then based on the similarity of both processes and regarding the importance of them to create products that meet the costumers requirements, it was proposed a method for software development. The method is based on the concurrent engineering approach and takes into account the possible ways of interaction of the participants to indentify the kind of tools that can be use to support the different stages during the process. Furthermore, a list of items to be check was proposed. It helps requirements engineering in the definition of the software specifications. This list can be modified once the method is tested. By integrating concurrent engineering principles is it possible to develop better software since during the problem definition and the requirements analysis hidden requirements can be identified. Also by the interactions of roles some software functionalities can be indentified therefore, increasing client satisfaction. 7. REFERENCES
[1] [2] Boehm, B. W. 1981. Software engineering economics. Prentice-Hall. Boehm, B. W. 1984. Verifying and validating software requirements and design specifications. IEEE Software, 1(1), 75-88.

Fig. 2: Items to be check. Adapted from [12]

Roles distribution. At least one item must be assigned for each role. In some projects, could happen that not all the items have a role assigned. It depends of the project scope that could require different amount of items to be checked. Requirements classification. All the team based on the traditional Functional and Non-Functional classification makes this classification. Requirements prioritization. Once the classification is done the entire team selects one the main requirement and rates it with the highest value. This requirement works as reference for the remaining ones; none can have a higher priority than the main one. Requirements agreement. Finally requirement document must be approved for every member of the working team.

108

[3] [4] [5]

[6] [7]

[8]

Dieter, G. E. & Schmidt, L. C. 2008. Engineering Design. McGraw-Hill Higher Education. Filippi, S. & Cristofolini, I. 2010. The Design Guidelines Collaborative Framework. Springer. Goguen, J. A. & Linde, C. 1993. Techniques for requirements elicitation. Proceedings of IEEE International Symposium on Requirements Engineering, 152-164. Lamsweerde, A. V. 2009. Requirements engineering: from system goals to UML models to software specifications. Wiley. Lwgren, J. 1995. Applying design methodology to software development. Proceedings of the 1st conference on Designing interactive systems: processes, practices, methods, & techniques, 87-95. Luz, T. da et al. 2011. The Collaborative Product Design and Help to Decision Making: Interactive Mind-Mapping. Global Product Development. Bernard, A. (Ed.), Global Product Development, 237-244. Springer.

[9]

[10] [11] [12] [13]

[14] [15]

Meja, G. R. 2009. Modelos y Mejores prcticas para el diseo globalizado. Correa, V. S. (Ed.), El libro azul: Apuntes de Ingeniera y Diseo, 245-260. Editorial Universidad EAFIT. Nuseibeh, B. & Easterbrook, S. 2000. Requirements engineering: a roadmap. Proceedings of the Conference on the Future of Software Engineering, 35-46. Prasad, B. 1995. Concurrent Engineering Fundamentals: Integrated Product and Process Organization, Volume I. Prentice Hall. Pugh, S. 1990. Total Design. Addison-Wesley. Shams, U. A.; Qadeem, K. & Gahyyur, S. A. K. 2009. Requirements engineering processes, tools/technologies & methodologies. International Journal of Reviews in Computing, 6, 41-56 Shaw, M. L. G. & Gaines, B. R. 1996. Requirements acquisition. Software Engineering Journal, 11(3), 149165. Sommerville, I. & Kotonya, G. 2003. Requirements engineering: processes and techniques. John Wiley & Sons.

109

Implementation Methodology Software Test Plan based on the PMBOK Guide Metodologa de Ejecucin del Plan de Pruebas de Software basado en la gua PMBOK
Docente Universidad Tecnolgica de Pereira. Pereira, Colombia. levayala@utp.edu.co. Estudiante Universidad Tecnolgica de Pereira. Pereira, Colombia. jorgesuarezch@gmail.com. 3 Estudiante Universidad Tecnolgica de Pereira. Pereira, Colombia. angelytocardona@gmail.com.
1 2

Luz E. Valencia1, Jorge L. Suarez2, Anglica M. Cardona3

INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin Historia del artculo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 05/06/2012 Palabras clave Plan de Pruebas, calidad, PMBOK, proyecto, casos de prueba, trazabilidad. Categories and Subject Descriptors D.2.4 [Software Engineering]: Management. General Terms Software Testing. Keywords Test Plan, quality, PMBOK, project, test case, traceability.

ABSTRACT The testing plan is a document which records the tests to be done to a software. Many times there are difficulties executing this plan. In this paper we propose to model the execution of a testing plan as a project in order to apply it using a recognized and tested standard, the PMBOK (Project Management Body of Knowledge). This paper specifies how to apply the PMBOK to the execution of the testing plan. RESUMEN El plan de pruebas es un documento donde estn consignadas las pruebas a realizar de un software, tal como un mapa. Sin embargo, en mltiples ocasiones se tiene problemas a la hora de cumplir con este plan. Es por esto que se pens en mirar la ejecucin de este como un proyecto y aplicarlo con un estndar reconocido y probado que ha brindado buenos resultados, el PMBOK (Project Management Body of Knowledge). En este documento se especifica cmo aplicarlo a la ejecucin del plan de pruebas.

1. INTRODUCCIN La utilizacin de la gua del PMBOK [4] a la ejecucin del plan de pruebas, surge del grupo de investigacin Grande de la Universidad Tecnolgica de Pereira, un proyecto denominado Laboratorio de Pruebas de Software. Este proyecto consiste en conformar un laboratorio que preste el servicio de pruebas de software (inicialmente pruebas funcionales) para las empresas de desarrollo de software ubicadas en las ciudades de Pereira, Manizales y Armenia. Cabe aclarar que el propsito del laboratorio es encaminar a las pequeas y medianas empresas de la regin, dedicadas al desarrollo de software, hacia el desarrollo de software con calidad. Con el fin de obtener un buen desempeo este centro de aseguramiento de calidad para los productos de software, se requiere tener agilidad, rendimiento y organizacin al momento de administrar los proyectos. Se considera proyecto todo aplicativo con la documentacin respectiva que llega al laboratorio para ser probado. Lo mnimo que se espera en la documentacin del software es: el documento de requerimientos y un diseo del aplicativo, de tal forma que se conozcan los resultados que se esperan de la aplicacin. Inicialmente se debe firmar un acta de constitucin para el proyecto, en la cual se estipula que el laboratorio va a realizar especficamente ciertos tipos de pruebas, sobre

un determinado software en proceso de desarrollo. Luego viene la etapa de planeacin, que consiste en escribir el plan de pruebas para ms tarde disear los casos de prueba, ejecutarlos y presentar un informe final a la empresa contratante, que se denominar cliente. Durante todo este proceso se debe vigilar el cumplimiento del cronograma de trabajo. La metodologa propuesta para el laboratorio de pruebas de software, facilita el funcionamiento al entregar un orden para administrar los proyectos que llegan, y es esencial por la cantidad de proyectos esperados que pueden encontrarse con avances diferentes. Esta metodologa debe estar soportada en un aplicativo que se construir una vez probada y validada la metodologa. 2. EL PLAN DE PRUEBAS El plan de pruebas es un documento especificado en la IEEE 829 [2], los tems presentados a continuacin presentan una ligera modificacin respecto al estndar, de tal forma que se adapte a las necesidades del laboratorio de pruebas: Identificador nico de plan de pruebas. Es el nombre que se le da al plan de pruebas, dicho nombre debe ser nico y estar relacionado con el alcance del plan. Alcance. Se identifican el tipo de prueba a realizar y las propiedades y elementos que se van a probar.

110

 Elementos. Son de dos tipos y se deben especificar los que pertenecen al plan y qu funcin cumplen dentro de ste, es decir, configuracin, requisitos, condiciones mnimas, entre otros: Documentos y Programa o mdulos. Estrategia. Se especifican tcnicas, patrones y herramientas para disear casos de prueba as como grado de automatizacin y nmero mnimo de casos de prueba. Caractersticas. Se debe especificar cules caractersticas se prueban y cules caractersticas no se prueban. Categorizacin de la configuracin. Se especifican bajo qu condiciones una prueba debe ser suspendida, repetida o culminada. En lo posible especificarse por cada tipo de prueba a realizar. Entregables. La funcin de las personas que realizan las pruebas es reportar los errores y fallas encontrados; en estos documentos llamados reportes se deben especificar el error o la falla, que periodicidad tienen y/o bajo cuales condiciones se presentan, a dems de la informacin de quien presenta el reporte, y la informacin de quien recibe el reporte. Recursos. Comprende el hardware, software y el talento humano requerido para realizar las pruebas. Para cada recurso se debe especificar la cantidad, las caractersticas, el tiempo y el para qu se necesita. Tambin se debe sealar cuando se requieran recursos especiales, como por ejemplo un especialista en un tema especfico. Calendario. Cada actividad debe tener una fecha, un responsable, el cargo del responsable y en caso de ser dependiente de otra actividad especificar la actividad precedente. Tambin debe existir un responsable general del cronograma y los hitos deben verse resaltados. Manejo de riesgos. Cada riesgo consignado debe tener una accin mitigante (prevencin), y una accin de contingencia (correccin). Los riesgos deben tomarse en cuenta por su alto impacto o por su alta probabilidad de ocurrencia. 3. LA METODOLOGA DEL PMBOK APLICADA AL PLAN DE PRUEBAS El funcionamiento del laboratorio de pruebas consta de cuatro etapas por las cuales debe pasar cada proyecto. Las etapas tienen propias de si unas entradas, unas actividades a realizar y unas salidas, las entradas son entregables que se requieren para realizar las actividades, las actividades son las acciones a realizar en la etapa y las salidas son entregables que se requieren para la siguiente etapa o para finalizar el proceso, como es el caso de las salidas en la etapa de evaluacin. Se describe a continuacin cada una de las etapas.

3.1 Planeacin La etapa de planificacin esta a cargo de los probadores o tester, quienes basados en el documento de requerimientos deben realizar el plan de pruebas y la EDT [5] (Estructura de Desglose de Trabajo). El documento de requerimientos es el punto de partida y un elemento fundamental para la construccin de un plan de pruebas exitoso, por tal motivo el laboratorio le debe dar una alta prioridad a las tareas de verificacin y validacin de los requerimientos, garantizando as, que estos sean claros, coherentes y nicos. Luego, basado en la EDT, se realiza el cronograma y se procede a buscar la aprobacin por parte del cliente del plan de pruebas. Esta etapa se representa en Figura 1.

Fig. 1: Etapa de Planificacin

La EDT es una descomposicin jerrquica orientada al entregable, en otras palabras es un rbol por niveles donde cada nodo representa un entregable, y cada nivel del rbol (en profundidad) representa el nivel de detalle de cada entregable, es decir, entre ms niveles tiene un rbol, ms detalle hay en las especificaciones de las actividades para conseguir dicho entregable. El hecho de saber cules son los entregables del proyecto, facilita al laboratorio, determinar las actividades para cada entregable y asignar los tiempos de duracin de dichas actividades; de esta forma se construye un cronograma mucho ms ajustado a la realidad, en trminos de tiempo y recursos. Se considera, que el laboratorio de pruebas de software requiere como mximo el tercer nivel de profundidad, debido a la naturaleza tcnica de las actividades de las pruebas, un mayor nivel sugiere tener un mayor nivel de detalle en las actividades lo que constituye o se convierte en un gasto innecesario de tiempo en esta etapa. Finalmente, cuando se obtiene el plan de pruebas aprobado por el cliente, se da inicio a la etapa de diseo. 3.2 Diseo Luego se realizar la etapa de planeacin se debe continuar con la etapa de diseo, como se representa en Figura 2, la cual consiste en elaborar los casos de prueba y la matriz de trazabilidad de acuerdo con el documento de requerimientos y el plan de pruebas.

111

Fig. 2: Etapa de Diseo

Fig. 3: Formato Casos de Prueba

Un caso de prueba, segn la IEEE 610 [1], se define como un conjunto de entradas, precondiciones de ejecucin, resultados esperados y post-condiciones de ejecucin, desarrollados para un objetivo particular o condicin de prueba, en otras palabras, son un conjunto de condiciones o variables bajo las cules se determina si un requisito es parcial o completamente satisfactorio. El objetivo principal en esta etapa, es disear los casos de prueba y la matriz de trazabilidad. Los casos de prueba se van a disear a partir de los requisitos, es decir, se listan y enumeran los requisitos y se construyen los casos de prueba para esos requisitos con base en el plan de pruebas. Este mtodo permite que el tester tenga claridad sobre los requisitos y se asegure que los casos de prueba comprueben que aplicativo hace lo que debe hacer y no hace lo que no debe hacer, o sea, se asegure que los casos de prueba se ajustan de manera precisa a comprobar que los requisitos funcionales del usuario se convirtieron en las funcionalidades del aplicativo. No existe una relacin matemtica que permita identificar cuantos casos de prueba se deben realizar para garantizar que un software cumple adecuadamente con los requisitos del usuario debido a la diversidad de requisitos para los programas, sin embargo, a travs del anlisis que debe hacer el tester al disear el caso de prueba, se puede medir la cobertura, el alcance y la efectividad que tienen los casos de prueba en conjunto, y si dichos casos de prueba se alinean con el plan de pruebas. En la Figura 3 se presenta el formato de casos de prueba a utilizar en el laboratorio. Este formato contiene los siguientes campos: ID de CP: Identificador de caso de prueba. Descripcin paso a paso: listado y numeracin de pasos para ejecutar la prueba. Entradas: V, cuando el dato a ingresar debe ser vlido; y NV, cuando el dato a ingresar debe ser invlido. Resultado Esperado: S, cuando el resultado esperado debe ser satisfactorio para el tester; y NS: cuando el resultado esperado es no satisfactorio para el tester. Resultado Obtenido: S, cuando el resultado obtenido fue satisfactorio para el tester; y NS: cuando el resultado obtenido fue no satisfactorio para el tester.

La manera de diligenciar el formato, es darle un identificador nico al caso de prueba, determinar los pasos a seguir, y luego las entradas que deben tener esos pasos. Se determin que es ms efectivo consignar en el formato la validez de las entradas a tener que consignar all mismo el dato a utilizar en la entrada y las caractersticas de dicho dato. Pues agiliza el proceso, el hecho de tener un conjunto de datos a utilizar, previamente seleccionado para cada caso de prueba, y as ejecutar el mismo caso con diferentes datos, es decir, hacer flexible para ajustes los casos de prueba sin perder las caractersticas de los datos que se explican adelante en esta misma fase. Es de notar que: Los resultados obtenidos se consignan a medida que se ejecuta la prueba (etapa de ejecucin). Existen tantos resultados esperados y resultados obtenidos como entradas. La cantidad de entradas es n, dependiendo de los campos de entrada de datos del aplicativo. Cada una de las entradas, debe especificar a qu campo del aplicativo hace referencia. La eleccin de datos es uno de los aspectos ms importantes del diseo de un caso de prueba, pues con una seleccin cuidadosa de los datos es posible lograr mejor cobertura con los casos de prueba a disear y brindar ms confianza en el desempeo funcional del software. Se busca que los datos seleccionados permitan encontrar la mayor cantidad de errores con la menor cantidad de casos de prueba. Esos datos deben cumplir como mnimo con tres caractersticas, como se especifica en SWEBOK [3]: Amplitud: es la cantidad de datos que sern utilizados para realizar la prueba. Alcance: variacin en los datos de prueba, los datos similares no proporcionan resultados objetivos. Profundidad: es la relevancia en los datos de prueba, es necesario variar los datos de extremo a extremo para garantizar una cobertura ptima. Luego de disear los casos de prueba se organizan con los requisitos en la matriz de trazabilidad. Dicha matriz consiste en listar los requisitos en la primera columna y los casos de prueba en la primera fila, luego se establecen las dependencias entre ellos marcando las celdas que los relacionan, como se muestra en la Figura 4. R: Requisito, CP: Caso de prueba.

112

Fig. 4: Matriz de Trazabilidad

Este esquema permite visualizar cules requisitos estn por fuera de los casos de prueba. Adems, cuando se realicen cambios en los requerimientos es posible identificar cuales casos de prueba se ven afectados al realizar los cambios, por lo cual la matriz de trazabilidad se convierte en un mecanismo de control, para gestionar cambios y para garantizar que existen los suficientes casos de prueba para los requerimientos existentes, estos beneficios de la matriz se ampliarn en la etapa de ejecucin. Cuando en el plan se especifiquen pruebas automatizadas, es necesario que adems de los casos de prueba, se diseen los scripts para las pruebas automatizadas. Estos scripts deben respetar todas las especificaciones dadas en el plan para la automatizacin, en grado de automatizacin, tcnicas y herramientas a utilizar, y dems. Finalmente se obtienen los casos de prueba para ejecutarlos en la siguiente etapa y la matriz de trazabilidad como mecanismo de control. 3.3 Ejecucin Consiste en ejecutar los casos de prueba diseados en la etapa anterior, como se observa en la Figura 5. Para esta etapa se requiere tener a la mano el documento de requerimientos, los ejecutables de la aplicacin, los casos de prueba diseados, y el formato de bugtracker (Figura 6). El bugtracker permite consignar las fallas encontradas en el sistema de una manera sencilla, de tal forma que sea simultnea la ejecucin de las pruebas y la consignacin de las fallas encontradas.

Severidad: Qu tan difcil es solucionar el error? (Alto, Medio, Bajo, No Establecida) Prioridad: Es urgente? (Crtica, Alta, Media, Baja) Tipo: Consideracin: debe ser tomado en cuenta. Sugerencia: No es necesario solucionarlo. Error: Es necesario solucionarlo. Hallazgo: No se esperaba encontrarlo. Naturaleza (Documentacin, Ambiente, Desarrollo) Estado: Abierto: No se ha solucionado. Cerrado: fue solucionado satisfactoriamente. Reabierto: se haba corregido y volvi a aparecer. Retroalimentacin: la solucin no fue satisfactoria. Reproducible Se repite? (Siempre, A veces, Nunca) Resolucin Cundo se va a solucionar? (Siguiente Versin, No Resuelto, Para Disear)

Fig. 6: Formato Bugtracker

Cuando una falla es encontrada al software es posible que esta detenga la ejecucin de las pruebas, segn la categorizacin de la configuracin, especificado en el plan de pruebas. Las fallas y/o errores encontrados adems de quedar consignadas en el bugtracker, darn paso a generar un reporte para el cliente quien los corrige y devuelve los ejecutables y/o documentos al laboratorio para ser probados nuevamente. Este reporte del cliente es una copia del bugtracker diligenciado, pues permitir ahorrar tiempo y entregar la informacin completa y clara de la falla y/o error encontrado. Existen dos causas por las que se podra modificar la EDT y el cronograma, la primera por fallas y/o errores encontrados y la segunda por cambios en los requerimientos por parte del cliente. Ambas causas tienen como consecuencia la prolongacin de las actividades por realizar y posiblemente impacto sobre el costo del proyecto. La primera causa va a ser manejada a travs de la gestin el tiempo, que consiste en pausar el cronometro del proyecto e iniciar el cronometro de espera por solucin hasta que el cliente devuelva las correcciones correspondientes. Una vez estn en el laboratorio los ejecutables corregidos se contina el cronometro del proyecto, y se vuelve a la etapa de ejecucin, se debe comprobar que las fallas encontradas son resueltas satisfactoriamente y que los otros requisitos continan funcionando correctamente. Es aqu donde cobra importancia el estado en el bugtracker (abierto, cerrado, reabierto o retroalimentacin) porque si una falla es

Fig. 5: Etapa de Ejecucin

En cada lnea del formato bugtracker, queda consignada una falla encontrada, de esta se debe especificar: Identificador del caso de prueba. Descripcin: Cul es la falla? Impacto: Alto, Medio, Bajo

113

encontrada recurrentemente aqu queda evidenciado y posiblemente se haga un seguimiento hasta encontrar la causa del problema y solucionarlo satisfactoriamente. Para la segunda causa, es necesario hacer gestin de cambios, soportados en la matriz de trazabilidad realizada en la etapa de diseo, que permite saber cules son los casos de prueba que se deben modificar y que otros casos de prueba se ven afectados. As que se hace necesario volver a la etapa de diseo, rediseando los casos de prueba afectados directa e indirectamente y el proyecto volverse a ejecutar, comprobndose que los cambios fueron implementados debidamente. Podra suceder que se presenten las dos causas simultneamente, en tal caso se debe parar el cronometro del proyecto y luego: 1. Verificar que los requisitos nuevos cumplan con las caractersticas mnimas. 2. Identificar los requisitos a modificar y a eliminar. 3. Depurar los casos de prueba y las fallas y/o errores encontrados de los requisitos a modificar o eliminar 4. Insertar los nuevos requisitos y ajustar los casos de prueba. 5. Ajustar el cronograma y la EDT. Como ya se haba mencionado ambas causas pueden producir, la modificacin de la EDT y el cronograma de trabajo, de tal forma que reajustarlos implica un tiempo extra por parte del tester. Para amortiguar este efecto, se clasifican los reajustes del tiempo de desfase como de alto impacto y de bajo impacto. Cuando el proyecto se desfasa por encima del 20% del tiempo de ejecucin del proyecto (Ley de Paretto 80/20 [7]) se considera de alto impacto, entonces se ajusta la EDT y el cronograma. Luego que sean resueltas las fallas encontradas, gestionados los cambios y se compruebe que el software funciona bien con respecto a los requerimientos, se da por terminada la etapa de ejecucin. Se considera que si el alcance es modificado por la entrada de nuevos requerimientos, se hace necesario modificar el contrato. Otros aspectos a tener en cuenta son la forma de comunicacin con el cliente, que debe permitir agilizar las actividades a realizar, se propone utilizar herramientas de video conferencias; y que la metodologa debe aplicarse a travs de un sistema de informacin (software) pues de otro modo sera tedioso y muy difcil llevar a cabo el proceso de pruebas. Finalmente, se obtiene la informacin para redactar el informe del cliente (bugtracker diligenciado), con los estados de todas las fallas y/o errores encontrados en los casos de prueba. Este documento, sirve como insumo para la etapa final del proyecto. 3.4 Evaluacin Esta etapa inicia cuando se ha definido el estado de la resolucin de las fallas y/o errores encontrados y han quedado por escrito, como se observa en la Figura 7.

Consiste en redactar y entregar los informes de las pruebas al cliente, con base en el reporte de fallas consignadas en el bugtracker. Este informe debe estar detallado de tal forma que sea entendible para el cliente, que fallas se encontraron y en que estado quedaron.

Fig. 7: Etapa de Evaluacin

El informe final, tambin incluye los indicadores que se le toman a la empresa desarrolladora, esos indicadores son: nmero de fallas encontradas en la aplicacin, numero de errores encontrados en la documentacin y el tiempo tomado por los desarrolladores para solucionar las fallas. Lo que permite que el empresario conozca el desempeo real de su organizacin, evale su empresa, encuentre sus falencias en el proceso de desarrollo, y trace polticas que encaminen a la empresa hacia el desarrollo de software con calidad. En la Figura 8 se muestra un certificado modelo y el formato del informe a presentar al cliente.

Fig. 8: Formato de Informe para el cliente

En esta etapa tambin se debe expedir un certificado que puede ser: de aceptacin, condicionada o de no certificacin. La certificacin de aceptacin se expide cuando el software cumple con los requerimientos de calidad y las fallas encontradas fueron solucionadas satisfactoriamente [6]. La certificacin condicionada se expide cuando existen fallas y/o errores sin ser solucionados satisfactoriamente y la no certificacin se

114

expide cuando el software no cumple con los requerimientos entregados por el cliente, lo que indica que el software no cumple con la definicin de calidad. Finalmente, se realiza el proceso de cierre del proyecto, que consiste en entregar el certificado y el informe al cliente y consignar en un acta la culminacin del contrato. 4. BENEFICIOS DE EJECUTAR EL PLAN DE PRUEBAS A TRAVS DE LA METODOLOGA PMBOK Los clientes tienen la capacidad de hacer comparaciones reales entre los proyectos, de tal forma que sea medible la eficiencia y la eficacia a travs de los estadsticos entregados por el laboratorio de pruebas. Obtener indicadores estadsticos confiables en cada proyecto, lo cual permitir a los clientes mejorar sus procesos. Optimizar el tiempo de duracin de un proyecto en el laboratorio de pruebas. Tener un sistema de informacin homogneo y estndar para el laboratorio de pruebas, de tal forma que obtener informacin de ste sea ms fcil. 5. CONCLUSIONES La metodologa hace ms eficiente la ejecucin del plan de pruebas utilizando herramientas de la gua PMBOK, de tal forma que considera en s las pruebas de un software en construccin un proyecto a realizar. El plan de pruebas constituye la base para la etapa de planeacin del proyecto, mientras que la EDT es la base para ajustar el proyecto en recursos y tiempo dentro del cronograma.

La etapa de diseo se centra en construir casos de prueba que permitan encontrar la mayor cantidad de fallas y/o errores con la menor cantidad de casos de prueba y hacerlos ms confiables, mediante la seleccin cuidadosa de los datos. La etapa de ejecucin se centra en realizar las pruebas diseadas, hasta que sean ejecutados todos los casos de prueba y se determine el estado de todas las fallas y/o errores encontrados, que es requisito para emitir el informe al cliente. La modificacin del alcance consignado en el plan de pruebas, causa la modificacin del contrato entre el cliente y el laboratorio. La gestin de tiempos esta orientada a identificar cual de las partes ocasiona la mayora de retrasos en el proyecto. La etapa de evaluacin presenta claridad sobre los documentos a entregar al cliente, por lo que cierra satisfactoriamente el proceso de pruebas. 6. REFERENCIAS
[1] IEEE Computer Society. 1990. Standard Glossary of Software Engineering Terminology. Standard 610-1990. [2] IEEE Computer Society. 1983. Standard Software Test Documentation. Standard 829-1983. [3] IEEE Computer Society. 2004. Guide to the software engineering body of knowledge SWEBOK. Computer Society. [4] Project Management Institute. 2008. Fundamentos para la direccin de proyectos: Gua PMBOK. PMI Book Service Center. [5] Fine, M. R. 2002. Beta Testing for Better Software. 2002. Wiley. [6] Valencia, A. L. E.; Villa, P. A. & Ocampo, C. A. 2009. Modelo de calidad de software. Scientia et Technica, 15(42), 172176. [7] Corporacin 3D. Principio de Pareto. Online: [Feb. 2012].

115

Contrast between a traditional software development method and BMP incorporation during the requirements analysis phase Comparativo para la fase de anlisis de requisitos entre un mtodo de desarrollo de software tradicional vs la incorporacin de BPM
Luis Merchn P.1, Diego A. Gmez M.2, Eunice Borja O.3, Mara E. Flrez O.4, Paola A. Torres L.5
1 2

Profesor Universidad de San Buenaventura. Cali, Colombia. lmerchan@usbcali.edu.co. Profesor Universidad de San Buenaventura. Cali, Colombia. dagmosqu@usbcali.edu.co. 3 Egresada Especializacin en Procesos para el Desarrollo de Software, USB Cali. Eunice_borja@eficacia.com.co. 4 Egresada Especializacin en Procesos para el Desarrollo de Software, USB Cali. meflorez2000@yahoo.com. 5 Egresada Especializacin en Procesos para el Desarrollo de Software, USB Cali. paotole@gmail.com. INFORMACIN DEL ARTCULO Tipo de artculo: Reflexin Historia del artculo Recibido: 30/04/2012 Correcciones: 24/05/2012 Aceptado: 30/05/2012 Palabras clave Gestin de procesos elicitacin de software. de negocio,

ABSTRACT The requirements analysis process is, undoubtedly, the mechanism to establish the conditions under which the different phases of software development life cycle are to be created. A flawless interrelationship among the corporate goals, the corporate environment and the requirements should lead to success through better indicators in resources, time and cost. A method of analyzing requirements under the perspective of the processes redesign through BPM (Business Process Management) is proposed and validated. In its application to a case study, this method shows commendable performance indicators when compared to the traditional method of analyzing requirements. RESUMEN El proceso de anlisis de requisitos constituye sin lugar a dudas el mecanismo a partir del cual se establecen las condiciones bajo las cuales se adelantarn las diferentes fases del ciclo de vida de desarrollo de software. Una buena interrelacin entre las metas organizacionales, entorno organizacional y los requisitos debe conducir al xito mediante el logro de mejores indicadores en las restricciones de recursos, tiempo y costo. Se propone y valida un mtodo de anlisis de requisitos contemplado bajo la ptica del rediseo de procesos mediante BPM (Business Process Management) el cual en su aplicacin para un caso de estudio muestra indicadores de resultado halagadores frente al mtodo tradicional de anlisis de requisitos.

Categories and Subject Descriptors D.2.4 [Software Engineering]: Elicitation methods, Methodologies. General Terms Requirements Engineering. Keywords Business process software elicitation. management,

1. INTRODUCCIN Cada vez que en el campo organizacional aparece una ola en cuanto a estrategias para el mejoramiento del modelo organizacional, es costumbre proceder a su implementacin directa. Lo vivieron las organizaciones con Total Quality Management TQM, Business Process Reenginering BPR, Enterprise Resource Planning ERP y Six Sigma, solo para mencionar algunas. Estas estrategias buscan proveer mecanismos que facilitan la optimizacin de procesos con miras a que las organizaciones sean ms eficaces, eficientes y giles; en otras palabras, ms competitivas con el fin de responder a los grandes retos que en su momento los mercados e industria exigen. BPM no ha sido la excepcin y las empresas estn asumiendo procesos de implementacin bajo diferentes perspectivas debido a la incertidumbre conceptual sobre su contexto, beneficios y retos: unas asumen los proyectos como implementacin tecnolgica y otras como un proceso de rediseo de procesos [1, 2]. Alinear el conocimiento del contexto del negocio necesidades y expectativas del modelo de negocio con los requisitos funcionales requisitos del modelado de software y su posterior trazabilidad en el ciclo de desarrollo de software ha sido un problema reiterado en las organizaciones [3, 4]. Se propone entonces un mtodo que incorpore a BPM en la fase de anlisis del

ciclo de vida de desarrollo de software que conduzca a unos requisitos ms slidos, pertinentes y coherentes con el modelo de negocio. Para el desarrollo del tema que nos ocupa, este artculo primero presenta una justificacin de este enfoque desde la perspectiva de los procesos de negocios y el desarrollo de software; posteriormente presenta una breve descripcin del contexto del caso de estudio, la metodologa seguida para el desarrollo de software bajo los dos enfoques, as como los comparativos resultantes al aplicar ambas consideraciones y finamente, se describen trabajos relacionados en la literatura cientfica, las conclusiones y trabajos futuros. 2. JUSTIFICACIN DE LA INCORPORACIN DE BPM EN EL DESARROLLO DE SOFTWARE Uno de los principales retos que se plantean los responsables de Tecnologas de Informacin TI es la capacidad de identificar y conocer los procesos del negocio, y ser capaces de dominarlos [5]. Es muy habitual observar que las empresas y sus reas de negocio no tienen bien identificados y monitorizados sus procesos, su elemento fundamental. Por esta razn, la implementacin de BPM es de gran importancia ya que permitir administrar de manera

116

unificada las personas, los procesos y la informacin de una organizacin as como los productos que del mismo se puedan desprender como: (1) agilizacin del trabajo de los usuarios, (2) la posibilidad de integrar tanto a empleados, clientes, proveedores y colaboradores, logrando una mayor trazabilidad y un menor nmero de errores en la informacin que manipulan y (3) mejor identificacin de necesidades y expectativas para el software que los soporta. Se parte del supuesto de que un buen diseo de procesos impactar favorablemente los fases de anlisis y definicin de requisitos lo que de hecho redundar en las siguientes fases del ciclo de desarrollo de software y es as como la elaboracin de un comparativo entre el mtodo tradicional de desarrollo de software en la fase de anlisis vs el anlisis bajo BPM permitir determinar y validar las ventajas de su incorporacin en los procesos de desarrollo de software. 3. CASO DE ESTUDIO Como caso de estudio para adelantar el comparativo se tom una empresa que brinda soporte y consultora integral en gestin de recursos humanos y outsourcing con 19 oficinas en Colombia y dos en Ecuador. Se tom el proceso el de seleccin de personal por ser el de mayor impacto dentro de la organizacin y porque administra ms de 20.000 puestos de trabajo y los subprocesos administracin y gestin de hojas de vida. 4. MTODO TRADICIONAL La empresa en la cual se adelant el comparativo presenta como mtodo de desarrollo de software en su fase de anlisis de requisitos las siguientes etapas: Fase de levantamiento: La inicia el usuario del proceso escribiendo la necesidad o problemtica en una plantilla estndar. Para el caso de estudio participaron los roles de lder de talento humano y analista de talento humano dado el contexto organizacional del software a ser desarrollado. Fase de aclaracin: El ingeniero de gestin y requisitos recibe de parte del usuario lder del proceso, el requisito detallado en la plantilla. Analiza el documento y solicita una reunin para aclarar la necesidad, esto en el caso que se identifique que hay ambigedad o se detecte que no est completo. Una vez aclarado el requisito se pasa a la fase siguiente. Fase de anlisis: El analista de desarrollo software asignado para administrar el requisito se rene con el ingeniero de gestin y requisitos para hacer la entrega formal y analizar en conjunto la necesidad y as determinar si se recibe a satisfaccin o si es necesario que se complemente. Una vez recibido a satisfaccin el requisito por parte del equipo de desarrollo analista de desarrollo, analista de productividad y desarrollo y coordinador de procesos de desarrollo, se inicia el anlisis detallado, para identificar cada uno de los componentes de desarrollo, los cuales se relacionan el archivo Matriz Trazable de Requisitos MTR.

Teniendo claro los componentes de desarrollo de software se da inicio a la fase de anlisis detallado, el cual debe quedar escrito en un documento definido diseo funcional y documentacin. En ese documento quedan registrados la funcionalidad, restricciones, excepciones, procesos alternos o paralelos que se derivan de cada componente de desarrollo. Al final se definen los tiempos requeridos para la construccin. Fase de validacin: Finalizado el anlisis se convoca a reunin al ingeniero de gestin de requisitos, el usuario lder del requisito y el analista de desarrollo de software. En la reunin se hace la presentacin de la(s) alternativa(s) de solucin y entre todos se selecciona una de ellas. El usuario lder da el visto bueno de la propuesta seleccionada y se inicia la fase de diseo y construccin. 5. MTODO CON BPM Para la gestin de anlisis de requisitos incorporando a BPM [6, 7] se estructuraron las siguientes fases: 1. Fase descubrimiento de procesos: Tiene como propsito el entendimiento de los procesos de negocios por el equipo del proyecto. 2. Fase modelamiento flujo de procesos: Tiene como propsito el modelamiento del proceso para anlisis de eficiencia y efectividad. 3. Fase definicin de reglas de negocio: Tiene como propsito definir las reglas de negocio que determinan la automatizacin y estandarizacin del proceso. 4. Fase de mejoramiento de flujo de proceso: Tiene como propsito proponer a partir de indicadores y simulaciones el proceso ms innovador para el negocio y el cual ser la base de los requisitos en cuanto a su funcionalidad, restricciones y excepciones. En cada una de ellas participan, algunos con mayor esfuerzo, los siguientes roles: (1) ingeniero de gestin y requisitos, (2) lder de talento humano, (3) analista de talento humano y (4) analista de productividad y desarrollo. 6. RESULTADOS Y ANLISIS Se presentan a continuacin los resultados de aplicar ambos mtodos en el caso de estudio. 6.1 Tiempos invertidos por fase Los tiempos que se detallan en la Figura 1 relacionan los tiempos medidos en horas que fueron requeridos para llevar a cabo la fase de anlisis funcional y detallado de la solucin entregada con el mtodo tradicional y el mtodo con una herramienta BPM. Al comparar las actividades realizadas y la cantidad de horas invertidas en cada uno de los mtodos, se puede ver claramente la diferencia tanto en cantidad de actividades como el nmero de horas totales. El mtodo tradicional requiri de seis actividades con un total de

117

53 horas y con el mtodo BPM las actividades se redujeron a cuatro y la inversin en horas a 35. Lo anterior nos lleva a concluir que la productividad con el mtodo BPM se incrementa en este caso, en 18 horas y se disminuye en dos actividades y lo ms importante es que la calidad del anlisis se mantiene.

6.3 Esfuerzo en das Siendo consecuentes con la observacin anterior con respecto al tiempo por rol, en la proyeccin en das para la etapa de anlisis del proyecto se puede observar un mayor esfuerzo en el mtodo tradicional, 53 das, a diferencia del mtodo BPM, 33 das, como lo muestra la Figura 3.

Fig. 3: Comparativo de tiempos del proyecto

Fig. 1: Comparativo de tiempos invertidos por mtodo

6.2 Tiempos invertidos por rol Uno de los recursos ms importantes en la planeacin de un proyecto es el recurso humano y el tiempo definido para su desarrollo. Las personas asignadas al proyecto se tomaron con base en los siguientes roles para la fase de anlisis: Ingeniero de gestin y requisitos Lder de talento humano Analista de talento humano Analista de productividad y desarrollo Analista de desarrollo Coordinador de procesos de desarrollo

6.4 Nmero de personas Validando el tema de cantidad de recurso en cuanto a personas en el proyecto, aplicando el mtodo tradicional se tiene en principio una persona por rol es decir, se destina en total, un nmero de seis personas que intervienen en la etapa de anlisis. Siendo consecuentes con esta forma de asignacin de las tareas, aplicando el mtodo BPM slo se requeriran en sentido estricto cuatro personas, como se observa en la Figura 4. Sin embargo, de acuerdo a los resultados presentados en la Figura 2 se observa una concentracin de actividades en los roles de Ingeniero de gestin de requisitos y de analista de productividad, para los cuales es posible asignar ms personas que cumplan estos roles, evitando la sobrecarga y rutas crticas, sin aumentar la cantidad de horas asignadas para cumplir con las actividades a realizar; en consecuencia, se conseguira no alargar el tiempo total del proyecto aplicando el mtodo BPM.

Al realizar el anlisis comparativo de la Figura 2 se puede observar que aplicando el mtodo BPM salen de la lista los roles de analista de desarrollo y el de coordinador de procesos de desarrollo, ya que sus tareas en esta fase no aplican para su funcin dentro del proyecto. Tambin observamos la variacin en cuanto a la cantidad de horas trabajadas por rol en cada mtodo, concluyendo que en la aplicacin del mtodo BPM se consumen menos horas en total pero se concentran ms actividades en los roles de analista de productividad y el de ingeniero de gestin y requisitos. Se aprecia que el rol de analista de talento humano que corresponde al rea cliente tiene una mayor participacin.

Fig. 4: Comparativo de recursos en # de personas

6.5 Costos del recurso Tanto en el mtodo tradicional como en el mtodo BPM se ejecutan una serie de actividades definidas en cada etapa del desarrollo de un proyecto de software. Al compararlos en cuanto a costos del recurso asignado y coherente a la informacin presentada en los puntos anteriores, se puede visualizar en la Figura 5 un mayor costo presupuestado para el desarrollo de la etapa de anlisis con el mtodo tradicional: una diferencia de $9.737.762 con respecto al del mtodo BPM. 6.6 Tareas Crticas Con el mtodo tradicional. La ruta crtica se plantea de forma serial en los diferentes roles que participan en el proyecto, lo cual hace que el porcentaje de oportunidad

Fig. 2: Comparativo de horas por rol

118

se pueda ver afectado por diferentes eventualidades, como se observa en la Figura 6.

mediante acercamientos Goal-Oriented Requirements Engineering GORE. A diferencia de stos, la propuesta presentada en el caso de estudio incluye no slo las metas sino el mejoramiento de procesos el cual en su ciclo define y redefine metas en forma iterativa. 8. CONCLUSIONES El proceso de desarrollo de software, en especial las primeras fases, debe incorporar la gestin de procesos que garanticen unos requisitos acordes con las metas organizacionales y contexto organizacional del producto. La Tabla 1 presenta a grandes rasgos las conclusiones obtenidos a partir del caso de estudio para el comparativo de los dos mtodos.
Tabla 1. Resultados del comparativo entre los mtodos Tradicional Las fases de anlisis y diseo son independientes Un enfoque muy orientado a las gestin de datos La fase de anlisis requiere mayor nmero de actividades Se requiere mayor cantidad de personas para llevar a cabo las fases de anlisis y diseo La participacin del usuario final es delimitada en algunas actividades Trabaja con fases y actividades muy secuenciales BPM Las fases se unifican Un enfoque muy orientado a la gestin de procesos Se reducen las actividades de anlisis Las fases de anlisis y diseo se realizan bajo un mismo rol Existe mayor participacin y continuidad del usuario final con el proceso Permite actividades paralelas para una mejor ruta crtica

Fig. 5: Comparativo de costos

Fig. 6: Ruta crtica con el mtodo tradicional

Con BPM. La ruta crtica solo se encuentra en el rol de ingeniero de gestin y requisitos por lo tanto el riesgo es menor y se puede tener un mejor control de las eventualidades que puedan afectar la oportunidad del proyecto (Figura 7).

9. TRABAJO FUTURO Actualmente se est adelantando la estructuracin de un framework para la implementacin de proyectos BPM el cual se integra al ciclo de desarrollo de software en sus diferentes etapas de acuerdo al modelo de desarrollo seleccionado. 10. REFERENCIAS
[1] Club-BPM. 2010. Estudio. Online [Jan. 2012]. [2] Sinur, J. 2011. Top 5 BPM Impacts for the Next Decade. Online [Feb. 2012]. [3] Andreescu, A. & Mircea, M. 2009. Managing knowledge as Business Rules. Informtica Econmica, 13(4), 63-74. [4] Computerworld. 2011. BPM: Innovacin y Competitividad en Latinoamrica. Online [Dec. 2011]. [5] Band, W. 2010. The Forrester Wave: CRM Suites for Midsized Organizations, Q2 2010. Forrester Research. [6] Jeston, J. & Nelis, J. 2006. Business Process Management: Practical Guidelines to Successful Implementations. Butterworth-Heinamennn. [7] IBM. BPM Solution Implementation Guide. Online [January. 2012]. [8] Sagheb-Tehrani, M. & Ghazafrian, A. 2002. Software development process: strategies for handling business rules and requirements. In SIGSOFT Software Engineering Notes, 27(2), 58-62. [9] Anton, A. 1996. Goal-Based Requirements Analysis, 2nd IEEE International Conference on Requirements Engineering, 136-144. [10] Lamsweerde, L. 2011. Goal-Driven requirements Engineering: The KAOS Approach. Online [July. 2011].

Fig. 7: Ruta crtica con el mtodo BPM

7. TRABAJOS RELACIONADOS Existen aproximaciones para buscar garantizar las interrelaciones entre el negocio y los requisitos en propuestas que buscan establecer reglas del negocio que sean fcilmente traducibles en requisitos [8]. A nivel de frameworks se tienen experiencias como GBRAM [9] y KAOS [10] muy orientados a interrelacionar las metas del negocio con los requisitos

119

An Overview of Testing Applications and Web Service Security: Free Options Un Vistazo al Testing de la Seguridad en Aplicaciones y Servicios Web: Opciones Libres
Luis E. Melndez C.
Fundacin Universitaria Tecnolgico Comfenalco. Cartagena, Colombia. lmelendez@tecnologicocomfenalco.edu.co. INFORMACIN DEL ARTCULO Tipo de artculo: Reflexin Historia del artculo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 05/06/2012 Palabras clave Pruebas, seguridad informtica, marco, metodologas. Categories and Subject Descriptors D.2.4 [Software Engineering]: Management. General Terms Software Testing. Keywords Testing, information framework, methodology. security, ABSTRACT Computer security is taking a very important role in software development, particularly in developing web applications and services, because these have become major targets of cyber-crime because of this it is necessary the instruments that the testing equipment can be used to ensure the security of software before going into production. This noble objective is affected by the high cost of tools and the absence of defined procedure to carry out this process, hence the aim of this paper which seeks to show some of the mechanisms offered by the Open Source carry out the processes of testing web application security. RESUMEN La seguridad informtica esta tomando un papel de mucha importancia en el desarrollo de software, particularmente en el desarrollo de aplicaciones y servicios web, debido a que estos se han convertido en uno de los principales objetivos de la ciber-delincuencia; debido a esto se hace necesario conocer los instrumentos que los equipos de prueba pueden utilizar para garantizar la seguridad de un software antes de salir a produccin. Este noble objetivo se ve afectado por los altos costos de las herramientas y de la ausencia de procedimiento definidos para llevar a cabo este proceso, de ah el objetivo de este artculo el cual busca mostrar algunos de los mecanismos que nos ofrece la corriente Open Source llevar a cabo los procesos de testing de seguridad en aplicaciones web.

1. INTRODUCCIN La seguridad en las aplicaciones web se ha convertido en uno de los puntos de mayor trabajo para los probadores de software, ya que en los ltimos aos estas se han vuelvo el principal objetivo para los ciberdelincuentes como se documenta en [1]. Trabajos como [44-46] son ejemplos de investigaciones cuyo objetivo era dar a conocer herramientas para automatizar en parte o todo el proceso de pruebas de seguridad en aplicaciones web, desafortunadamente para la poca las herramientas eran pobres tanto en tcnica como en tecnologas, adems de que en ese momento eran pocos los proyectos Open Source en el rea, lo que llev a tomar como referencia herramientas comerciales. Como lo vislumbraban los trabajos antes citados y respaldado por las tendencias actuales, el problema de asegurar las aplicaciones radica en los costos asociados a este proceso. Por lo que en este artculo se busca dar un vistazo a los diferentes instrumentos metodologas, pruebas y herramientas que brinda el Open Source para llevar a cabo este proceso. En el captulo 2 se tocarn los conceptos bsicos que rodean la prueba de seguridad en aplicaciones web, en el captulo 3 los distintos tipos de prueba de seguridad que se pueden llevar a cabo, en el captulo 4 se explicarn los detalles de la metodologa ms completa para llevar a cabo la prueba seguridad, en el captulo 5 se compararn dos de las herramientas para la automatizacin de las tareas asociadas y por ltimo se finaliza con las conclusiones obtenidas al desarrollar este trabajo.

2. BASES TERICAS 2.1 Aplicaciones Web Una Aplicacin Web puede ser vista como un software basado en arquitectura cliente/servidor creado para operar en un entorno Web, que usa como canal de comunicacin protocolo HTTP [2] y se visualiza a travs de un Navegador. En la Figura 1 se observa la interaccin de los distintos componentes que una aplicacin web puede poseer.

Fig. 1: Aplicacin Web - Componentes

Son desarrolladas en lenguajes de programacin de ltima generacin tales como ASP, ASP.Net, Python, Perl, JAVA, PHP, entre otros, siendo PHP y JAVA los ms usados en la actualidad [3]. La aplicacin es diseada utilizando patrones arquitectnicos basados en un modelo Cliente/Servidor, uno de los ms usados es el MVC o Modelo Vista-Control [4], tambin conocido como Modelo de 3 Capas, el cual divide la aplicacin en tres componentes operativos con funciones distintas modelo de datos, interfaz grfica y lgica de negocio. En la Figura 2 se puede ver la manera en que opera el patrn arquitectnico MVC.

120

cual se publican y buscan los Servicios Web. Este servicio ha permitido estandarizar los servicios de localizacin, ubicacin y publicidad de los Servicios Web dando orden a estos procesos que carecan de una estructura normalizada entre ellos.

Fig. 2: Arquitectura MVC o Modelo VistaControl

Algunas ventajas de este tipo de aplicaciones son: Elimina las barreras de acceso a la aplicacin, ya que al basarse en tecnologas Web es posible acceder a ella desde cualquier parte a travs de la Internet, siempre y cuando la configuracin de seguridad lo permita. Es totalmente multiplataforma, lo cual permite que la aplicacin pueda ser accedida desde cualquier sistema operativo a travs de un navegador Web. El consumo de recursos por parte del cliente que accede a la aplicacin es bastante bajo en comparacin con aplicaciones stand-alone. El tiempo de desarrollo y puesta en produccin de este tipo de aplicaciones es menor que el de aplicaciones stand-alone. 2.2 Servicios Web Segn el World Wide Web Consortium [5], un Servicio Web, es un sistema software identificado por una URI cuyos interfaces pblicos estn definidos y descritos por XML. Esta definicin puede ser accedida por otros sistemas software, los cuales pueden interactuar con el Servicio Web en la forma prescrita en su definicin, utilizando mensajes XML y transportado por mensajes de Internet. Podemos simplificar este concepto y decir que un Servicio Web es un componente software que permiten la interoperabilidad de aplicaciones heterogneas (tanto en lenguaje de desarrollo como en plataforma operativa) en entornos distribuidos, usando para el intercambio de datos entre ellas mensajes en formato estandarizado a travs del protocolo XML y transportados sobre protocolos de uso comn en la Internet como HTTP o HTTPS. La arquitectura de los Servicios Web consta de tres elementos bsicos: El Web Services Description Language (WSDL), el Universal Description, Discovery and Integration (UDDI) y el Simple Object Access Protocol (SOAP). El Web Services Description Language (WSDL) [6] es un formato XML usado para describir los Servicios Web que son desplegados, este define las caractersticas necesarias para que se d el consumo del servicio web (su localizacin, los mtodos, parmetros disponibles y formato de datos soportados). En la Figura 3 se puede ver la estructura de un documento WSDL. El Universal Description, Discovery and Integration (UDDI) [7], es un servicio de directorios abierto en el

Fig. 3: Estructura de un documento WDSL

El Simple Object Access Protocol (SOAP) [8] es un elemento de vital importancia dentro del intercambio de datos en los Servicios Web, ya que este protocolo se encarga de definir cmo se intercambiaran objetos entre procesos heterogneos usando para ello mensajes estructurados y estrictamente formateados en protocolo XML. En la Figura 4 se puede observar como interactan cada uno de los elementos antes mencionados en una arquitectura basada en Servicios Web.

Fig. 4: Arquitectura Operativa de un Servicio Web

2.3 Vulnerabilidad El trmino vulnerabilidad es descrito por Richard Bejtlich [9] como la debilidad existente en un bien que podra dar lugar a su explotacin, lo que terminara impactando negativamente sobre la integridad, confidencialidad o disponibilidad del bien afectado. Un concepto ms administrativo es el suministrado por la norma ISO/IEC 13335:2004 [10] en la cual se establece que una vulnerabilidad es una debilidad de un activo o conjunto de activos que pueden ser explotados por una amenaza, teniendo en cuenta que una amenaza es cualquier evento que ponga en riesgo la seguridad de nuestros activos de informacin. Otra definicin interesante es la suministrada por el Centro de Respuesta ante Incidentes del Instituto Nacional de Tecnologas de las Comunicaciones INTECO en Espaa

121

[11], que la definen como aquellos fallos de seguridad que pueden provocar que nuestro sistema informtico sea susceptible de sufrir un ataque por una mala programacin del mismo o una configuracin errnea. El concepto anterior deja entrever distintos escenarios en los que se puede dar origen a una vulnerabilidad, lo cual coincide con lo descrito por Bejtlich [9], donde afirma que las vulnerabilidades son producto de fallas en el diseo, la implementacin o en la administracin de un bien informtico. Existen diferentes tipologas para la clasificacin de las vulnerabilidades en sistemas informticos; la de mayor aceptacin es la del Forum of Incident Response and Security Teams FIRST [12], que plantea un modelo tipolgico basado en mtricas para la clasificacin y cualificacin de las vulnerabilidades, usando para ello tres grupos bsicos de mtricas cualitativas, mtricas base, mtricas temporales y mtricas del entorno. En la Tabla 1 se pueden observar las mtricas pertenecientes a cada grupo.
Tabla 1. Tipologa Basada en Mtricas para clasificar vulnerabilidades Grupos Mtricas
Vector de Acceso Complejidad de Acceso Mtricas Base Autenticacin Impacto en la Confidencialidad Impacto en la Integridad Impacto en la Disponibilidad Explotabilidad Mtricas Temporales Facilidad de Correccin Fiabilidad del Informe de Vulnerabilidad Mtricas del Entorno Daos Colaterales Distribucin de Equipos Vulnerables Requisitos de Seguridad

Tipos
Locales Red Local Remotos Alta Baja Simple Mltiple Ninguna Alta Baja Alta Baja Alta Baja Explotable No Explotable Correccin Fcil Correccin Compleja No Existe Correccin Identificada y Confirmada Identificada sin Confirmar Sin Fuentes Alta Baja Alta Baja Alta Baja

Fig. 5: Resumen de OWASP Top 10 2010

Desde el ao 2007 el proyecto OWASP ha generado una clasificacin documentada de las vulnerabilidades ms predominantes y crticas en las aplicaciones y servicios web el cual se conoce como el OWASP Top 10 [13], la versin ms reciente de esta clasificacin data del ao 2010 y se puede observar en la Figura 5. Este documento se ha convertido a nivel internacional en un referente de suma importancia al momento de evaluar o implementar la seguridad en aplicaciones web, al punto de ser reconocida y adoptada por organismos estatales norteamericanos como U.S. Federal Trade Commission y el U.S Defense Information Systems Agency DISA, por empresas del sector tecnolgico como HP, IBM Global Services, Oracle, Price Waterhouse Coopers, Symantec entre otras y empresas del sector bancario como Citibank, Bank of Newport y National Australia Bank [14].

2.4 Pruebas de Seguridad Antes de entrar a definir el trmino Prueba de Seguridad, se mencionar apartes del proceso del que hace parte, la prueba de software. La prueba de software consiste en la verificacin dinmica del comportamiento de un programa sobre un conjunto finito de casos de prueba, apropiadamente seleccionados a partir del dominio de ejecucin que usualmente es infinito, en relacin con el comportamiento esperado [15]. Esta definicin hace nfasis en la relacin de las caractersticas y limitaciones propias de la prueba, nmero de casos de pruebas finitos sobre un objeto de prueba con infinitas posibilidades de error. Se puede concluir que la prueba es la fase dentro del ciclo de desarrollo de software que se encarga de asegurar que cumpla con los requerimientos establecidos y de identificar defectos o errores para garantizar su calidad, este concepto concuerda con los expuestos en [16] y [17]. En los ltimos aos esta fase ha cobrado vital importancia, lo que ha llevado a formalizar y estandarizar muchos de sus procesos o tareas embebidos, por ejemplo la normalizacin iniciada en el ao 2007 por el comit ISO/IEC JTC1/SC7 para la creacin del estndar ISO/IEC 29119 [18], el cual normaliza las mejores prcticas tomadas de estndares como IEEE 829 Test Documentation [19], IEEE 1008 Unit Testing [20], BS 7925-1 Vocabulary of Terms in Software Testing [21] y BS 7925-2 Software Component Testing Standard [22]. El estndar ISO antes mencionado define varios tipos de pruebas a realizarse dentro de esta fase: Accessibility Testing, Backup/Recovery Testing, Compatability Testing,

122

Conversion Testing, Disaster Recovery Testing, Functional Testing, Interoperability Testing, Maintainability Testing Performance, Load, Stress, Endurance, Volume and Capacity Testing, Portability Testing, Procedure Testing Reliability Testing, Stability Testing, Usability Testing y Security Testing, siendo este ltimo el objeto de estudio en este trabajo. El Security Testing es una de las pruebas de mayor importancia en la prueba de software, especialmente si se habla de software destinado a operar en ambientes web, esto debido al nivel de exposicin y riesgo inherente a este tipo de programas; esta afirmacin se respalda en estudios realizados por la firma Gartnet Inc. [1], los cuales concluyen que aproximadamente el 75% de los ataques informticos tienen como objetivo fallas o vulnerabilidades en las aplicaciones web, como se observa en la Figura 6, lo cual evidencia la necesidad de identificar y corregir este tipo de defectos en las aplicaciones antes de salir a produccin, en este punto es donde aparece el Testing de Seguridad.

alcanzar este adjetivo cuando se hace referencia a proyectos de mediano y gran tamao, esto se debe a la gran cantidad de tiempo que el probador debe invertir para revisar la totalidad de lneas que pueden tener proyectos de estas magnitud; inclusive utilizando herramientas que le ayuden automatizando parte o todo el proceso, lo cual la vuelve ineficiente en estos casos, adems, es posible que entre tantas lneas de cdigo y sin poder ejecutar la aplicacin en un entorno de prueba, el probador pierda el control de la evaluacin y no se logren los resultados esperados. Por otra parte a pesar de que es viable identificar muchas vulnerabilidades a nivel de cdigo, sin la ejecucin de un probe of concept no es posible establecer su nivel exacto de explotabilidad e impacto sobre la aplicacin o el servicio web y la informacin que maneja. Adems, esta prueba requiere conocimientos especficos, capacidad de reflexin analtica y competencia humana para ser efectiva, como se sugiere en [15] y [23]. 3.2 Blackbox Testing En este tipo de prueba el probador tendr acceso slo a la aplicacin o al servicio web sin ningn tipo de privilegios de usuario. Algunos profesionales en el rea y autores como [23-27] hacen referencia a ella como un PenTest o Test de Penetracin, esto debido a el enfoque real de las pruebas Blackbox el tester posee el mismo nivel de conocimiento sobre la aplicacin que un potencial atacante. El objetivo principal de este tipo de prueba es identificar vulnerabilidades que le permitan al probador el acceso no autorizado a la aplicacin o a la informacin que ella maneja, tambin a alterarla o borrarla y, de ser posible, tomar control del host anfitrin. Entre sus principales caractersticas se encuentra la sencillez de las tareas para llevarla a cabo, los reducidos tiempos de prueba en comparacin con el mtodo anterior y su total orientacin a la seguridad de la aplicacin [24, 27]. No es til para verificar el uso de estndares de programacin segura, adems, no detecta vulnerabilidades asociadas con prcticas poco ticas en el desarrollo, como bombas lgicas, puertas traseras, entre otras, slo se limita a la identificacin de fallas basadas en puntos de acceso o de intercambio de datos a travs de la realizacin de ataques informticos contra ellos y no cubre la posible totalidad de defectos existentes; en estos puntos de evaluacin suelen aparecer especulaciones por parte del probador lo cual reduce la objetividad de la evaluacin. 3.3 Whitebox Testing Tambin se conoce como Glassbox-Test. El tester posee acceso al cdigo fuente de la aplicacin, manuales de usuario, credenciales validas del sistema, configuracin del servidor Web y acceso a la aplicacin en si misma [23, 25]. Este tipo de prueba se puede considerar un punto intermedio en entre los dos anteriores porque adopta las principales ventajas de cada uno de ellos, lo que permite identificar vulnerabilidades en tiempo de ejecucin a travs de un pre-testing controlado y analizar la seccin de cdigo que las generan; adems, al

Fig. 6: Resultados Webapp Security Investigation

Este tipo de prueba se enfoca a identificar y corregir defectos, ms conocidos en el argot de la seguridad informtica como vulnerabilidades, que pongan en riesgo la seguridad de la informacin que los programas manejan o de las plataformas sobre las que operan. 3. TIPOS DE PRUEBAS DE SEGURIDAD 3.1 Anlisis Esttico de Cdigo Este tipo de prueba es el ms bsico y riguroso de todos, y es el proceso de evaluar un software sin ejecutarlo [23]; lo que implica una revisin lnea a lnea del cdigo fuente de la aplicacin o el servicio web este proceso puede ser parcial/totalmente manual o automtico a travs de una herramienta de anlisis y no tiene la posibilidad de ejecutarse en un entorno para identificar y corregir posibles defectos de programacin que desencadenen en vulnerabilidades que pongan en riesgo la seguridad de la misma. Este tipo de Prueba de Seguridad, en teora, permite identificar gran cantidad de defectos de programacin, eliminando las suposiciones que se pueden generar en otros tipos de pruebas porque todo es verificable en el cdigo fuente [23]; adems, es til al momento de comprobar el uso de estndares de programacin segura por parte de los desarrolladores. A pesar de ser una tcnica que por sus caractersticas podra considerarse como muy efectiva, no logra

123

tener acceso al cdigo fuente es posible establecer los niveles de cumplimiento de los estndares de programacin. Posee las siguientes falencias [27]: Puede generar gran nmero de falsos positivos si el analizador de cdigo fuente no se encuentra calibrado de forma adecuada. Proporciona poca retroalimentacin de los componentes del entorno que pueden comprometer la seguridad de la aplicacin. Est orientada ms al dominio de desarrollo que al de la seguridad, a diferencia del Blackbox. A pesar que el tiempo de ejecucin es inferior al anlisis esttico de cdigo, sigue siendo mayor al necesario para llevar a cabo un Blackbox. 4. OWASP TESTING METHODOLOGY A pesar de estar definido dentro de diferentes metodologas de prueba de software, como en el ISO/IEC 29119, no cuenta con una estructura en su desarrollo ni en el tipo y cantidad de pruebas a llevar a cabo. Existen varias iniciativas para desarrollo de pruebas de seguridad en aplicaciones Web entre las que resaltan dos iniciativas: la propuesta por ISECOM [28] llamada OSSTMM Web App [29], a la que slo tienen acceso usuarios Gold de su comunidad y la propuesta por la OWASP Foundation [30], OWASP Testing Methodology, a la cual se puede tener acceso libre a travs del sitio del proyecto. OWASP una iniciativa liderada por la OWASP Foundation, organizacin sin nimo de lucro de carcter internacional que financia sus actividades a travs del cobro de membresas y donaciones realizadas generalmente por la empresa privada y simpatizantes de la iniciativa. El proyecto tiene como objetivo principal identificar, clasificar y documentar todas aquellas vulnerabilidades que hacen inseguros al software, particularmente las de ndole Web, adems, plantear guas de buenas prcticas tanto para la prueba como para el desarrollo de software seguro. Dentro de los resultados publicados por OWASP en los ltimos aos se encuentra una gua metodolgica y de buenas prcticas que se han convertido en un estndar de facto para llevar a cabo Pruebas de Seguridad en aplicaciones web, el OWASP Testing Guide [32] trabaja actualmente en el desarrollo de la versin 4.0 presupuesta para ser liberada a finales del 2013 [34]. Esta propuesta es de tipo Blackbox y divide la Prueba de Seguridad en dos fases: (1) en modo pasivo y (2) en modo activo. En la Tabla 2, el tester se dedica a conocer la aplicacin, a comprender su lgica y a identificar posibles puntos de acceso.
Tabla 2. Controles Fase Modo Pasivo Categora
Recoleccin de Informacin

En la Fase en Modo Activo (Tabla 3), el tester inicia las pruebas tomando como punto de partida los diferentes puntos de acceso identificados en la fase anterior.
Tabla 3. Controles Fase Modo Activo Categora Pruebas
Pruebas SSL/TLS Prueba de DB Listener Prueba de Gestin de Configuracin de Infraestructura Prueba de Gestin de Configuracin de Aplicacin Prueba del Gestor de Extensin de Ficheros Antiguo, backup y ficheros no referenciados Interface de Administracin de Aplicacin e Infraestructura Prueba de mtodos HTTP y XST Transporte de Credenciales sobre canal cifrado Enumeracin de usuarios Prueba de deteccin de Cuentas de Usuario Adivinables Prueba de Fuerza Bruta Prueba para evitar el esquemas de autenticacin Recordatorio de contrasea y restablecimiento Cierre de Sesin y Gestin de Cache de Navegacin Prueba de CAPTCHA Prueba de Autenticacin de Mltiple Factores Prueba de Condiciones de Carrera Prueba del Esquema de Gestin de Sesin Prueba de atributos de Cookies Prueba de Fijacin de Sesin Prueba de Variables de Sesin Expuestas Prueba de CSRF Prueba de Ruta Transversal Prueba para Evitar Esquema de Autorizacin Prueba de escalada de Privilegios Prueba de Lgica de Negocio Prueba de XSS Reflejado Prueba de XSS Almacenado Prueba de XSS basado en DOM Prueba de XSS basado en Flash Inyeccin SQL Inyeccin LDAP Inyeccin ORM Inyeccin XML Inyeccin SSI Inyeccin XPath Inyeccin IMAP/SMTP Inyeccin de Cdigo Inyeccin de Ordenes del Sistema Operativo Desbordamiento de buffer Prueba de Vulnerabilidad incubada Prueba de HTTP Splitting/Smuggling Prueba de Ataques a travs de Comodines SQL Bloqueo de Cuentas de Usuarios Pruebas de DoS mediante Desbordamiento de Buffer Asignacin de Objeto de Usuario Especificado Entrada de usuario como un contador de bucle Prueba de Escritura en Disco de data del Usuario Fallo en Liberar Recursos Almacenamiento de demasiados datos en Sesion Recopilacin de Informacin de WS Prueba de WSDL Prueba en la Estructura del XML Prueba del XML a nivel de contenido Prueba de REST/parmetros HTTP GET Adjuntos SOAP maliciosos WS SOAP Prueba de Repeticin Vulnerabilidades Ajax Pruebas Ajax

Pruebas de Gestin de Configuracin

Pruebas de Autenticacin

Pruebas de Gestin de Sesiones

Pruebas de Autorizacin Prueba de Lgica de Negocio

Pruebas de validacin de datos

Pruebas de denegacin de Servicio

Pruebas de Servicios Web

Pruebas de AJAX

Pruebas
Spiders, Robots y Crawlers Descubrimiento/Reconocimiento mediante motores de bsqueda Identificacin de puntos de entrada de la aplicacin Pruebas de firma digital de Aplicaciones Web Descubrimiento de Aplicaciones Anlisis de Cdigos de Errores

5. HERRAMIENTAS PARA AUTOMATIZACIN Una metodologa de Prueba de Seguridad como la propuesta por OWASP, exige gran cantidad de pruebas, que si bien podran realizarse de forma manual, el tiempo necesario para completarlas sera bastante prolongado y ocasionara serios retrasos en la puesta en

124

produccin del aplicativo. Esta situacin fue aprovechada por investigadores y empresas del campo de la seguridad informtica para desarrollar herramientas que permitieran automatizar las tareas o pruebas asociadas, lo que permite ahorrar tiempo en la realizacin de las pruebas, aunque tienden a incurrir en la generacin de falsos positivos, por lo que se deben examinar cuidadosamente los resultados obtenidos y de ser posible comprobarlos de forma manual. Existen muchas herramientas de este tipo, en su mayora comerciales, las cuales son bastante eficientes, pero sus costos tienden a ser elevados y suelen ser poco flexibles, por lo que muchas empresas y profesionales del desarrollo de software desisten de adquirirlas. Algunos ejemplos son: Acunetix Web Security Scanner [34], IBM Rational AppScan [35] y HP Web Inspect [36]. Una solucin al problema se encentra en el Software Libre. Investigadores del rea de la seguridad informtica de diferentes partes del mundo, como el proyecto W3AF [37], el proyecto Arachni [38] el proyecto Grendel Scan [39] y el proyecto Grendel Scan, entre otros, han desarrollado frameworks para la identificacin de vulnerabilidades en entornos web, con caractersticas similares a las ofrecidas por las herramientas comerciales pero bajo licenciamiento libre conocidas en la comunidad como Web Applications Security Scanner Framework. En la actualidad se destacan el W3AF y Arachni. 5.1 W3AF El Web Application Attack and Audit Framework es una de las pocas herramientas de cdigo libre que encierra todo un marco de trabajo para llevar a cabo Pruebas de Seguridad en aplicaciones web, por lo que se ha convertido en uno de los principales referentes en los de su tipo. Su arquitectura operativa se basa en plugins, lo cual permite que sea fcilmente extensible. Esta arquitectura se basa en dos secciones o componentes operacionales: (1) el ncleo del framework y (2) la base de plugins. La primera se encarga de gestionar todo el proceso de prueba y provee las diversas funcionalidades usadas por plugins e interfaces de usuario la segunda contiene los diferentes PoC que materializan las diversas pruebas a realizar segn su categora [23, 40, 42]. A la fecha ofrece plugins para detectar ms de 150 tipos de vulnerabilidades web, los cuales se muestran en la Tabla 4. Ventajas: Uno de los atractivos de esta herramienta es su licenciamiento libre. Es multi-plataforma. Posee una arquitectura basada en plugins, lo que permite que sea fcilmente extensible [42]. Posee dualidad de interfaces de usuario, consola y grfica, lo que le permite operar sin inconvenientes en entornos grficos o de lnea de comando. Su interfaz grfica es bastante intuitiva, lo que permite que el manejo de la herramienta sea sencillo.

Brinda la posibilidad de crear perfiles, los cuales cargan una coleccin de plugins pre-establecidos por el tester para una circunstancia en particular. Existen una serie de perfiles por defecto los cuales son creados al momento de la instalacin, entre los que se destaca el OWASP Top 10, que se enfoca exclusivamente en realizar pruebas de identificacin de vulnerabilidades asociadas a este escalafn. Posee una amplia base de datos de plugins, la cual es peridicamente actualizada [23, 41, 42]. Brinda la posibilidad de detectar vulnerabilidades en Query string, URL Filename, HTTP Headers, JSON, Contenido de Archivos y Web services. Posee funcionalidades anexas como Codificadores/ Decodificadores, Comparadores, Proxy Local, entre otras, que apoyan, de ser necesario, los procesos de verificacin manual de resultados.
Tabla 4. Tipologa de Plugins W3AF [40, 43]
Plugin
Discovery Audit Bruteforce Grep Evasion Output Mangle

Descripcin
Descubren la superficie de anlisis de la aplicacin objetivo. Intentan detectar una vulnerabilidad especfica en el sitio Web Realizan ataques de fuerza bruta contra mdulos de autenticacin. Buscan informacin en el contenido de las pginas del sitio. Modifican las peticiones para evadir filtros de seguridad. Definen el formato de salida de la informacin generada. Permiten que el usuario modifique secciones de las peticiones realizadas

Desventajas: A pesar de poseer una interfaz de fcil uso, la configuracin de la herramienta exige buen conocimiento en seguridad, lo que restringe su uso a un grupo especfico de profesionales. La calidad grfica de los reportes generados es baja. El consumo de recursos es elevado en comparacin con otras. Tiende a generar un numero alto de falsos positivos, por lo que se recomienda la verificacin manual de resultados. 5.2 Arachni Es un proyecto Open Source desarrollado en lenguaje Ruby orientado a operar a travs de interfaces Web. Se inicio como un ejercicio educativo y se ha convertido en uno de los proyectos ms prometedores en el rea de la deteccin de vulnerabilidades en ambientes Web. Posee caractersticas como una arquitectura 100% modular y distribuida, habilidades analticas y meta-analticas que le permite correlacionar y sacar conclusiones con base en resultados obtenidos y opera en ambientes de computacin en malla lo que repercute en un aumento considerable en el rendimiento de la herramienta. En la Tabla 5 se describen sus mdulos.
Tabla 5. Mdulos y Pruebas Disponibles en Arachni Mdulos Pruebas
SQL injection Blind SQL injection using rDiff analysis Blind SQL injection using timing attacks CSRF detection Code injection (PHP, Ruby, Python, JSP, ASP.NET) Blind code injection using timing attacks (PHP, Ruby, Python, JSP, ASP.NET) LDAP injection

Auditoria

125

Recoleccin de Informacin o Reconocimiento

Path traversal Response splitting OS command injection (*nix, Windows) Blind OS command injection using timing attacks (*nix, Windows) Remote file inclusion Unvalidated redirects XPath injection Path XSS URI XSS XSS XSS in event attributes of HTML elements XSS in HTML tags XSS in HTML 'script' tags Allowed HTTP methods Back-up files Common directories Common files HTTP PUT Insufficient Transport Layer Protection for password forms WebDAV detection HTTP TRACE detection Credit Card number disclosure CVS/SVN user disclosure Private IP address disclosure Common backdoors .htaccess LIMIT misconfiguration Interesting responses HTML object grepper E-mail address disclosure US Social Security Number disclosure Forceful directory listing

A la fecha presenta algunos bug por lo que algunos expertos la consideran todava como una herramienta en fase Beta. Presenta limitaciones para evaluar aplicaciones que posean mucho contenido de tipo JavaScript o AJAX, por no contar con un intrprete que soporte estas tecnologas. Aunque implementa muchas pruebas que pueden coincidir con algunas de las que se incluyen en la OWASP, no posee la totalidad de sta y tampoco prioriza vulnerabilidades a travs del OWASP Top 10. A pesar de implementar mtodos que disminuyen la aparicin de fasos positivos, siguen apareciendo aunque en un menor nmero, por lo que se recomienda complementar el trabajo de identificacin de vulnerabilidades automatizado con una verificacin manual. No posee muchas pruebas para evaluar Web Services. Los periodos de actualizacin de la herramienta a pesar de ser peridicos son muy largos. En la Tabla 6 se ofrece un anlisis comparativo entre las herramientas descritas en este apartado.
Tabla 6. W3AF vs. Arachni
W3AF
Lenguaje de Desarrollo Arquitectura Consumo de Recursos Multi-plataformas Inteligencia Artificial Capacidad de Aprendizaje en Caliente Testing Distribuido Interfaces de Usuario Calidad de los Reportes Mdulos y Plugins Patrones de deteccin basados en OWASP Soporta Evaluaciones Web Service a Si Medio-Alto Baja Media Alta Alta Rapid7 Bonsai IS Free GPL v2.0 Python Basada en Plugins Alto Si No No No Stand Alone y Consola Baja Ms de Plugins 180

Ventajas: Es un proyecto Open Source. Fue creado para operar sobre sistemas operativos Linux, pero es posible ejecutarlo en Windows a travs del emulador de consola Linux Cygwin. Posee la capacidad de razonar y sacar conclusiones a travs de un proceso de correlacin complejo, para disminuir los falsos positivos tratando de emular la capacidad humana para tomar decisiones [38]. Es capaz de aprender de las acciones y respuestas que recibe durante la evaluacin, lo que ayuda a que pueda incorporar nuevo conocimiento durante el proceso de prueba descubrir vectores de ataque ocultos, implementar variantes de ataque, adaptar tcnicas o PoC al entorno que se evala,. Para optimizar el consumo de ancho de banda utiliza peticiones HTTP asncronas que evitan el consumo excesivo de dicho recurso [38]. Genera buenos reportes de resultados que son entendibles, agradables a la vista y en diferentes formatos: HTML, Plain Text, XML, entre otros. Posee ms de 40 mdulos de auditora y recoleccin de informacin, compuestos por cientos de PoC que permiten identificar desde fallas crticas como code injection, XSS o SQL injection hasta recuperar informacin expuesta como direcciones de e-mail, directorios sin proteccin o comentarios en el cdigo del cliente. Permite ejecucin de pruebas de forma distribuida o en entornos de Grid Computing a travs de la implementacin de un API RPC, lo que aumentar el rendimiento y disminuye los tiempos de duracin de la prueba. Desventajas: Poca informacin acerca de su uso y configuracin. El nmero de pruebas que puede realizar es menor en comparacin con W3AF.

Arachni
Ruby Basada en Modulos Medio Si (CygWin) Si Si Si Web y Consola Media 40 Mdulos (Auditoria y Reconocimiento) No Limitado en nmero de pruebas por lo que puede ser poco eficiente Medio Baja Baja Media Media A la fecha no posee Free GPL v2.0

Si (Posee un perfil para el OWASP Top 10)

Nivel de Generacin de Falsos Positivos Dificultad en el Uso Dificultad en la Configuracin del Testing Estabilidad de la Versiones Liberadas Periodicidad de Actualizacin Patrocinadores Costo Licenciamiento

6. CONCLUSIONES Desde el punto de vista de la seguridad es recomendable llevar a cabo pruebas de tipo Blackbox para identificar fallas o vulnerabilidades en aplicaciones web, tanto por tiempos de realizacin como por los resultados ofrecidos.

126

 El trabajo en el desarrollo de metodologas para pruebas de seguridad en aplicaciones web se incrementa cada da. La metodologa propuesta por OWASP para probar aplicaciones web es una de las mejores opciones para llevar a cabo esta tarea, se podra considerar como la ms completa y mejor documentada, aunque no existen herramientas que automaticen la totalidad de la pruebas que exige, por lo que debe mezclarse con pruebas manuales. El software libre ofrece excelentes opciones a nivel de herramientas para realizar pruebas de seguridad en aplicaciones web, que llegan a ser tan competitivas como las comerciales. El uso de herramientas que automaticen el proceso de prueba de seguridad no remplaza completamente a la prueba manual, porque estas herramientas suelen generar falsos positivos y los resultados deben ser comprobados a travs de una verificacin manual. La formacin de los programadores debe incluir slidas bases en seguridad informtica para evitar que comentan errores en el desarrollo o la configuracin que desemboquen en vulnerabilidades crticas que pongan en riesgo la aplicacin, como las reportadas en el OWASP Top 10. 7. REFERENCIAS
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] Garnet Inc. http://www.gartner.com. Fielding, R. 1999. Hypertext Transfer ProtocolHTTP/1.1. Tiobe Software. 2012. Programming Community Index. Deacon, J. 2009. ModelViewController (MVC) Architecture. W3C Working Group. 2004. Web Services Architecture. W3C Working Group. 2001. Web Services Description Language (WSDL) 1.1. OASIS. OASIS UDDI Specification TC. W3C Working Group. 2000. Simple Object Access Protocol (SOAP) 1.1. Bejtlich, R. 2004. The Tao of Network Security Monitoring: Beyond Intrusion Detection. AddisonWesley. ISO/IEC. 2004. ISO/IEC 13335:2004 - Information technology - Security techniques - Management of information and communications technology security. ISO/IEC. INTECO. Centro de respuestas a incidentes de seguridad TIC. Mell, P.; Scarfone, K. & Romanosky, S. 2007. A Complete Guide to the Common Vulnerability Scoring System. OWASP. 2010. OWASP Top 10 - The Ten Most Critical Web Applications Security Risks. The OWASP Foundation. Majchrzak, T. A. 2012. Improving Software Testing Technical and Organizational Developments. Springer. Abran, A. & Moore, J. W. 2004. Guide to the software engineering body of knowledge. Computer Society. Cristia, M. 2009. Introduccion al Testing de Software. Universidad Nacional del Rosario.

[11] [12] [13] [14] [15] [16]

[17] ISO. 2005. JTC1/SC7-Software and Systems Engineering. ISO JTC. [18] ISO/IEC. 2012. ISO/IEC 29119 - Software Testing Standard. ISO/IEC. [19] IEEE. 1983. IEEE Std 829-1983 Standard for Software Test Documentation. IEEE. [20] IEEE. 1987. ANSI/IEEE Std-1008-1987 Standard for Software Unit Testing. ANSI/IEEE. [21] British Standards Institution. 1998. BS 7925-1:1998 Software testing. Vocabulary. [22] British Standards Institution. 1998. BS 7925-2:1998 Software testing. Software component testing. [23] Riancho, A. & Tartarelly, M. 2009. Testing de Seguridad en Aplicaciones Web Una Introduccion; IEEE Computer Society Argentina. [24] Hope, P. & Walther, B. 2008. Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast. OReilly Media. [25] Andrews, M. & Whittaker, J. A. 2006. How to Break Web Software: Functional and Security Testing of Web Applications and Web Services. Addison-Wesley. [26] Wysopal, C. et al. 2006. The Art of Software Security Testing: Identifying Software Security Flaws. AddisonWesley. [27] Dickson, J. B. 2008. Black Box versus White Box: Different App Testing Strategies. Denim Group. [28] ISECOM. Institute for Security and Open Methodologies. [29] ISECOM. OSSTMM Web App Alpha Web App methodology out to team members for testing osstmm webapp security. [30] OWASP. The Open Web Application Security Project. [31] OWASP. The OWASP Foundation. [32] OWASP. 2008. The OWASP Testing Guide v3. [33] Meucci, M.; Fedon, G. & Luptak, P. 2011. Planning the OWASP Testing Guide v4. [34] Acunetix Web Security Scanner. [35] IBM. 2012. IBM Security AppScan: Application security and risk management. IBM Software. [36] HP WebInspect. 2011. Quickly identify exploitable security vulnerabilities in Web applications, from development through production. Hewlett-Packard Development Company. [37] W3AF. Web Application Attack and Audit Framework. [38] Arachni. Web Application Security scanner framework. [39] GrendelScan Project. [40] Riancho, A. 2008. W3af user's guide. [41] Di Croce, M. N. 2009. Hacking tico y Frameworks Opensource. Proceedings IX Seminario Iberoamericano de Seguridad en las Tecnologas de la Informacin. [42] Riancho, A. 2009. A framework to 0wn the Web. Proceedings FRHACK. [43] Palanco, J. R. 2009. W3AF: un framework de test de intrusion web. Proceedings IV OWASP Spain Chapter Meeting. [44] Wiegenstein, A. et al. 2006. Web application vulnerability scanners: A benchmark. Virtual Forge. [45] Fong, E. & Okun, V. 2007. Web application scanner: Definitions and functions. Proceedings of the 40th Annual Hawaii International Conference on System Sciences. [46] Arkin, B.; Stender, S. & Mcgraw, G. 2005. Software penetration testing. IEEE Security and Privacy, 3(1), 8487.

127

CONFERENCIAS

128

Usability and Agile Methods: Debate and Integration Roads Usabilidad y Mtodos giles: Debate y Vas de Integracin
Universidad Politcnica de Madrid. Madrid, Spain. ammoreno@fi.upm.es. ABSTRACT This presentation tries to contribute to the existing debate in the software engineering community about how to deal with usability and UEX practices into the agile movement. Commonalties and differences in both approximations will be discussed as well as the different integration roads that are rising up. RESUMEN Esta presentacin tiene pretende contribuir al debate existente en la comunidad de Ingeniera del Software acerca de la integracin de prcticas de usabilidad y UEX en el desarrollo gil. Se presentarn los puntos comunes y diferencias entre ambas aproximaciones as como los principales enfoques de integracin entre ambas disciplinas que estn surgiendo en la actualidad. Categories and Subject Descriptors D.2.0 [Software Engineering. General] General Terms Design, Human Factors. Keywords Usability, User Experience, Agile Methods. Palabras clave Usabilidad de software, experiencia del usuario, mtodos giles.

Ana M. Moreno

there seems to be a tendency in the in the Agile community to recognize the need to explicitly incorporate usability practices into the agile process [2, 3]. However, the incorporation of such usability practices in an agile approximation is not a straightforward process. One of the main challenges highlighted by different authors is that Agile methods and UCD states different approaches to software construction. User interface design methods tries to get a holistic view of the user needs, while agile methods favor little up-front design and focus instead on delivering working software early [1]. Another discussion is related to the role of the user and the client in an agile process [4]. Usability methods highlight the need to have a direct implication of the user during the whole development process. Agile methods focus on delivery something useful for the customer, who plays a relevant role for identifying and prioritizing user requirements. However, the individual who is the customer may not be the real end user of the application. 3. AGILE AND USABILITY INTEGRATION ROAD There exists an important discussion in the agile and UEX community about how to combine both views. In this presentation we will address different perspectives for such combination: How to integrate UEX practices and SE practices into the lifecycle How to accommodate UEX practices to the agile philosophy 4. CONCLUSIONS In general, regarding the integration of UCD and agile approaches, although we can find in literature a few successful experiences of such integration, more research and practice is required to arrive at a comprehensive integration framework suitable for a more extended use. 5. REFERENCES
[1] Chamberlain N. M. S. & Sharp, H. Towards a Framework for
Integrating Agile Development and User-Centred Design. Proceedings of XP 2006. LNCS 4044, 143-153, 2006. [2] Ambler S. W. Tailoring Usability into Agile Software Development Projects. In: Law E.; Hvannberg, E. & Cockton, G. (Eds.), Maturing Usability. Quality in Software, Interaction and Value. Springer, Helidelberg. 2008. [3] Jokela, T. & Abrahamsson, P. Usability Assesment of an Extreme Programming Project. Close Co-operation with the Customer Does Not Equal Good Usability. PROFES, 2004. [4] Constantine, L. Process Agility and Software usability: Toward Lightweight use-CentredCentered Design. Information Age, 2001.

1. INTRODUCTION Agile methods are gaining significant acceptance, or at least visibility, in the software engineering field, and they are also gaining adepts in industry and even in some engineering schools. Agile development focus on the idea that user requirements are particularly prone to changes as users uncover new needs and correct their initial requirements as the software application unfolds. This claim appears to address an important issue in HCI. Moreover, the Agile movement also emphasizes the importance of human factors in the development process (see http://www.agilemanifesto.org). In this sense there also seems to be some tune between the Agile and Usability communities. In spite of this apparent alignment and even when the need to address usability and UEX in the agile process has been highlighted, there is no agreement about how to address this process. During this presentation we will discuss about existing debate in the agile and usability community, and the integration approximations that are being proposed. 2. THE AGILE USABILITY DEBATE Agile approximations and usability engineering have been characterized with common attributes, and therefore suitable for integration. Chamerlain et al. [1] discuss several of these similarities. Complementary,

129

Agent Participation in Engineering Processes Determined by NFRs Participacin de Agentes en los Procesos de Ingeniera, determinada por RNFs
Universidad de Antioquia. Medelln, Colombia gaurrego@udea.edu.co ABSTRACT In general, methodologies for defining and developing the conceptual model of a service or an intangible product, such as information systems, focus their actions on the process rather than product, more on the problem than on the solution. We show how, working with product orientation, you can obtain from its Non-functional requirements, a model representation of processes that supports the approach of the concurrent engineering. In the process model is made explicit how the agents involved in this approach participate. Keywords Non-Functional requirements, oriented approach process model, product

Germn Urrego G.

Universidad Nacional sede Medelln. Medelln, Colombia glgiraldog@unal.edu.co

Gloria L. Giraldo G.

producto, dando un tratamiento separado y posterior a los atributos de calidad. La progresiva irrupcin de las tecnologas de la informacin y las comunicaciones permite la masiva participacin de agentes interesados en soluciones informticas que cubren prcticamente todas las reas de intervencin de los seres humanos, pone de manifiesto la importancia de los requisitos Nofuncionales, como lo presentan, entre otros, [8, 9, 16], convirtindolos, en muchos casos, en los factores prioritarios y dominantes en la construccin de los productos [15, 23]. Nuestra investigacin en este campo, nos conduce a la obtencin de requisitos No-funcionales que nos permitan la conceptualizacin y aplicacin de diferentes enfoques participativos en la ingeniera, como es el caso del trabajo cooperativo, la ingeniera multidisciplinaria y concurrente, la ingeniera concurrente colaborativa, entre otros, con aplicacin a productos de diferentes campos. Por ejemplo, la elaboracin de una propuesta curricular de un programa en ingeniera con un enfoque multidisciplinar y concurrente [11], la incorporacin del concepto de desarrollo sostenible en currculos de ingeniera [20], la elaboracin de una ontologa de conceptos referidos al conocimiento necesario para la construccin de currculos de un programa de ingeniera [21], la elaboracin de un modelo de identificacin, prevencin y correccin de riesgos en la innovacin de productos y servicios. La consideracin de Requisitos No-funcionales en las mencionadas aplicaciones ser explicada en la seccin siguiente. En estas experiencias se aprecia la necesidad de partir de los Requisitos No-funcionales con la perspectiva de mejorar los enfoques participativos en la ingeniera. Igualmente se constata la escasez de modelos que definan las formas de participacin de los agentes interesados y la realizacin de los procesos a partir de los RNF de los productos. Como una contribucin a la mencionada deficiencia adoptamos una representacin del modelo de procesos que resalta las interacciones entre los agentes implicados. All se muestra cmo sobre este modelo se pueden aprovechar enfoques de ingeniera orientados hacia la innovacin de productos y servicios, como por ejemplo la co-creacin, reafirmando los RNFs de estos enfoques. Esto constituye el objeto del presente artculo. Luego de la introduccin, el artculo describe en Seccin 2 las experiencias de la explotacin de los RNFs para la elaboracin del modelo conceptual de un producto. En

RESUMEN En general las metodologas para definir y elaborar el modelo conceptual de un servicio o un producto intangible, como los sistemas de informacin centran su accionar en el proceso ms que el producto, ms en el problema que en la solucin. En este artculo mostramos cmo, trabajando con orientacin al producto, se puede obtener, a partir de sus Requisitos Nofuncionales, un modelo de representacin de procesos que soporte el enfoque de la Ingeniera concurrente (IC). En el modelo de proceso se hace explcita la forma como participan los agentes bajo dicho enfoque. Palabras clave Requisitos No-funcionales, modelo de procesos, enfoque orientado al producto.

1. INTRODUCCIN Los Requisitos No-funcionales (RNF) establecen el marco de restricciones que determinan el desarrollo y aprovechamiento de los productos. La ingeniera de los productos de calidad debe orientarse a satisfacer estos requisitos surgidos del medio social, natural, organizacional, y de las comunidades y los individuos, en consonancia con el desarrollo cientfico y tecnolgico. De esta manera se establece una relacin entre los atributos de los productos y sus procesos con los enfoques de ingeniera que los soportan. Este desafo impulsa el desarrollo de la Ingeniera de Requisitos. En el campo de la Ingeniera de Software, trabajos pioneros como los desarrollados por [1, 4, 19], captan la dependencia que tiene la calidad del producto respecto a la especificacin de sus requisitos. Muchos mtodos de anlisis y diseo de sistemas, considerando el tratamiento de los requisitos, que surgieron en los aos 90, han evolucionado, y an tienen vigencia, por ejemplo los trabajos de [2, 6, 10, 13, 17, 18, 24]. Desde sus orgenes se advierte la presencia de los atributos no directamente operacionales o No-funcionales, por ejemplo en [5], pero el desarrollo de las soluciones estaba ms centrado en las funcionalidades del

130

Seccin 3 se introduce el concepto de Ingeniera Concurrente (IC) y la adopcin de un modelo de procesos para este enfoque con base en los RNFs de dicho modelo. La conclusin y los trabajaos futuros son tratados en Seccin 4. Los reconocimientos y las referencias constituyen las dos ltimas secciones. 2. EXPLOTACIN DE LOS RNFs EN ELABORACIN DE PRODUTOS El estudio de requisitos es inherente al desarrollo de cualquier tipo de producto en todos los sectores de la economa. Los conceptos del desarrollo industrial se trasladan a productos con menos contenido material como son los productos de la Ingeniera de Software. El avance en los desarrollos propios en este campo permiten, en la actualidad, influenciar los modelos aplicados en la industria, Por ejemplo, los modelos de Lneas de Productos o Familias de Aplicaciones desarrollados en la Ingeniera de Software constituyen hoy en da un campo de desarrollo conjunto con los sectores empresariales. En la Ingeniera de Software, la elaboracin de productos con base en el ciclo de vida considera en la fase de conceptualizacin dos etapas: la definicin y el anlisis del producto. En la etapa de anlisis se parte del estudio de requisitos para llegar al modelado lgico del producto, centrando el estudio de requisitos en el proceso. Algunos mtodos propuestos en [14, 25], entre otros, basan su estrategia de obtencin de requisitos directamente en los agentes interesados en el producto y participantes en el proceso. Otras estrategias menos utilizadas para educir los requisitos se centran en el producto: unas basadas en modelos generales de dominio y otras basadas directamente en caractersticas del producto. Las primeras utilizan los modelos de dominio, como son, de una parte, los enfoques que emplean modelos jerrquicos de conceptos del dominio, como son las ontologas [26] o las Estructuras de Servicios y Objetos del Dominio [22]. De otra parte los enfoques orientados a Bases de Datos, en los cuales los conceptos del dominio se expresan en modelos de Entidad-Asociacin [7]. Las segundas, que ya se reconocen en algunos enfoques arquitectnicos, constituyen un campo en cual se requieren mayores esfuerzos de investigacin. Si bien, los requisitos No-funcionales se consideran en muchas metodologas, no se toman en general junto con el modelo del producto como el punto de partida para construir el modelo lgico de la solucin. En la presente investigacin se elaboraron algunos modelos para la construccin de soluciones en diversos campos, tales como el manejo de conocimiento en currculos de ingeniera y el tratamiento de riesgos en los procesos de la cadena de innovacin de productos. En el manejo de conocimiento acadmico se describen a continuacin dos experiencias.

2.1 Modelo de Conocimiento para Construccin y Evolucin de un Currculo El modelo de conocimiento para soportar la construccin y evolucin de un currculo debe plasmar en ste las caractersticas que se espera tenga el programa de formacin correspondiente. Adoptando la estrategia de partir de los requisitos No-funcionales asociados al producto, se establecen en la Tabla 1 estos requisitos para un modelo de currculo de ingeniera. La construccin y evolucin de un currculo es un proceso en el cual existen las etapas de entrada, de transformacin y de salida. La caracterizacin del modelo de construccin y evolucin del currculo mediante los RNFs se completa con los servicios que presta el modelo y las funciones para las que se elabora. Se pretende encontrar los elementos de un proceso para construir y soportar la evolucin de un currculo de ingeniera a partir de los RNFs de dicho currculo. Se concibe el proceso en tres etapas: entrada, transformacin, y salida. Se adopta para el proceso un modelo lingstico, donde la entrada est constituida por causas o antecedentes determinados por la expresin Por qu? La transformacin o realizacin responde a las expresiones Qu? y Cmo? La salida o consecuencia est determinada por la expresin Para qu? Al aplicar estas preguntas al modelo de conocimiento del currculo, caracterizado por cada uno de los RNFs de la Tabla 1 se obtienen como respuestas los conceptos que conforman el proceso para producir y soportar la evolucin de un currculo con los atributos enunciados en dicha tabla. Estos conceptos estn representados en la Figura 1.
Tabla 1. Requisitos de un modelo de conocimiento para construccin y evolucin de un currculo de Ingeniera

A manera de ejemplo, el requisito 1 gua el descubrimiento de los conceptos modelo curricular y propsitos de formacin. Las necesidades sociales y los problemas que dan origen al programa son identificados mediante el Requisito 2. El Requisito 3 determina el concepto conocimiento extraacadmico. Los Requisitos 3, 4, y 9 dan origen a los conceptos reas generales de conocimiento, reas de conocimiento especfico, unidades temticas, estrategias didcticas. El concepto de

131

competencias personales proviene del Requisito 7. El Requisito 8 determina el concepto dimensiones de formacin. Los Requisitos 5, 6, 10 y 11 contribuyen al concepto conocimiento acadmico externo, y al concepto conocimiento extra-acadmico.
Es fuente de

Los conceptos de la Figura 1 condensan el conocimiento que debe manejarse en la construccin y evolucin de currculos de ingeniera basados en problemas y orientados por competencias.

Sociedad
Fundamentacin Epistemolgica, Pedaggica, Filosfica, Psicolgica
reas del conocimiento

Conocimiento extraacadmico
Permite definir

Conocimiento acadmico Interno y Externo

Aportan

Estructura
Poseen Aporta

Mtodo
Requieren Caracterizan Permiten afrontar

Aporta Nutren

Dimensiones de formacin: ser, saber, hacer, comportarse

Problemas
Generan

reas temticas de referentes (ACM, IEEE, ECAES, ACOFI, ING-UDEA, Asociaciones, Universidades)
Se sintetizan en

Nutren

Orientan

Competencias por UOC y dimensin de formacin

Definen Desarrollan

Satisfacen

Soporta

Unidades de Organizacin Curricular (UOC)

Se concretan en

Determinan Conforman

Propsitos de formacin con dimensiones de formacin

Modelo pedaggico

Unidades Temticas y Estrategias didcticas

reas Temticas Profesionales propias, su relacin con los propsitos y dimensiones de formacin , los conceptos requeridos de cada rea

Fig. 1: Conceptos para la Construccin y evolucin de un Currculo de Ingeniera

2.2 Introduccin del Concepto de Sostenibilidad en un Currculo La adaptabilidad de los currculos debe permitir la incorporacin de nuevos conceptos en los currculos existentes. La introduccin en la propuesta de desarrollo sostenible en currculos de ingeniera, parte de la adopcin de una taxonoma de requisitos Nofuncionales que el currculo debe desarrollar para lograr el cometido de ayudar a que los estudiantes alcancen las competencias que les posibilite actuar en sus campos de ejercicio profesional en pro del desarrollo sostenible en sus dimensiones social, econmica, y del medio natural. En la Tabla 2 aparecen las categoras de Requisitos Nofuncionales adoptadas para el descubrimiento de los nuevos conceptos que tendran que introducirse o precisarse en el modelo curricular de la Figura 1, para orientar los currculos hacia el desarrollo sostenible. Los requisitos dieron lugar a la incorporacin de nuevas situaciones dentro de los problemas. En torno a los problemas surgieron nuevas preguntas que deba responder el programa. Estas preguntas completan el conjunto de las formuladas a partir de los problemas identificados en el medio social y organizacional. Para responderlas, el programa asume sus propsitos de formacin a partir de los cuales se determinan y organizan los contenidos curriculares y las competencias.
Tabla 2. Taxonoma de Requisitos de Sostenibilidad

2.3 Introduccin de los Conceptos Multi-disciplina, Concurrencia y Colaboracin en un Currculo Para la elaboracin de un currculo de ingeniera que incorpore los conceptos de la Ingeniera Multidisciplinaria Concurrente y Colaborativa se estableci un modelo de RNFs descrito en la Tabla 3. Tres categoras de RNFs componen el modelo: aspectos tcnicos, intervencin humana, y ciclo de vida. En la primera se identifican los requisitos: independencia del lugar y de la plataforma, tiempo real, facilidades de comunicacin y de medios. En la categora de intervencin humana se encuentran accesibilidad, pensamiento sistmico y trabajo en equipo. En relacin con el ciclo de vida del producto se consideran los requisitos: multiplicidad de mtodos y modelos, evolucin de modelos, integracin e interrelacin de procesos actividades y decisiones.
Tabla 3. Requisitos de un Modelo Curricular de Ingeniera que incorpore Conceptos de Multi-disciplina, Concurrencia y Colaboracin

132

Dentro de varias estrategias para la incorporacin de nuevos conceptos en un currculo basado en problemas, se opt por la de completar los problemas originalmente identificados en los contextos social y organizacional, con problemas correspondientes a los nuevos conceptos. Los RNFs antes descritos amplan los problemas originalmente identificados para ser atendidos por el programa de ingeniera. En torno a los problemas se formulan preguntas sobre cmo realizar tareas o elaborar elementos que contribuyan a las soluciones de los problemas. El procedimiento consiste en adicionar un conjunto de preguntas que el programa de ingeniera debe responder en trminos de sus propsitos de formacin. En esas preguntas se introducen los nuevos conceptos que se quieren incorporar al currculo: multi-disciplina, concurrencia y colaboracin. 3. MODELO DE REPRESENTACIN DE PROCESOS DE LA INGENIERA CONCURRENTE (IC) Las exigencias para el modelado de los procesos bajo el enfoque de la Ingeniera Concurrente parten de la definicin de esta forma de afrontar la realizacin de los procesos para el desarrollo de productos. Con los elementos incluidos en las definiciones corrientes en particular las propuestas por [12] y [3] y con las consideraciones que hemos realizado en el estudio de la co-innovacin de productos y en el anlisis y tratamiento de los riesgos en estos procesos definimos la Ingeniera Concurrente como un enfoque de gestin orientado a la obtencin oportuna de productos de calidad, en una configuracin integral, y dinmica de procesos, actividades, y acciones interrelacionados, secuenciales y/o no-secuenciales, simultneos y/o diferidos, paralelos y/o convergentes, expresados a diversos niveles de abstraccin; y considerando responsabilidades, objetivos, decisiones, y operaciones de agentes internos y/o externos. La Tabla 4 contiene las caractersticas (RNFs) esperadas de un modelo de procesos de la Ingeniera Concurrente de acuerdo con la definicin precedente de este enfoque.
Tabla 4. Requisitos de un modelo de representacin de procesos para la Ingeniera Concurrente

Para satisfacer los mencionados RNFs es preciso adoptar un modelo de procesos que los haga visibles y logrables. Del anlisis de los RNFs se observa que el modelo de representacin de procesos debe centrarse en agentes interactuantes, y, expresar y soportar dinmicamente las operaciones para las cuales se aplica este modelo. Determinar la participacin de los agentes en los enfoques de ingeniera, en este caso en la Ingeniera Concurrente, a partir de los RNFs del producto que se elabore en esos enfoques, es el objetivo del presente trabajo. Ese conjunto de operaciones que el modelo representa constituyen efectivamente un proceso, en el cual se aprecian claramente las entradas, las transformaciones y las salidas, as: (a) El ingreso o la modificacin de agentes internos y/o externos, de sus acciones e interacciones, (b) el despliegue sucesivo de procesos en micro-procesos, (c) el cambio del orden de ejecucin en procesos, actividades, y acciones, (d) la priorizacin y armonizacin de decisiones y objetivos generales, as como tambin de decisiones y metas particulares de los agentes, (e) desagregacin de servicios, procesos, y actividades, (f) reconfiguracin de actividades y procesos y el traslape entre ellos, g) integrarse con otros procesos y transferir conocimiento entre ellos y (h) Seleccionar actividades y establecer grafos parciales con el fin de mejorar el rendimiento. De las ocho operaciones descritas, la (a) es una operacin de entrada, de la (b) a la (f) son de transformacin, y la (g) y la (h) son operaciones de salida.

Fig. 2: Modelo de representacin de procesos de IC

Estas capacidades del modelo se aprecian en la Figura 2. En efecto, los nodos en lnea continua representan agentes internos a una organizacin, en tanto que los nodos en lnea punteada son externos. Una entidad es considerada un agente al ejercer como responsable en una intervencin. Las intervenciones son acciones o interacciones. Un agente es el responsable de una accin autnoma o de una interaccin con otro agente. Las mltiples trayectorias entre nodos son intervenciones de agentes que van desde el agente responsable de la intervencin hacia el agente interactuante. Las

133

intervenciones de agentes pueden expresar acciones, actividades, procesos, o servicios, los cuales constituyen cuatro niveles de abstraccin. En el nivel de abstraccin mayor la intervencin del agente expresa un servicio, en el nivel siguiente expresa un proceso, en el que sigue expresa una actividad, y en el nivel de abstraccin ms bajo expresa una accin. La accin la realiza un agente autnomo, que no admite agente interactuante, sobre un objeto del ms bajo nivel, en una estructura jerrquica de objetos de un dominio. Un servicio est constituido por un conjunto de procesos, un proceso est conformado por un conjunto de actividades y una actividad est conformada por un conjunto de acciones. El esquema de proceso de la Figura 2 puede representar las diferentes situaciones asociadas a los RNFs de la Tabla 4. La diversidad de agentes internos y externos, la multiplicidad de intervenciones a diferentes niveles de abstraccin, la libertad de inicio y terminacin, la simultaneidad, el paralelismo, la repeticin de las intervenciones de los agentes; la disponibilidad espacio temporal de los agentes, sus decisiones, situaciones y los medios que utilicen son caractersticas expresadas en los RNFs de la Tabla 4 y representables y analizables en el modelo de la Figura 2. No existen limitaciones debidas a la complejidad de los problemas para gestionar con base en el modelo propuesto las diferentes fases de un proyecto conducente a la elaboracin y entrega oportuna de un producto novedoso de alta calidad. La exteriorizacin de la participacin de los agentes en los procesos de la Ingeniera Concurrente, expresada en las ocho operaciones de entrada, transformacin, y salida obtenidas a partir de los RNFs de este enfoque de IC, satisfacen el objetivo del presente trabajo, el cual consiste en determinar la participacin de los agentes en un enfoque de ingeniera a partir de los RNFs que lo caracterizan. El producto que en este caso buscamos, es un modelo ajustado a las caractersticas de la IC, expresadas en los RNFs, en el cual se hace explcita la forma de participacin de los agentes. 4. DISCUSIN En los casos descritos en las dos secciones anteriores se le da preponderancia a los RNFs, en busca de un modelo lgico del producto que se quiere desarrollar. En los objetos tangibles, estos RNFs aparecen ms explcitos y directamente conectados con sus funcionalidades, un poco diferente a lo que ocurre con los objetos intangibles donde su manifestacin concreta se da al ejercer sus funcionalidades, generalmente incorporadas en otros objetos tangibles. Estas tendencias llevan a un equilibrio en la medida en que los objetos adquieren un carcter ms simblico y aparecen mltiples opciones de objetos con las mismas funcionalidades, diferencindose en propiedades dependientes de la cultura y de las percepciones individuales. Los objetos de la moda, por ejemplo, llegan a centrar su valor en atributos al margen de su funcionalidad.

La irrupcin de la tecnologa en todas las esferas de la vida de la sociedad y de los individuos, pone de manifiesto la importancia de los RNFs en los productos y servicios, en los cuales, por ejemplo, los soportados por la Ingeniera de Software deben anteponer RNFs tales como la seguridad, la usabilidad, el rendimiento, entre otros, a las funcionalidades. Con crecimiento acelerado del conocimiento de las tecnologas de la informacin y las comunicaciones, la globalizacin de la economa, y el crecimiento demogrfico, se crea un contexto en el cual la innovacin de productos y servicios es vital para el surgimiento, el crecimiento y la supervivencia de las empresas. Cuando los productos surgen de una necesidad expresa, como es el caso general, son aplicables los mtodos tradicionales que conducen a la elaboracin del modelo lgico y al de diseo con base principalmente en los Requisitos Funcionales. En la actualidad se evidencian otros caminos para el surgimiento de los productos y servicios, como la invencin o descubrimiento de objetos mediante la percepcin de una oportunidad o mediante elaboraciones mentales conducentes a la definicin de un producto o servicio sin haber establecido de antemano una necesidad. Esta aproximacin al producto centra la atencin en los RNFs. Otra aproximacin al producto se basa en la identificacin de los servicios o grandes funcionalidades del producto conforme con el conocimiento del dominio, antes de optar por el descubrimiento de los requisitos de los agentes. Ambas opciones basadas en el producto estn orientadas a la solucin en vez de centrarse en el problema como hacen los mtodos tradicionales: Los enfoques basados en el producto constituyen una va alterna a la del proceso para llegar a las funcionalidades. Esto nos posibilit elaborar modelos conceptuales por cada una las vas o combinando ambas, as como tambin proponer modelos para probar y validar soluciones obtenidas por vas alternas. Por otro lado, las vas alternas para las soluciones tienen vigencia cuando no es factible tener simultneamente el conocimiento completo del producto y del proceso. Cada una de estas vas es una opcin cierta para construir la solucin, dando lugar a mtodos giles fundados en un conocimiento pertinente, estructurado, y referido a la totalidad de la solucin. Esto constituye un avance respecto a la forma como se establece el conocimiento inicial para la aplicacin de un mtodo gil. Sobre estas bases es posible proponer nuevos mtodos giles orientados al manejo de conocimientos ms estructurado. Las investigaciones sobre los RNFs contribuyen a fortalecer la opcin de desarrollar mtodos y obtener objetos actuando ms en funcin de la solucin que del problema. 5. CONCLUSIN Y TRABAJO FUTURO En estas elaboraciones sobre los RNFs como punto de partida para la construccin de un producto se muestra

134

el carcter activo y determinante que tienen estos requisitos. Los mtodos que se ocupan de la elaboracin del modelo conceptual, y de diseo de un producto tangible, por su carcter concreto aprovechan de forma la directa visibilidad y expresividad de la orientacin hacia el producto. El carcter ms abstracto de los servicios y dentro de estos los sistemas informticos han dado lugar al empleo de mtodos orientados al proceso. Otros mtodos combinan ambas orientaciones, as como tambin los productos involucran elementos tangibles e intangibles. Las mquinas e instrumentos modernos, por ejemplo, cada vez incorporan ms elementos que implementan funciones lgicas. Nuevos mtodos son requeridos para el anlisis y el diseo de estos productos. La ingeniera de requisitos, estimulada desde la Ingeniera del Software, se extiende hacia los productos mixtos e influencia los mtodos empleados en la industria. En los mtodos empleados en la Ingeniera de Software predomina la orientacin al proceso y con estos se ha desarrollado la Ingeniera de Requisitos, con nfasis particular en los Requisitos Funcionales. La importancia creciente de los Requisitos No-funcionales impone una mirada hacia el producto y un espacio ms amplio para aplicar convenientemente la orientacin al proceso y al producto. Es necesario ms trabajo de investigacin en los mtodos orientados al producto y a la combinacin de ambas orientaciones. Mucho trabajo se realiza actualmente en modelos y mtodos relacionados con RNFs como una de las vertientes de la orientacin producto. En este campo se ubica el presente trabajo. Algunos enfoques de ingeniera, por ejemplo, la Ingeniera Concurrente combina las miradas del proceso y del producto en busca de una colocacin rpida de los productos novedosos en manos de los consumidores. En los ejemplos descritos en la Seccin 2 y en la propuesta de un modelo de representacin de procesos, en la Seccin 3, se muestran las grandes posibilidades que ofrece la orientacin al producto, particularmente la consideracin de los RNFs. En todos los casos, con diferentes medios se complet la caracterizacin del producto en trminos de los RNFs, con los servicios que el producto ofrece, su razn de ser; deducidos a partir de los RNFs inicialmente definidos. Estos servicios del producto conforman el modelo del dominio, el cual se puede detallar introduciendo los conceptos implicados en los servicios. En los dos casos correspondientes a la introduccin de nuevos conceptos en un currculo de ingeniera, basados en problemas de los contextos social y organizacional, se opt por ampliar los problemas para cubrir las demandas implicadas por la introduccin de los RNFs asociados a los nuevos conceptos adicionados. Frente a los problemas surgieron nuevas preguntas sobre cmo el currculo los puede atender considerando los nuevos

conceptos. Las respuestas aportaban a los propsitos de formacin del programa, que son los servicios que el currculo se propone lograr con estudiantes. En los otros dos casos relacionados con la elaboracin de un modelo, se utiliz el concepto de proceso para identificar los elementos asociados a los servicios (proceso efectuado por el modelo) realizados o soportados por el modelo (el producto). En el caso del modelo de conocimiento de un currculo de ingeniera, se utiliz un modelo lingstico expresando la entrada del proceso en trminos de causas (Por qu?), la transformacin o realizacin (Qu?, Cmo?), y la salida en trminos de efectos o consecuencias (Para qu?). En el caso del modelo de representacin de procesos de la Ingeniera Concurrente se formularon directamente, a partir de los RNFs del modelo de representacin de procesos de la IC, las operaciones de entrada, de transformacin, y de salida que soporta el modelo propuesto. La doble va, del proceso y del producto, nos permiti elaborar modelos de prueba para las primeras fases del ciclo de vida de los sistemas, propuestas para la aplicacin eficaz de mtodos giles para el anlisis y el diseo, as como la evolucin de modelos en las fases de anlisis y de diseo. Estos trabajos se continuarn en las fases de la cadena de innovacin de productos y en el anlisis y tratamiento de riegos en esa cadena, bajo diferentes enfoques de ingeniera. Los trabajos de modelado del dominio, considerando los RNFs del producto y los servicios que ste soporta, se continuarn en el marco de las Lneas de Productos. 6. REFERENCIAS
[1] Alford, M. W. A Requirements Engineering Methodology for Real-Time Processing Requirements. IEEE Transactions on Software Engineering. SE-3, 1, 1(1), 6069, 1997. Anton A. Goal-Based Requirements Analysis. ICRE'96, Colorado Springs, Colorado USA, IEEE, 1996. Belay, A. M.; Helob, P. & Kasieb, F. M. Concurrent engineering yesterday, today and tomorrow. Improving Complex Systems Today. 18th ISPE International Conference on Concurrent Engineering. Springer-Verlag London Limited, 425-432, 2011. Boehm, W. Verifying and Validating Software Requirements and Design Specifications. Software, IEEE, 75-88, 1984. Bowen, T. P.; Wigle, G. B. & Tsai, J. T. Specification of Software Quality Attributes, Report of Rome Air Development Center, 1985. Bubenko, J. Challenges in Requirements Engineering, In Proceedings of 2nd International Symposium on Requirements Engineering, IEEE 1995, 160-162, 1995. Chen, P. P. The Entity-Relationship Model: Towards a unified view of Data. ACM Transactions on Database Systems, 1, 9-36, 1976. Chung, K. L.; Nixon, B. A. & Yu, E. Using Quality Requirements to systematically Develop Quality Software. Proceedings, Fourth International Conference on Software Quality, McLean, Virginia, 1994.

[2] [3]

[4]

[5]

[6]

[7]

[8]

135

[9]

[10]

[11]

[12]

[13]

[14]

[15] [16]

Donzelli, P. & Bresciani, P. Improving Requirements Engineering By Quality Modeling, International Workshop on Requirements engineering for Software Quality (REFSQ03), 2003. Dowson, M. & Fernstrm, C. Toward Requirements for enactment mechanisms. ICSP2-2nd International Conference on Software Process. Berlin, Germanay, 1993. Giraldo, G. L. & Urrego, G. Problem-Based Construction of Engineering Curricula for Multidisciplinary and Concurrent Engineering Practice. 16th ISPE International Conference on Concurrent Engineering, Taiwan, 2009. Kamara, J. M. & Anumba, C. J. Evbuomwan NFO. Developments in the Implementation of Concurrent Engineering in Construction. International Journal of Computer-Integrated Design and Construction. 2, 68-78, 2000. Lamsweerde, A. V. et al. The KAOS Project: Knowledge Acquisition in Automated Specification of Software, Proc. AAAI Spring Symp. Series, Track: Design of Composite Systems, Stanford University, 59-62, 1991. Letier, E. & Lamsweerde, A. Agent-Based Tactics for GoalOriented Requirements Elaboration, Proceedings ICSE2002, 24th International Conference on Software Engineering, 2002. Levenson, N. G. Software: System Safety and Computers. Addison-Wesley, 1995. Mylopoulos, J.; Chung, K. L. & Nixon, B. A. Representing and Using Non- Functional Requirements: A ProcessOriented Approach. IEEE Transactions on Software Engineering, Special Issue on Knowledge Representation and Reasoning in Software Development, 18(6), 483497, 1992.

[17] Pohl, P. K. Process Centered Requirements Engineering. J. Wiley and Sons Ltd., 1996. [18] Rolland, C.; Souveyet, C. & Salinesi, C. Guiding Goal Modelling Using Scenarios, TSE special issue on scenario management, 1998. [19] Ross, D. & Schoman, K. Structured Analysis for Requirements Definition. Transactions on Software Engineering, IEEE, 3(1), 6-15, 1977. [20] Urrego, G. & Giraldo, G. L. Evolucin de currculos de Ingeniera hacia la sostenibilidad. XXXIX Conferencia Nacional de Ingeniera: la educacin en ingeniera para el desarrollo sustentable. Irapuato. Mxico, 2012. [21] Urrego, G., Giraldo, G. L. Organizational memory supporting the continue transformation of engineering curricula. 14th ISPE International Conference on Concurrent Engineering, Sao Jose dos Campos, 2007. [22] Urrego, G., Giraldo, G. L. Estructuras de servicios y de objetos del dominio: una aproximacin al concepto de ontologa. Tecnolgicas, 15, 2006. [23] Urrego, G. Reasoning Non-Functional Goals and Features in Web systems. ICCTA International Conference. Damascus, Syria, 2004. [24] Yu, E. Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. Proceedings of the 3rd IEEE Int. Symp. on Requirements Engineering (RE'97), Washington D.C., 226-235, 1997. [25] Yu, E. Agent Orientation as a Modelling Paradigm. Wirtschaftsinformatik, 43(2), 123-132, 2001. [26] Zapata, C. M.; Giraldo, G. L. & Mesa, J. E. Una propuesta de metaontologa para la educcin de requisitos. Revista Chilena de Ingeniera, 18(1), 26-37, 2010.

136

From Requirements to Code: Model-Driven Software Development in Practice De Requisitos a Cdigo: Desarrollo de Software Dirigido por Modelos en Prctica
scar Pastor Lpez
Centro de Investigacin PROS, Universitat Politcnica de Valncia. Valencia, Espaa opastor@pros.upv.es lruiz@pros.upv.es sergio.espana@pros.upv.es Keywords Model driven software development, communication analysis, business process reengineering, business process modelling.

Marcela Ruiz

Sergio Espaa

ABSTRACT Model-driven software development (MDD) is a paradigm that provides to the requirement models of some advantages: as the potential to derive conceptual models for generating software in an automatic way. The automatic generation of software products allows an easy adoption of requirements engineering methods in an industrial environment. For this reason, design and/or adaptation of requirements methods into MDD environments increases the role of models in a software process development. This presentation tries to contribute to the existing debate around of MDD in practice. In the PROS Research Centre, a proposal to link requirements engineering techniques with conceptual modelling has been developed. As a practical case, we have applied the framework to integrate Communication Analysis a communicationoriented business process modelling and requirements method and OO-Method an object-oriented model-driven development method. This integration framework follows a model-driven development approach. We propose a development framework that involves tools (e.g. Eclipse) to support modelling tasks. Novel meta-modelling techniques and model transformation were considered in the proposed integration framework. RESUMEN El desarrollo dirigido por modelos (DSDM) es un paradigma que puede dotar a los modelos de requisitos de un valor agregado: el potencial para derivar de ellos los modelos conceptuales que servirn para la generacin automtica de software, permitiendo as una fcil adopcin de metodologas de requisitos en un entorno industrial. De este modo, el diseo y/o adaptacin de mtodos de requisitos en entornos de DSDM le da un papel ms activo a los modelos de requisitos dentro del proceso de desarrollo de software, ms all de ser solo parte de la documentacin del sistema. Esta presentacin tiene como objetivo principal generar un debate en torno a los retos que envuelve el desarrollo de software dirigido por modelos en la prctica. En el Centro de Investigacin PROS se ha desarrollado una propuesta que busca unir tcnicas avanzadas de ingeniera de requisitos y modelado conceptual. Como caso prctico, la integracin de Anlisis de Comunicaciones un mtodo de modelado de procesos de negocio orientado a la comunicacin y OO-Method un mtodo de desarrollo de software dirigido por modelos orientado a objetos es un aporte que ilustra el uso de mtodos y herramientas. De este modo el marco aprovecha herramientas para el soporte de modelado como Eclipse y se emplean tcnicas de meta-modelado y transformacin de modelos que en la actualidad es promulgado por la academia y la comunidad de ingeniera de software. Palabras clave Desarrollo de software dirigido por modelos, anlisis de comunicaciones, OO-Method, reingeniera de procesos de negocio, modelado de procesos de negocio. General Terms Management, documentation, languages, design.

1. INTRODUCCIN Los sistemas organizacionales requieren mtodos de especificacin de requisitos para identificar las necesidades y caractersticas de los procesos de negocio. Las prcticas de ingeniera de requisitos han permitido involucrar a los usuarios en el proceso de desarrollo de software, lo cual permite la correccin temprana de errores y el ndice de aceptacin del producto final se ve incrementado [1]. Incorporar tcnicas avanzadas de ingeniera de requisitos en la industria ha sido un reto que la comunidad de ingeniera de software reconoce, y en el cual diversos grupos de investigacin se han dedicado a proponer soluciones y estrategias para afrontar la dificultad de transferencia tecnolgica a entornos de produccin reales. Por otro lado, el Desarrollo de Software Dirigido por Modelos (DSDM) es un paradigma que dota a los modelos de software de grandes ventajas, como lo es la generacin de productos software de forma automtica mediante transformaciones de modelos que llevan a productos software compilables y ejecutables. El paradigma de DSDM permite resolver algunas de las dificultades presentadas al momento de realizar la transferencia de tcnicas de ingeniera de requisitos a la industria. En la prctica industrial, las especificaciones de requisitos se encuentran establecidas en modelos, los cuales describen el software que dar soporte a las actividades y necesidades de la industria. Dichos modelos que representan la especificacin de necesidades y requerimientos del sistema, pueden ser usados para derivar de ellos los modelos conceptuales enfocados al diseo del software. Los modelos conceptuales resaltan e incrementan la importancia de los modelos de requisitos en un entorno industrial. De este modo, la especificacin de requisitos pasa a ser una parte activa en el proceso de desarrollo de software. Dicha perspectiva de modelos corresponde con el paradigma de DSDM, donde el cdigo del software es trazable con los modelos del sistema [2]. De este modo, para llevar a la prctica el uso de tcnicas avanzadas de ingeniera de requisitos en mbitos industriales, la academia debe disear y/o adaptar los mtodos de ingeniera de requisitos para que stos sean compatibles con entornos de DSDM. Un marco genrico para adaptar mtodos de ingeniera de requisitos existentes en ambientes de DSDM ha sido desarrollado

137

en el Centro de Investigacin PROS [3]. Como caso prctico, se han realizado todos los pasos del marco para integrar Anlisis de Comunicaciones un mtodo de modelado de procesos de negocios orientado a la comunicacin [4] y OO-Method Un mtodo de desarrollo dirigido por modelos orientado a objetos [5]. El marco en s mismo, sigue el paradigma de DSDM para ofrecer un conjunto de etapas y tareas que lleven a la integracin de requisitos a cdigo. Durante la presentacin, se discutirn las ventajas del uso de mtodos como Anlisis de Comunicaciones en entornos de DSDM y su integracin con OO-Method. Adicionalmente, se discutir la importancia del uso de meta-modelos para dar soporte a la integracin de dichos mtodos en entornos de DSDM y otras aplicaciones prcticas como el mantenimiento de sistemas legados, reingeniera y evolucin de modelos. 2. ANLISIS DE COMUNICACIONES Y OO-METHOD: DE REQUISITOS A CDIGO Los sistemas organizacionales requieren mtodos de captura y especificacin de requisitos para identificar las necesidades y caractersticas intrnsecas de sus procesos de negocio. Analizar el Sistema de Informacin desde una perspectiva comunicativa es necesario, debido a que los procesos y actores del sistema son observados en un mismo nivel de abstraccin. Adicionalmente, las perspectivas comunicativas permiten analizar el sistema de informacin desde un punto de vista centrado en el cmo se comunica la informacin, como sta es intercambiada, cmo evoluciona y es enriquecida. Anlisis de Comunicaciones es un mtodo de ingeniera de requisitos que propone describir los procesos de negocio desde una perspectiva comunicacional donde los actores del sistema juegan el rol principal como emisores y receptores de las comunicaciones en un sistema de informacin. OO-Method es un mtodo de DSDM, cuyos modelos conceptuales se encuentran soportados por Integranova, un compilador de modelos que permite la generacin automtica de cdigo ejecutable [6]. La unin de los modelos de requisitos de Anlisis de Comunicaciones y los modelos conceptuales de OOMethod se encuentra guiada a travs de un alineamiento ontolgico entre ambos mtodos y una serie de reglas de transformacin de modelos. Dicha integracin metodolgica se encuentra descrita en [7]. Proporcionando herramientas de modelado y motores de transformacin de modelos, el paso de requisitos a cdigo es automtico. 3. TCNICAS DE METAMODELADO Y HERRAMIENTAS Los modelos de requisitos de Anlisis de Comunicaciones se encuentran conformados por el Communicative Event Diagrams (CED) y las Message Structures (MS). CED es una tcnica de modelado de procesos de negocio a travs de la cual es posible especificar aspectos dinmicos y estticos del sistema

de informacin. MS es una tcnica de anlisis y diseo de las interacciones comunicativas de sistemas de informacin. Teniendo en cuenta los conceptos de los modelos de CED y MS, la sintaxis abstracta es definida mediante tcnicas de meta-modelado. Siguiendo una aproximacin de arquitectura dirigida por modelos (ADM) [8] y teniendo en cuenta que un meta-modelo es un modelo, la aproximacin de ADM puede ser tenida en cuenta para la especificacin de conceptos de mtodos de requisitos. De este modo, un meta-modelo independiente de plataforma (PIM) para los modelos de requisitos de Anlisis de Comunicaciones es adecuado para la especificacin de conceptos y relaciones sin tener en cuenta el soporte tecnolgico de los modelos del mtodo. La principal ventaja de mantener un meta-modelo PIM para el mtodo, es brindar la posibilidad de anlisis de la especificacin del mtodo con expertos y diseadores los cuales pueden modificar y evolucionar el mtodo a nivel de modelos sin necesidad de tener en cuenta aspectos tecnolgicos. Posteriormente, cuando el meta-modelo PIM se encuentra en un nivel de madurez aceptable, es posible complementar y modificar dicho meta-modelo para que aspectos tecnolgicos y de la plataforma destino sean tenidos en cuenta. Para el caso particular de Anlisis de Comunicaciones, la plataforma de desarrollo de Eclipse ha sido tenida en cuenta [9]. Tecnologas como EMF, GMF y ATL han sido las plataformas sobre las cuales han podido ser implementados los modeladores grficos para CED y MS. Las reglas de transformacin de modelos de Anlisis de Comunicaciones a los modelos de OO-Method es soportado a travs de la plataforma ATL de Eclipse.

METAMODELO PIM 1.0 CONCEPCIN EJEMPLOS ILUSTRATIVOS time

VALIDACIN INTERNA

METAMODELO PIM 2.0

VALIDACIN EXTERNA

METAMODELO PIM 3.0

2 EJEMPLOS DE LABORATORIO ENTREVISTAS CON EXPERTOS EN AMBOS MTODOS

EJERCICIO DE EVALUACIN DE USABILIDAD (UPV) EN HERRAMIENTA DE MODELADO EJERCICIO DE EVALUACIN DE EXPRESIVIDAD (UPV)

METAMODELO PIM 1.0 METAMODELO BSICO CON CONCEPTOS, ATRIBUTOS, RELACIONES Y CARDINALIDADES

METAMODELO PIM 2.0 NUEVOS CONCEPTOS Y RELACIONES, CORRECCIN DE ERRORES Y CONFLICTOS DEFINICIN DE REGLAS OCL PARA REPRESENTACIN DE RESTRICCIONES

METAMODELO PIM 3.0 CONCEPTOS Y RELACIONES REESTRUCTURADAS. SOPORTE PARA MS MEDIANTE EDITOR TEXTUAL Y RBOL JERRQUICO

Fig. 1: Lnea de tiempo de desarrollo del meta-modelo PIM para los modelos de requisitos de Anlisis de Comunicaciones

La Figura 1 representa la lnea de tiempo de desarrollo del meta-modelo PIM de los modelos de requisitos de Anlisis de Comunicaciones. Una primera versin fue desarrollada donde los conceptos principales del mtodo fueron tenidos en cuenta y una serie de ejemplos ilustrativos fueron desarrollados. Una validacin interna fue llevada a cabo con expertos de ambos mtodos para evaluar que los conceptos, relaciones, atributos y cardinalidades representen las caractersticas de cada aproximacin. Finalmente, se llev a cabo una validacin externa con un grupo de estudiantes de mster de la Universitat

138

Politcnica de Valncia. Dichos estudiantes tienen un perfil cercano a un analista de sistemas de informacin. Los resultados de la evaluacin permitieron la mejora y desarrollo de nuevos conceptos y relaciones que dieron lugar a una versin del meta-modelo PIM mejorada. Teniendo como base el meta-modelo PIM de los modelos de requisitos, un meta-modelo PSM fue especificado en las herramientas EMF de Eclipse, donde posteriormente fueron desarrollados los mdulos de modelado y motor de transformacin de modelos. 4. CONCLUSIONES La posibilidad de integrar mtodos de ingeniera de requisitos en ambientes de DSDM ha motivado diferentes lneas de investigacin en el rea de ingeniera de software. Por esta razn, el debate alrededor de posibles soluciones para involucrar la especificacin de requisitos en el proceso de desarrollo de software abre diversas ventanas de discusin. Anlisis de Comunicaciones es un mtodo de ingeniera de requisitos que ofrece una perspectiva para analizar sistemas de informacin desde el punto de vista comunicativo, permitiendo observar el sistema desde un punto de vista esttico y dinmico. Debido a la diversa cantidad de informacin que puede ser analizada y diseada siguiendo las guas de uso del mtodo, le convierte en un mtodo de especificacin de requisitos potencialmente adaptable en un entorno DSDM. Por este motivo, como caso prctico se ha llevado a cabo la integracin, y un soporte tecnolgico con herramientas tecnolgicas que son idneas para el desarrollo de entornos de modelado y transformacin de modelos. En la actualidad, se est explorando la posibilidad de incorporar tcnicas de reingeniera organizacional dirigida por modelos para dar soporte a la evolucin de los modelos de requisitos. Dicha evolucin ser guiada por modelos de metas que justifican y representan la necesidad que da lugar a un sistema deseado.

5. REFERENCIAS
[1] Foster, S. T. & Franz, C. R. User involvement during information systems development: a comparison of analyst and user perceptions of system acceptance. Journal of Engineering and Technology Management, 16, 329-348, 1999. [2] Nuseibeh, B. & Easterbrook, S. Requirements engineering: a roadmap. Presented at the Conference on The Future of Software Engineering (ICSE'00), New York, USA, 2000. [3] Ruiz, M. A model-driven framework to integrate Communication Analysis and OO-Method. Master in Software Engineering, Formal Methods and Information Systems, Departamento de Sistemas Informticos y Computacin (DSIC), Universitat Politcnica de Valncia, Valncia, 2011. [4] Espaa, S. et al. Communication Analysis: a requirements engineering method for information systems. Pesented at the 21st International Conference on Advanced Information Systems (CAiSE'09), Amsterdam, The Netherlands, 2009. [5] Pastor, O. & Molina, J. C. Model-Driven Architecture in practice: a software production environment based on conceptual modeling. New York: Springer, 2007. [6] http://www.integranova.com. [7] Espaa, S. Methodological integration of Communication Analysis into a Model-Driven software development framework. PhD. Computer Science, Departamento de Sistemas Iformticos y Computacin (DSIC), Universitat Politcnica de Valncia, Valencia, 2011. [8] OMG. MDA Guide. In How is MDA used? OMG (Ed.), 1-62, 2003. [9] http://www.eclipse.org/

139

Reusing Formal Proofs Through Isomorphisms

Invited Talk
Departments of Mathematics and Computer Science Universidade de Braslia Braslia D.F., Brazil

Mauricio Ayala-Rincn ayala@unb.br 1.

ABSTRACT
Formalization of computational objects, software and hardware, is the unique manner to guarantee well-behavior of computer programs and hardware, at least from the mathematical and logical point of view. Several verication and testing approaches have been proved of great applicability in this area being their usability made evident through real applications in the development of critical systems. Reusing the given correctness proofs of a specication in order to verify that an improved version of the originally given specication is also correct requires a great deal of eort and in several cases simple algorithmical improvements make it necessary the development of new correctness proofs from scratch. This paper sketches a methodology based on construction of isomorphisms between data structures that allows reusing correctness proofs for specications that are obtained basically changing data structures. The case of study is a specication of the well-known Dolev-Yao cryptographic model in which the characterization of security was formalized in the proof assistant PVS. The given formalized specication was based on the representation of sequences of cryptographic operators via a data structure of nite sequences. The improvement consists of a specication in which lists will be used instead nite sequences.

INTRODUCTION

Formal methods are of great usability to certify quality of software and hardware design, but reusing mechanical demonstrations after the original design is modied, usually requires rebuilding proofs from scratch. As an example, consider the following specication of a searching function of keys over lists of naturals written in the language of the well-known proof assistant PVS1 [3].

search(i : nat, l : list[nat]) : RECURSIVE nat = IF null?(l) THEN length(l) ELSIF car(l) = i THEN 0 ELSE 1 + search(i, cdr(l)) ENDIF MEASURE length(l) Correctness of this searching method consists in proving that whenever given as input a natural key i and a list of natural keys l, the computed output will be either the length of the list, if the searched key does not occurs in the list, or a valid index k of the list, that is a natural below the length of the list, such that i in fact occurs at position k in the list l. The positions of l are indexed from 0 to its length minus one. These correctness constraints can be stablished as the two lemmas below, respectively.

Categories and Subject Descriptors

F.3.1 [Specifying and Verifying and Reasoning about Programs]: Specication techniques; F.4.1 [Mathematical Logic]: Proof theory; D.2.4 [Software/Program Verication]: Formal methods

Keywords
Specication and verication, Formalization, Proof assistants - PVS, Reusing formal proofs Research funded by the Brazilian Research Council CNPq and the District Federal Foundation for Research FAPDF. Author partially funded by the Brazilian Research Council CNPq.

not_member_gives_length : LEMMA FORALL(l : list[nat], i : nat): NOT member(i,l) IMPLIES search(i, l) = llength search_works : LEMMA FORALL (l : list[nat], k : nat) : member(k, l) IMPLIES nth(l, search(k, l)) = k Formalizations of both these lemmas are obtained by induction on the length of lists after working particular characteristics of the list abstract data type and its primitive
1 PVS specication and verication system available at http://pvs.csl.sri.com/

140

operators, such as decreasingness of the length of the cdr of non empty lists and preservation of the contents of the list after applying cdr, as well as validity of the position computed expressed through a PVS type correctness condition (TCC):

R+ , , 1, > via exp in the following form: R, +, 0, > R + 0 >

/ R+ , , 1, > / R+ / /1 />

x (x):=exp(x) + + := 0 0 :=1 > > :=>

search_works_TCC1: OBLIGATION FORALL (l: list[nat], k: nat): member(k, l) IMPLIES search(k, l) < length[nat](l);

This TCC is automatically generated by the proof assistant PVS from the specication of lemma search_works since the function nth is typed as nth : [l: list[nat], j: below[llength]] -> nat

Since exp is bijective, it is invertible, and one knows its inverse, denoted as , is the function ln. Thus, one has two useful lemmas: Lemma (isomorphism 1) is the identity in R Lemma (isomorphism 2) is the identity in R+ In fact, one knows that x : R. ln(exp(x)) = x and x : R+ . exp(ln(x)) = x. Jointly with these isomorphism lemmas, several homeomorphic properties related with the preservation of operators through the isomorphism functor are necessary: Lemma (preservation of +) x, y : R. (x + y) = (x) + (y) Lemma (preservation of > 1) x, y : R. x > y (x) > (y) In fact, x, y : R. exp(x + y) = exp(x) exp(y) and x, y : R. x > y exp(x) > exp(y). Also, one has homeomorphic properties related with the preservation of operators through the inverse of the isomorphic functor: Lemma (preservation of ) x, y : R+ . (x y) = (x) (y) Lemma (preservation of > 2) x, y : R + . x > y (x) > (y) In fact, x, y : R+ . ln(x y) = ln(x) + ln(y) and x, y : R+ . x > y ln(x) > ln(y). Now, suppose the following equational theorems in which new operators ( ) and ( )1 are involved, have been proved in R, +, > : Theorem (additive inverse) x : R. x + (x) = 0 Theorem (ln of mult. inverses) x : R+ . ln(x1 ) = ln(x) The proof of this theorem can be reused in order to prove new theorems in the structure R+ , , > , for instance Theorem (multiplicative inverse) x : R+ . x x1 = 1 can be proved as follows:

and search_works uses l and search(k,l) as arguments of nth. Lists and searching on lists can be applied in several computational applications, but although all these formalizations on lists are simple, the use of lists is optional. For instance, indexation of sequences of large size requires optimal compression of information given by means of bit-code arrays and even more sophisticated data structures such as sux and array trees. Consequently, adopting other data structure will imply the development of new specialized formalizations according to the chosen data structure of the modied specication. Here, a formal discipline based on construction of isomorphism functors is proposed in order to reuse formalizations when dierent data structures are chosen to solve the same problem. The suggested approach proposes the exploration and construction of isomorphism functions together with formalization of their associated homeomorphic properties. These isomorphisms bijectively map the basic structures, relational and functional objects involved in the original given specication, for which it is supposed several formalizations were done, and the new selected data structures and their associated relational and functional objects. In this way the specier is able to reuse formalizations previously constructed for the specication based on the original data structure.

2.

BACKGROUND

Mathematically, isomorphisms are dened as a bijective transformations between algebraic structures which preserve relations and functions. Thus, an isomorphism maps not only elements of the domain of one structure into the other, but also functions and relations from one structure into functions and relations of the other one. For instance, exp is an isomorphism between R and R+ , since it is a bijective function. Notice also that exp(x + y) = exp(x) exp(y), then the corresponding operation to + in R+ is and vice-versa. Also, the ordering relation > is preserved: x > y if and only if exp(x) > exp(y). Thus, the relation corresponding to > in R is also > in R+ . Summarizing, one has a transformation form the structure R, +, 0, > into the structure

141

1. x x1 = exp ln(x x1 ), by Lemma isomorphism 2; 2. exp ln(x x1 ) = exp(ln(x) + ln(x1 )), by preservation of ; 3. exp(ln(x) + ln(x )) = exp(ln(x) + ln(x)), by Theorem of ln of mult. inverses; 4. exp(ln(x) + ln(x)) = exp(0), by Theorem of additive inverse; 5. exp(0) = 1, by application of the isomorphism exp.
1

families of sets, and from functions into functions and relations into relations, such that the following homeomorphic preservation properties hold: For all f F , and m-tuple of well-typed arguments for f , x1 , . . . , xm , supposing f is an m-ary function of type i1 in , (f (x1 , . . . , xm )) = f (i1 (x1 ), . . . , im (xm )); For all p P, and m-tuple of well-typed arguments for p, x1 , . . . , xm , supposing p is an m-ary predicate of type i1 in , (p(x1 , . . . , xm )) if and only if p (i1 (x1 ), . . . , im (xm )).

In this way, a new proof of a theorem in the structure R, +, 0, > is obtained from proofs in the other structure, that is R+ , , 1, > , by applying isomorphic properties without the need to prove additional algebraic properties in the original structure. Of course, this kind of reuse of proofs can be applied in computational formalizations, but always depending on the specicities of the objects, functions and relations being treated.

For brevity, subscripts of the isomorphic transformation are omitted, but it should be noticed that this transformation is in general polymorphic and poly-sorted. The former, since having several sorts, the equality relation is polymorphic and it has to be mapped by the isomorphism. For our structures R, +, > , R+ , , > , the isomorphism maps x R as (x) = exp(x), + is mapped in and > into >. Thus, (x + y) = (x) + (y), that is exp(x) exp(y). In general, isomorphisms can be sketched as in Fig. 1.

3.

ISOMORPHIC TRANSFORMATION IN COMPUTATIONAL SPECIFICATIONS

Several additional aspects need special attention when dealing with computational specications and formalizations; among them, it deserves consideration the fact that in computation one deals with poly-sorted functions and relations. Thus, while in mathematics one deals with isomorphisms from a unique domain into another one (e.g., from R into R+ ) in the denition of isomorphism functor in the computational context, it is necessary to deal with transformations between a family of sorts and signatures of poly-sorted functions and relations. A poly-sorted signature is a structure of the form A, F, R , where A is a nite family of sorts, say {1 , . . . , n }; F is a nite set of functions together with their types, that is, for each f F , one has a type description of f : i1 in , where and each ij , for 1 j n, is a type in the family of sorts; and, R is a nite set of predicates together with their types, that is, for each p R, one has a type description of p : k1 km , where each kj , for 1 j m, is a type in the family of sorts. This way, it is possible to dene poly-sorted functions such as the element of a list of naturals, nth : index List[N] N, which is intended to take as input a valid index of a list of naturals and to give as output the natural in this position of the list. Now, the denition of isomorphism can be stablished. Denition (Isomorphisms between poly-sorted signatures) Let A, F, R and B, G, P be signatures consisting of families of sets A = {A1 , . . . , An } and B = {B1 , . . . , Bn }, functions F = {f1 , . . . , fk } and G = {g1 , . . . , gk } and relations R = {r1 , . . . , rl } and P = {p1 , . . . , pl }. An isomorphism between these structures, is a bijective mapping from the

4.

CASE-STUDY: LISTS VERSUS SEQUENCES IN A CRYPTOGRAPHIC FORMALIZATION

In this section, reuse of proofs through isomorphisms in a simple case of study will be considered. Alternative representation of the freely generated monoid representing chains of cryptographic operators in a formalization of the DolevYao cascade protocol model ( [1]) as presented in [2] and subsequently in [4] will be considered. Essentially, a cryptographic protocol in the Dolev-Yao model is a sequence of alternating chains of cryptographic operators, which species a communication protocol to be obligatorily followed by the actors of a communication net. This is a two party model, but is of great relevance and usability in a great variety of current (two and multi party) protocols since it is embedded as part of most of the modern electronic protocols. Any user u U owns encrypt and decrypt keys Eu and Du . The set {Eu | u U } {Du | u U } is the alphabet of the language of the protocol and words freely generated by this alphabet are steps of a protocol. From the algebraic point of view, this is the freely generated monoid over this alphabet in which concatenation and empty word, denoted as , play the role of the binary operator and identity of the monoid. Additionally, one considers the congruences Eu D u = Du Eu = , u U

Thus, for any message, or plain text M , one has Eu (Du (M )) = Du (Eu (M )) = M . Security in this model is characterized by two properties; namely, existence of encrypt operators in the rst step of

142

A, F , R AA f F

x A (x) f f

/ B, G, P /BB / f G

(f (x1 , . . . , xm )) = f ((x1 ), . . . , (xm )) pR

p p

/ p P

(p(x1 , . . . , xm )) p ((x1 ), . . . , (xm ))

Figure 1: Isomorphism between poly-sorted signatures the protocol and balancing property in each step of the protocol. The latter is explained as the existence of encrypt operators in any step of the protocol for any user for which a decrypt operator appears in this step of the protocol. Additionally, any malicious user, or intruder, can follow the protocol as any honest user for starting communication with any other user or continuing a communication started by another user, but also he/her can passively observe the communication between other user and eventually supplant other users. All this gives as result an admissible language for the intruder. Security or a protocol means that using this admissible language, any potential malicious user cannot extract the message hidden by the protocol. Details can be studied in the analytical proofs both in [1] and the complete PVS formalization reported in [4] for which 1.651 lines (80 KB) of specication and 55.300 lines (3.8 MB) of PVS proof commands where necessary. The option chosen to represent monoids in [4] is the structure of nite sequences. A nite sequence is a structure of the form (# length : nat, seq : [0..length-1] -> CryOp #) The isomorphism functor from sequences to lists of cryptographic operators includes several transformations, as the ones presented in Fig. 2. In order to have the isomorphic engine, all the additional inexistent necessary operators (such as (_seq ) in Fig. 2) should be specied as well as all necessary isomorphic properties should be formalized, explicitly. In particular, on the one side, sequences are isomorphically transformed into lists through the following recursive function. (s : seq[CryOp]) RECURSIVE : list[CryOp] = IF slength = 0 THEN null ELSE cons(sseq(0), (s(1, slength - 1)) ENDIF MEASURE seqlength Additionally, several homeomorphic properties should be guages, lists of objects of type T, lists[T], are built from the empty list, that is denoted as null and through the constructor cons, that is a function of type T, list[T] -> T, and for an object of type T and a list of type list[T] builds the list whose rst element is the input object and whose tail is the original list. The type of lists is parameterized and PVS will automatically generate a variety of ADT lemmas including as well a correct inductive schema of proofs. For illustration, consider reusing the proof of

Theorem(length of empty sequences) slength = 0 IFF s = empty_seq to prove that the following analogous result over lists.

Theorem(length of null list) length(l) = 0 IFF l = null

where length is the length of the sequence and seq is the access function of the sequence which for any valid index k, from 0 to length - 1, gives as output the cryptographic operator (CryOp) at position k of the nite sequence, say s. This is done through calls of the form sseq(k). By the elaborated typing discipline of the PVS specication language, whenever the type of k is dierent from [0..length-1], the term sseq(k) is ill-typed. The question of arises, from several algorithmic perspectives and dierent programers point of views, whether this is the better style to specify chains of cryptographic operators. And according to the eciency necessities (e.g., either reducing running time or space) and dierent programming styles, alternative data structures can be chosen instead nite sequences. For instance, instead nite sequences, ADTs as lists of CryOp can be used. list[CryOp] In the PVS specication language, as in other functional lan-

143

{CryOp, seq[CryOp], N, N, . . .}, {length, seq, . . .}, {=seq[CryOp] , . . .}

{CryOp, list[CryOp], N, N+ , . . .}, {length, ( seq) . . .}, {=list[CryOp] , . . .} CryOpt seq[CryOpt] N N(index) length seq . . .
op op

/ CryOpt / list[CryOpt] /N / N+ (position) / length( ) / ( seq)

. . .

s (s)

n n

n n+1

slength length((s))

sseq (i:[1,length]) . nth(i,(s))

/
. . .

. . . Figure 2: Isomorphism between sequences and lists of CryOps formalized as, for instance:

Lemma B1 (length(l)) = ((l))length Lemma B2 (nth(k, l)) = ((l))seq((k)) Lemma A1 (slength) = length((s)) Lemma A2 (sseq) = (i:[1,slength]) .nth(i, (s)) Lemma A3 (sseq(k)) = ((i:[1,slength]) .nth(i, (s)))(k) Notice that (i:[0,length(l)1]) . nth(i + 1, l))((k)) = (i:[0,length(l)1]) . nth(i + 1, l))(k 1) nth(k, l). A family of lemmas about isomorphic properties are necessary, among them one has:

Observe, that one has: ((i:[1,slength]) .nth(i, (s)))(k) ((i:[1,slength]) .nth(i, (s)))(k + 1) nth(k + 1, (s)), thus, by lemma A3, (sseq(k)) = nth(k + 1, (s)). On the other side, lists are isomorphically transformed into sequences through the following specied function. (l : list[CryOp]) : seq[CryOp] = (# length = length(l), seq = (i:[0,length(l)1]) .nth(i+1, l) #) As in the direction from sequences to lists, in this direction homeomorphic properties should be formalized.

Lemma isomorphism 1 s : seq[CryOp]. (s) = s Lemma isomorphism 2 l : list[CryOp]. (l) = l

The previous lists of homeomorphism lemmas is not at all exhaustive, and several other isomorphic transformations should be built in order to be able to reuse proofs. Coming back to the example of reusing the proof of Theorem slength = 0 IFF s = empty_seq to prove Theorem length(l) = 0 IFF l = null, one can follow the sketch below:

144

length(l) = 0 (length(l) = 0) (length(l)) = (0) (length(l)) = 0 (l)length = 0 IFF (l) = empty seq ((l) = empty seq) ((l)) = (empty seq) l = (empty seq) l = null

appl. of isomorphism operator isomorphism properties isomorphism properties isomorphism properties reuse of Theorem application of isomorphism isomorphism properties isomorphism properties isomorphism properties 2

p(x1 , . . . , xn )

KS 

isomorphisms Theorem

p ((x1 ), . . . , (xn ))

Theorem p(x1 , . . . , xn )

Figure 4: General sketch for reusing relational proofs by isomorphisms

To summarize, the approach to reuse formalizations through isomorphic transformations involves two main steps: 1. Construction and formalization of isomorphisms: (a) Construction of isomorphic transformations between data structures, functions and relations; (b) Formalization of isomorphic and homeomorphic properties; 2. Reuse of proofs. Once the rst step is completed, proofs by reusing formalizations of equational and relational theorems follow the sketches in Fig. 3 and 4, respectively.

5.

DISCUSSIONS

Although the proposed proof reusing methodology is illustrated with very simple properties over lists and sequences, it is necessary to remark that after having developed a full PVS theory for isomorphisms between both nite sequences and lists, that includes formalizations for homeomorphic properties for functions and relations over sequences and lists, it will be possible to reuse highly elaborated formalizations of theorems of the theory of characterization of security of the Dolev-Yao model for cascade protocols. In this way, one avoids development from scratch of formalizations for the specication of the Dolev-Yao model over lists. In general, the availability in a proof assistant of several libraries about isomorphisms between dierent alternative data structures is of great usability in order to adapt specications to other data structures, dierent from the originally chosen, by reusing formalizations through isomorphisms. Lists and sequences are very similar, except for the inductive schemas to be adapted to deal with recursive denitions; consequently, proofs in one context are very similar to proofs in the other one. But the proposed general methodology is of great interest and usability when dealing with more elaborated data structures used for the treatment of similar solutions. For instance, elaborated data structures such as sux trees and sux arrays are highly explored in complex algorithmic solutions of combinatorial questions over strings, which makes of interest having isomorphic relations between them.

f(x1 , . . . , xn )

KS 

isomorphisms

f ((x1 ), . . . , (xn )) = g(y1 , . . . , ym ) Theorem

KS 

isomorphisms

g ((y1 ), . . . , (ym )) Theorem f(x1 , . . . , xn ) = g ((y1 ), . . . , (ym ))

6.

REFERENCES

Figure 3: General sketch of reusing equational proofs by isomorphisms Reusing proofs is not straightforward. Building poly-sorted isomorphisms works well, but is an exhaustive task. Although this, after specifying isomorphism operators and having proved all mundane isomorphic properties complex proofs can be reused.

[1] D. Dolev and A. C. Yao. On the Security of Public Key Protocols. IEEE. T. on Information Theory, 29(2):198208, 1983. [2] R. Nogueira, F. de Moura, A. Nascimento, and M. Ayala-Rincn. Formalization Of Security Proofs o Using PVS in the Dolev-Yao Model. In Computability in Europe CiE 2010 (Booklet), 2010. [3] S. Owre, J. M. Rushby, and N. Shankar. PVS: A Prototype Verication System. In D. Kapur, editor, 11thInt. Conf. on Automated Deduction (CADE), volume 607 of LNAI, pages 748752, 1992. Springer. [4] Y. Rgo and M. Ayala-Rincn. Formalization in pvs of e o balancing properties necessary for the security of the dolev-yao cascade protocol model. Technical Report www.mat.unb.br/ayala, Universidade de Bras lia, March 2012.

145

Independent verification and validation to ensure higher confidence in the software controlling critical systems Verificacin y Validacin independiente para asegurar mayor confianza en el software que controla sistemas crticos
Patricia Rodrguez Dapena1
1

Softwcare S.L.. Vigo, Espaa. rodriguezdapena@softwcare.com. RESUMEN Cada vez son ms los productos software que son crticos (incluyendo el software que controla sistemas crticos) y de los que depende nuestro da a da, e incluso que si fallan podra ser mortal. Por tanto estos productos software se deben desarrollar muy cuidadosamente, introduciendo los mecanismos de robustez adecuados para evitar posibles efectos adversos. Diferentes sectores tienen requisitos y normativa a ser cumplidos desde el inicio del desarrollo del producto, tanto referentes a los procesos de desarrollo y ciclo de vida, como para el producto a ser desarrollado, y que son ms estrictos cuanto ms crtico sea el producto software. La verificacin y validacin independiente del producto software (ISVV) (que es complementaria a sendos procesos que realiza el desarrollador del software) se identifica como mtodo a ser utilizado para ayudar tambin al aseguramiento de la confianza en el producto software crtico, aunque no es todava un mtodo muy extendido en los diferentes sectores. Este artculo presentar las caractersticas ms importantes de los procesos de ISVV, adems de resultados de experiencias y medidas de la efectividad de este mtodo en el sector espacial europeo.

INFORMACIN DEL ARTCULO Tipo de artculo: Investigacin: ___ Reflexin: _X__ Revisin: ___ Historia del artculo: Recibido: Correcciones: Aceptado: Palabras clave: Categories and Subject Descriptors: Software Verification, Validation. General Terms: Software Engineering, Verification, Validation Keywords: ABSTRACT Our daily lives are increasingly depending on critical software products. These products shall be carefully developed, and shall include adequate robustness mechanisms to avoid its failures may cause any of these adverse effects. Different sectors already have requirements and standards to be applied from the very beginning of the development of these critical products. They contain requirements to both the processes and life cycles models to be implemented and to the product itself. The higher the criticality of the product is, the more stringent the requirements will be. Independent software verification and validation (ISVV) (complementing the verification and validation processes performed by the developers) is a technique used in the space domain to increase the required confidence level of the critical product, although it is not very much used in other sectors. This paper presents what this ISVV means, as well as its benefits and efficiency, at least in the space domain.

146

1. INTRODUCCIN Cada vez son ms los productos software que son crticos (incluyendo el software que controla sistemas crticos). Es decir, de los que nuestro da a da depende, e incluso que si fallan, nos pueden matar. No slo el software que controla el ABS o la direccin asistida en un automvil, ni el software de control en aviones o trenes, si no el software de los telfonos mviles, de sistemas de comunicacin pueden llegar a ser crticos cuando se utilicen para, por ejemplo, un S.O.S. o una ciruga soportada con sistemas de telemedicina respectivamente. Por ello, es importante asegurar que estos productos software se desarrollan con los procesos y mecanismos adecuados para confiar al mximo no tener fallos que sean la causa de efectos catastrficos o crticos. Para ello hay requisitos y normativa a ser utilizada desde el inicio del desarrollo del producto, tanto referentes a los procesos de desarrollo y ciclo de vida, como para el producto a ser desarrollado, y que son ms estrictos cuanto ms crtico sea el producto software. Como ejemplos de estos requisitos se pueden mencionar los siguientes para algunos de los diferentes aspectos en los que se requiere ser ms o menos rigor segn la criticidad del producto a ser desarrollado: a) Se requiere que la gestin de los cambios durante el desarrollo se realicen controladamente para cualquier resultado de cualquier proceso durante el desarrollo pues puede tener impacto en la seguridad/safety del producto (incluyendo planes y estndares del proyecto). Cada cambio propuesto se debe analizar (respecto a cualquier aspecto de safety), se debe aprobar siempre por personal clave en el proyecto, y despus de que implemente, se verifican estas implementaciones. Esto se exige, por ejemplo, en el sector de la automocin, a travs de la aplicacin de la norma ISO/IEC 26262 [2] para la seguridad funcional (lase functional safety) de los vehculos rodados. Tambin se exige en casi todas las dems normas en otros sectores, por ejemplo, la IEC 62304 [8] para los procesos de ciclo de vida del software para dispositivos mdicos, o para el software de control en aviones segn la norma DO178C[3], en los requisitos para el desarrollo de software en sistemas espaciales (ECSS [6], NASA [7]), en el software para sistemas de sealizacin de trenes (EN50128 [4]), etc. b) Se requiere que ciertas actividades se realicen independientemente, sobretodo actividades de calidad, de safety, de verificacin y validacin (pruebas). Cuanta ms criticidad, ms actividades sern realizadas con independencia. Por ejemplo, las tareas de anlisis de seguridad en cada etapa del desarrollo se debe realizar independientemente para el software crtico para el sector de la automocin, la sealizacin de trenes, sistemas espaciales, etc. Las tareas de verificacin y pruebas se deben realizar independientemente en el sector del software crtico para la sealizacin de trenes [4], el software de control en aviones [3], etc. c) Se requiere la verificacin de la cobertura estructural y de requisitos de las pruebas que se realicen al producto crtico, y, por ejemplo, se exige el 100% de cobertura de todas las sentencias, y de todas las decisiones que haya en el cdigo fuente del producto software crtico. Esto se exige en el sector del software crtico para la sealizacin de trenes [4], el software de control en aviones [3], para el

software en automocin [2], en sistemas espaciales [6] [7], etc. d) Se requiere el uso de mtodos para el desarrollo, verificacin, pruebas, etc. del producto ms exigente cuanto ms crtico sea el producto. Una tabla ejemplo de estas exigencias es la siguiente:
Tabla 1 Methods for the verification of requirements
Mtodos ASIL ASIL ASIL ASIL A B C D 1a Verificacin Informal a travs de ++ + 0 0 walkthrough 1b Verificacin Informal a travs de + ++ ++ ++ inspeccin 1c Verificacin Semi-formala + + ++ ++ 1d Verificacin Formal 0 + + + a El mtodo 1c se puede ayudar por modelos ejecutables. ISO/IEC 26262-6 [2]

La tabla anterior proviene de la normativa en el sector automocin (donde ASIL D es el nivel ms crtico y es para el que se exige utilizar mtodos ms rigurosos - ++ highly recommended). Existen tablas y requisitos similares en todos los dems sectores: software crtico para la sealizacin de trenes, el software de control en aviones, para el software en sistemas espaciales, etc. e) Se requiere el uso de mtodos para definir e insertar en el diseo del producto mecanismos de tolerancia a posibles fallos de software. Una tabla ejemplo de estas exigencias es la siguiente:
Tabla 2 Arquitectura Software
TECHNIQUE/MEASURE 1. Defensive Programming 2. Fault Detection & Diagnosis 3. Error Correcting Codes 4. Error Detecting Codes 5. Failure Assertion Programming 6. Safety Bag Techniques 7. Diverse Programming 8. Recovery Block SIL0 SIL1 SIL2 SIL3 SIL4 R R HR HR R R R R R R R R R R R R HR HR HR R HR R HR HR HR R HR R

147

tienen un nivel suficiente de conocimientos, competencias y cualificaciones. La verificacin y validacin independiente del producto software se identifica como mtodo a ser utilizado para ayudar tambin al aseguramiento de la confianza en el producto software crtico, aunque no es todava un mtodo muy extendido en los diferentes sectores. Se exige sobretodo en el sector espacial, tanto en Europa (ECSS [6]) como en NASA [7]. Es importante destacar que no se trata de la realizacin de las actividades de verificacin y validacin independientemente, sino que se trata de la realizacin de actividades de verificacin y validacin extras y complementarias, que estresen el producto, y realizadas por una organizacin independiente no contaminada por los desarrolladores originales. A continuacin se presentar una introduccin de estas actividades y sus objetivos en el sector espacial europeo. Despus se presentarn casos reales de realizacin, de los cuales se podr deducir directamente el beneficio de este tipo de mtodos, aunque, a priori, parezca caro y que complica la gestin del proyecto. 2. VERIFICACIN Y VALIDACIN INDEPENDIENTE DE SOFTWARE (ISVV) Como con cualquier actividad de verificacin y validacin, el objetivo de ISVV es encontrar fallos y aumentar la confianza en el producto software. ISVV debe aportar un valor aadido sobre la verificacin y validacin llevada a cabo por el desarrollador de software. Tiene que ser complementaria, por lo que deber tener diferentes: - Los objetivos, - Procesos, - Los mtodos, - Herramientas, - Las personas. El ISVV se centra en encontrar las posibles deficiencias y errores, tratando de romper el software, con una actitud 'destructiva'. Las actividades ISVV dedicarn especial atencin a las actividades manuales de verificacin y validacin del proveedor de SW (por ejemplo, el realizados del ISVV tambin podra realizar verificaciones automticas de cdigo utilizando herramientas diferentes a las utilizadas por el proveedor del SW). En la Figura 1 se presentan los procesos de ISVV:
MAN. Gestin MAN.PM. Proceso de Gestin de ISVV MAN.VV. Definicin del Nivel de ISVV IVE. Verificacin Independente IVE.TA.Anlisis de Requisitos Software IVE.DA.Anlisis del Diseo IVE.CA. Anlisis de Cdigo IVA. Validacin Independiente IVA.Validacin

roles, responsabilidades, planificacin, presupuesto y estimaciones, comunicacin, competencia, confidencialidad, etc. Es un proceso cuya responsabilidad es tanto del cliente como del proveedor de ISVV, como se muestra en la siguiente figura:
PM.T2.S2 Submit documentation and code to ISVV supplier Agree on scope PM.T2.S3 Check received documentation

PM.T2.S13 Update criticality analyses PM.T2.S4 Perform verification or validation activities yes Any PM.T2.S5 clarification Request needed? clarification

Any clarification received? yes PM.T2.S6 Respond to requests for clarifications PM.T2.S8 Review early ISVV Findings

PM.T2.S7 Report early ISVV findings PM.T2.S9 Produce ISVV verification report

PM.T2.S10 Conduct Review Meeting

PM.T2.S11 Produce ISVV findings resolution report

PM.T2.S12 Implement resolutions ISVV Customer ISVV Supplier

Figura 2 - Tareas del proceso de Gestin de ISVV

El proceso de definicin del nivel de ISVV (MAN.VV) es de apoyo al de Gestin y tiene como objetivo limitar el alcance, sobretodo en el uso de los mtodos propuestos para realizar los diferentes procesos de verificacin y de validacin. ISVVL 0 significa que para ese producto no se requiere ISVV, y ISVVL 2 es el ms estricto. El nivel de ISVV se identifica combinando la criticidad del software (cuanto ms criticidad SCC- mayor nivel de ISVV) y otros factores del desarrollo que pueden influencias la introduccin de fallos y errores en el producto (analizado en lo que se denomina error potential questionnaire y que incluye desde la experiencia y habilidades del equipo de desarrollo, hasta la novedad del diseo y tecnologas del producto a ser desarrollado, el tamao y (des-)localizacin del equipo de desarrollo, la complejidad del producto, etc.). A mayor potencial de error mayor Nivel de ISVV.
Tabla 3. Tabla de definicin del Nivel de ISVV [1]
SCC 4 SCC 3 SCC 2 SCC 1 ISVVL 2 ISVVL 2 ISVVL 2 ISVVL 1 ISVVL 1 ISVVL 2 ISVVL 2 ISVVL 0 ISVVL 1 ISVVL 1 ISVVL 2 ISVVL 0 ISVVL 0 ISVVL 1 Low Medium High Error Potential Software Criticality Category

ISVVL

Figura 1 Actividades de ISVV [1]

El proceso de Gestin del proceso de ISVV (MAN.PM) se ocupa de cuestiones tales como la identificacin de los

148

estas tareas (TAR) por parte del cliente del ISVV, donde puede filtrar, re-clasificar o aclarar los findings encontrados en esta verificacin. Anlisis de Diseo (IVE.DA), que es la verificacin del diseo de software de arquitectura, del diseo detallado de software, y del Manual de usuario. La actividad finaliza con una revisin de estas tareas de verificacin (DAR).
Tiempo
Desarrollo de software

Anlisis de cdigo (IVE.CA), que es la verificacin del cdigo fuente del software, junto a la verificacin de las pruebas unitarias y de integracin del software realizadas por el desarrollador del software. La actividad finaliza con una revisin de estas tareas (CAR). El proceso de Validacin >Independiente (IVA) consiste en probar del software para estresar que la aplicacin cumple con las especificaciones tcnicas de una manera robusta y que se conocen los lmites del comportamiento del mismo y que si falla ante los mismos, se conocen los efectos y estn controlados. Las pruebas se realizan independientemente aunque a veces se realizan en el mismo entorno de pruebas del proveedor del software. La actividad finaliza con una revisin de los resultados de esta validacin independiente (IVR).

SRR

PDR

CDR

QR

Requisitos y Arquitectura Diseo detallado e implementacin Validation Verification Entrega y aceptacin

TA
ISVV

DA CA
Validacin Independiente

1 mes

2 meses TAR DAR

1 mes CAR

1 mes IVR

Figura 3 Procesos de ISVV versus los de desarrollo Tabla 4. Extracto de la Tarea 1 para la verificacin del cdigo (IVE.CA.T1) Title: Activity: Start event: End event: Responsible: Objectives: Inputs:
TASK DESCRIPTION Source Code Verification IVE.CA.T1 Task ID: IVE.CA Code Analysis CDR Critical Design Review CAR Code Analysis Review ISVV Supplier Evaluate the software source code for internal consistency, correctness, completeness, accuracy, testability, and readability. From ISVV Customer: Software Requirements Specification [TS; DDR] Interface Control Documents [DDF; CDR] Software Architectural Design including software models if produced [DDF; CDR] Software Detailed Design including software models if produced [DDF; CDR] Software dependability and safety analysis reports [DJF; CDR] Schedulability Analysis (including WCET) [DJF; CDR] Technical Budgets [DJF; CDR] From ISVV Supplier: Technical Specification Verification Report [IVE.TA.T1] Software Architectural Design Verification Report [IVE.DA.T1] Software Detailed Design Verification Report [IVE.DA.T2] ISVV level definition (from Design Analysis MAN.VV.T3) Contribution to Independent Validation (from Design Analysis) IVE.DA.T2

Implementation:
ISVV Level 1 and 2: IVE.CA.T1.S1: Verify source code external consistency with Technical Specification (by Inspection - reviewing the traceability matrices produced by the software developer): Ensure that all software item requirements are traceable to a software unit (source code) and that the functionality described in the requirement is implemented by the source code unit (forward traceability); Ensure that all software units (source code) have allocated requirements and that each software unit (source code) is not implementing more functionalities than the ones described in the requirements allocated to it (backward traceability) For each requirement traced to more than one software unit (source code) ensure that implementation of functionalities is not repeated. Ensure that the relationship between the software units (source code elements) and the software requirements are specified in a uniform manner (in terms of level of detail and format). IVE.CA.T1.S2: Verify source code external consistency with Interface Control Documents (by Inspection - reviewing the traceability matrices produced by the software developer): Ensure that the interfaces implementation (with other software units, hardware, the user, etc.) is consistent with the applicable Interface Control Documents. Software Source Code Verification Report Outputs: Contribution to Independent Validation (updated) -

149

Tabla 5. Aplicabilidad de los mtodos a ser utilizados en algunas sub-tareas de IVE.CA.T1 Task Sub-task Method/Technique

IVE.CA.T1

IVE.CA.T1.S4: Verify interfaces consistency between different SW units IVE.CA.T1.S5: Verify source code correctness with respect to technical specification, architectural design and detailed design

Inspection Reverse Engineering1 Inspection Reverse Engineering1 Bug pattern identification Inspection software static analysis, metrics, coding standard conformance checking

ISVV Level (when not specified it always applies) ISVV Level 1 ISVV Level 2 ISVV Level 1 ISVV Level 2 ISVV Level 1 ISVV Level 2

IVE.CA.T1.S6: Verify the source code readability, maintainability and conformance with the applicable standards

ESA ISVV Guide [1]

Tabla 6. Formato de comentario resultado de cada discrepancia de los procesos de ISVV

Review Item Discrepancy Title Originating subtask Document reference Problem location Problem description Item N Date Author Unique identifier of the RID. Origination data of the RID (e.g. in DD.MM.YYYY format). Author/originator of the RID. Title of the RID. Identification of the verification subtask in which the RID was identified (e.g. IVE.CA.T2.S1). Identification of the document against who the RID was raised. Identification of the inconsistency location (document page, software component, source file and line). Claim: The description of the problem found. Recommendation: Recommendation aiming at the resolution of the RID. This is an optional field. Problem type (see Error! No se encuentra el origen de la referencia.) RID classification according to the problem types: Problem type Description External consistency Internal consistency Correctness The item presents an inconsistency against an item of an applicable or referenced document (e.g. the component design is not according to an applicable software requirement). What is implemented is not what is required. The item presents an inconsistency against another item in the same document (e.g. the description of an interface is not consistent between the interface user and the interface provider). The item is incorrectly implemented, technical issues are being violated. Consider for instance an activity diagram that contains a deadlock condition. That would be a case to which correctness will apply. The item is not technically feasible taking into account the applicable constraints (e.g. the architecture makes extensive use of advanced object oriented techniques but the application is to be written in C language). The item is hard to read and/or to maintain. An individual other than the author will have serious difficulties in implementing and/or maintaining the item. The information provided is confuse and therefore may lead to wrong interpretations. The item is not completely defined or the provided information is not sufficient (e.g. the description of the service 5 telemetry provided in the user manual do not allow for a clear identification of the error cause). If an item do not completely implements a requirement or interface defined in an applicable or reference document, one shall use external consistency instead.

Technical feasibility Readability & Maintainability Completeness

Severity classification (see Error! No se encuentra el origen de la referencia.)

RID severity classification according to table below. The severity classification is originally assigned by the ISVV Supplier and then reviewed and possibly updated together with the ISVV Customer. Severity Description classification Major Minor Comment The discrepancy found presents a major thread to the system. Its correction is pertinent. The discrepancy found is a minor issue. Although it does not present a major threat to the system, its correction should be done. The discrepancy found does not present any threat to the system. The RID was raised as a recommendation that aims at improving the quality of the affected item. The implementation of the recommended correction is optional. ESA ISVV Guide [1]

150

En la tabla 4 anterior se muestra un extracto de una tarea tal y como se define en la Gua de ISVV [1]. Se identifican cules son algunas de las sub-tareas de la tarea IVE.CA.T1, que es una tarea aplicable a los Niveles ISVV 2 1 (como se muestra en la tabla). Adems, en los ejemplos de la tabla 5, la Gua [1] menciona los mtodos a ser utilizados para cada una de las sub-tareas, identificando cules utilizar para los diferentes niveles de ISVV. En la tabla 5, el uso del mtodo de Ingeniera Inversa slo se utilizar para realizar las sub-tareas IVE.CA.T1.S4 (para verificar la consistencia de los interfaces entre las diferentes unidades/mdulos del cdigo) y la IVE.CA.T1.S5 (para verificar la correctitud del cdigo fuente respecto a los requisitos y diseos) Los resultados de la realizacin de las actividades de ISVV, como de las actividades de verificacin y validacin durante el desarrollo, son discrepancias, problemas, findings, que son transmitidos a los desarrolladores para corregirlos. Estos comentarios o findings se pueden documentas siguiendo diferentes formatos. La tabla siguiente se presenta un ejemplo de cmo se transmiten estos findings normalmente en proyectos espaciales: 3. EXPERIENCIAS Y CASOS REALES 3.1 Definicin de la efectividad del ISVV El ISVV es un mtodo de obligado cumplimiento para el desarrollo de software crtico (niveles A mximo nivel- y B) en sistemas espaciales, tanto en Europa como en NASA. A priori parece costoso, introduce complejidad en la organizacin y gestin del proyecto y su efectividad resulta difcil medir. La organizacin de estos proyectos suele ser ms compleja, ms cara pues hay que contratar a otro proveedor para realizarlas, adems de que los findings y comentarios del ISVV llegan al proveedor del software ya avanzado el proyecto de desarrollo, refirindose a correcciones de resultados de fases ya pasadas y que repercutirn adems en cambios en toda la cadena de resultados posteriores (ej. findings en los requisitos, supone cambios posibles en el diseo y en el cdigo que ya se estn desarrollado). Hasta el momento, la efectividad de la utilizacin de este mtodo no se ha cuestionado pues: se compensa nada ms encontrar y corregir un slo fallo severo que ya no cause un efecto catastrfico o crtico durante el uso del sistema (pues esto s resultara de un costo incalculable). Encontrar inconsistencias en los tipos de datos de interfaz entre componentes crticos (del tipo KM en vez de Millas); o de fallos de robustez del producto recomendando el uso de mecanismos de tolerancia a fallos: de defensive programming o determinados assertions, etc. son ejemplos de la razn del ISVV en los proyectos. Pero, tras la realizacin de bastantes proyectos de ISVV en diferentes proyectos espaciales, se ha querido medir cuantitativamente la efectividad de los mismos. Por tanto, se contrat la realizacin de un proceso de medidas y su anlisis en diferentes proyectos de ISVV realizados por diferentes empresas y organizaciones europeas. El proceso de medida utilizado sigui los pasos identificados por la norma ISO/IEC 15939 [10]. Una de las primeras actividades fue la de definir los objetivos de qu objetivos se quieren medir, para determinar las medidas en detalle y los datos necesarios a ser recolectados. La

efectividad de la verificacin independiente se defini en base a los siguientes factores:

Number, type, severity and implied changes of findings per stage/task

Requirements stability

Tools usage

Problem complexity

Characteristics of input software Documentation / code quality

ISVV verification cost effectiveness

ISVV findings usability and understandability

ISVV after SW review

Figura 4. Efectividad de los procesos de IVE

Estos factores se identificaron como los que se deban de recolectar para medir la efectividad, tras analizarse que slo se poda estudiar la efectividad de los procesos de verificacin independiente. No se podran obtener datos comparables de los procesos de validacin de los diferentes proyectos (asunto a ser corregido en el futuro en los proyectos ISVV). Adems, tampoco se iban a poder obtener datos de esfuerzos ni costes dedicados a los diferentes procesos y tareas, por lo que los anlisis a ser obtenidos sera solamente basados en el nmero de findings y en su tipologa y eficiencia. Se recolectaron y analizaron datos de 15 proyectos ISVV, de sendos 15 productos software crticos de 5 proyectos espaciales diferentes. No se han proporcionado datos de todos los factores mencionados en la Figura 4 anterior, pues fueros todos recolectados con efecto retroactivo (los proyectos ISVV ya haban finalizado hace aos) por lo que el anlisis de la efectividad se vi un poco limitado. 3.2 Medidas de la efectividad del ISVV El total de findings que se recopil por proceso de ISVV se muestra en la figura siguiente:
IVE.TA 958 39% IVE.CA 824 33%

IVE.DA 710 28%

151

IVE.TA.T1 (Requirements traceab verif) 191 21%

verificacin y validacin, siempre es mejor poder utilizar herramientas (maduras) que soporten el anlisis y las inspecciones, pues adems de ayudar a realizar las tareas y actividades ms rpidamente, siempre ayudan a evitar los posibles fallos humanos al realizar las tareas manualmente.
Semiaut omat ed 2% A ut omat ed 1%

IVE.TA.T2 (Requirements verif) 702 79%

Figura 6. Findings por tarea del proceso TA [9].

Pero analizar slo estos totales per s no proporcionan ninguna informacin acerca la efectividad de las tareas de ISVV. Haba que analizar los findings que tuvieran un efecto de cambio y correccin en el software crtico: estos son los efectivos. La figura siguiente muestra que la mayora de los findings encontrados originaron una necesidad de correccin en el software crtico. Incluso se compar cul era esta proporcin respecto al tamao del producto (productos grandes, medianos o pequeos) o al tipo de producto (producto de tipo aplicacin o tipo sistema operativo o SW de bajo nivel), y siempre la mayora de findings era efectiva:
Not effective 31%

M anual 97%

Figura 9. Porcentaje de findings descubiertos con el uso de herramientas [9]

Effective 69%

Como se ve en la figura 9 anterior, el porcentaje de findings que se ha descubierto con el uso de herramientas, ya sea directamente por la herramienta, o semiautomticamente con la ayuda de los resultados del uso de alguna herramienta es decepcionantemente bajo. Esto puede ser debido a varias causas: a) a que no hay herramientas maduras que ayuden a realizar estas tareas; b) a que la Gua no es clara respecto a las tareas a realizarse por lo que no se buscan herramientas que puedan ayudar; c) las habilidades del personal de ISVV no es madura. Es un tema a intentar corregirse respecto a los procesos de ISVV en los proyectos. Ms aspectos identificados en este proyecto de medida de la eficiencia de los procesos ISVV es la identificacin de subtareas de las que no se han identificado ningn finding en ninguno de los proyectos evaluados. Como consecuencia, en caso de tener que reducir en nmero de sub-tareas a realizarse, esas seran las primeras a descartarse. Adems, puede que la razn de no encontrarse ningn finding sea por que la Gua no la defina adecuadamente o que sea difcil de realizar. 4. CONCLUSIONES Y TRABAJOS FUTUROS Tras analizarse diferentes aspectos sobre la eficiencia de los procesos de ISVV en los proyectos, la conclusin del estudio es que son sin duda muy efectivos. El 69% de los findings es efectivo, y, aunque no todos so de severidad importante (major), la cantidad es suficientemente elevada como para justificar la realizacin de estos procesos de ISVV. Adems, se ha demostrado que no importando el tipo de producto, el proyecto, el tamao, y para todas las severidades de findings. Pero, aunque como primer ciclo de medida, los resultados son valiosos, es necesario seguir realizando los siguientes trabajos futuros y seguir iterando las mediciones: - Se recomienda recolectar los datos en todos los proyectos ISVV (que anteriormente NO se haban recolectado como tales durante su realizacin). Para ello se deber utilizar la plantilla fija e idntica para todos los proyectos a ser proporcionada por el Cliente del proyecto ISVV). - S es importante corregir el hecho de que slo para el 3% de findings se utilizaron herramientas (especialmente en

Figura 7. Findings efectivos [9]

Pero de nuevo surge la necesidad de ahondar ms en cul es el tipo de findings efectivos: si son comentarios editoriales o si son fallos importantes (major) que si no se corrigen ponen en peligro en sistema. La figura siguiente muestra el nmero de findings por tipo de severidad, y cules de cada tipo han sido efectivos.
100% 270 80% 60% 40% 66 20% 0% Comment Major Minor Very Low 638 997 62
NOT effective

446

13

effective

Figura 8. Findings efectivos segn su severidad [9]

Aunque la mayora de findings de cada tipo han sido efectivos, la figura 8 anterior nos muestra que la mayora de findings efectivos es de tipo menor, o sea, fallos que no presentan un problema importante aunque deberan ser corregidos (ver la Tabla 6 anterior). De todos modos, la cantidad de fallos clasificados como importantes (major) era tambin considerable, lo cual justifica la necesidad de estos procesos ISVV en los proyectos. Se analizaron otros muchos aspectos de la eficiencia de los proyectos de ISVV. Cuando se realizan tareas de

152

las tareas de Anlisis de cdigo CA). Se debe revisar la Gua [1] para aclarar mejor la posibilidad del uso de herramientas para la realizacin de las diferentes tareas, y no slo recomendar los mtodos a utilizarse. - Aunque cuando haya restricciones de presupuesto o tiempo se puedan dejar de hacer sub-tareas de las cuales no se han identificado findings en estos primeros proyectos medidos, se debe revisar la Gua [1] para aclarar mejor estas sub-tareas. 5. AGRADECIMIENTOS Este trabajo de medicin de la eficiencia de los procesos de ISVV fue financiado por la Agencia Espacial Europea (ESTEC contract No.: 18543). 4. REFERENCIAS
[1] ESA Guide for Independent Software Verification and Validation. ESA ISVV Guide. Issue 2. December 29, 2008. [2] ISO/IEC 26262 Road vehicles Functional safety Parts 1-10. ISO. 2011.

[3] DO-178C. Software Considerations in Aeronautical Systems. RTCA, Inc. 2011. [4] EN 50128:2011. Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems. CENELEC. 2011. [5] IEC 61508. Functional Safety of Electrical/Electronic/ Programmable Electronic Safety-related Systems (E/E/PE, or E/E/PES). Parts 1-7. Ed. 2 IEC. 2010 [6] ECSS. ECSS-E-ST-40C Space Engineering Software. ECSS. 2009. ECSS-Q-ST-80C Product Assurance Software product Assurance. ECSS. 2009. [7] NASA-STD-8719.13B w/Change 1 Software Safety Standard. NASA technical standard July 8, 2004 [8] IEC 62304:2006. Medical device software Software life cycle processes. IEC. 2006 [9] P. Rodrguez-Dapena. Final Presentation. ISVV Metrication Analysis. 2011. ISVV cost effectiveness Metrication project.

153

MEDELLN 2012